Enterprise patterns and architecture

Every business solution ^[1] aims at addressing business/customer needs. So an appropriate understanding of these needs is fundamental before proceeding with a design, a development, an implementation, …  In short, everything that the adopted development methodology ^[2] requires.

Perfect, are we tempted to say, but … what about the needs which are not business i.e. not rendering directly value to the customers ? for example the capacity, robustness or resilience of the solution ? These requirements are often called “non-functional” ^[3]. And finally what about the processes supporting the business solution: operation, maintenance, support, ordering, billing, … ?

In an IT context, most of the development methodologies start by analysing the business needs (business modelling), then derive the necessary functionality to support these needs that get finally implemented in a technical solution (software/hardware). These methodologies tend to focus on the functional needs (the ones directly beneficial to the customer or expressed by him) and on software aspects. The processes and non-functional parts being less well covered.

This is the submerged part of the iceberg which can nevertheless represent a consequent or the main part of the overall development efforts and costs. Here are some examples of non-functional aspects to take into account:

Accessibility	Operability	Effectiveness
Audit and control	Parties (dependency on other)	Efficiency
Availability	Performance	Extensibility
Backup	Portability	Failure management
Capacity	Pricing	Interoperability
Compatibility	Privacy	Security
Compliance	Quality	Stability
Configuration management	Reporting	Testability
Deployment	Resilience	Legal and licensing
Disaster recovery	Robustness	Training
Documentation	Scalability

Underestimating or ignoring these aspects induces delays, additional costs and inaccurate business cases because the reality of the implementation of the solution always demands these requirements to be addressed sooner or later. Who can for example afford to spare security or performance ?

So how to increase the chances not to miss anything ?

1. By adopting a development methodology that takes into account the needs of all the actors interacting with the solution i.e. not only the business actors but also the non–business ones: back office ^[4], third-party providers, employees …
2. But also by initiating the design and development of the processes associated with the business solution. This effort must be conducted simultaneoulsy to the software development effort.

What the iceberg metaphor tells us is that what is visible is anticipated and what is hidden is underestimated but this is that part that makes the whole thing float.

References:

[1] business solution
[2] software development methodology, wikipedia
[3] non-functional requirements, wikipedia
[4] back office, wikipedia

Related articles:

• Quid of the functional strategy ?