Enterprise patterns and architecture

There is sometimes a disconnection between the business strategy and the IT strategy of a company and that inevitably implies unexpected effects like e.g. difficulties for IT to deliver solutions in due time, on scope, on budget or with the requested level of quality. 

One of the things the business part of a company wants to achieve is a consolidated view of their business domains, processes and actors to enable efficient market analysis, product management, etc. On its side, the IT part is concerned with the perennial maintenance and evolution of its infrastructure in order to respond optimally and in a flexible way to current and future needs. Well that is ok, but is it sufficient ?

The answer is potentially no. For example, are these two approaches able to answer key enterprise governance questions like:

• Which piece of software is supporting which business product or service ?
• Which business domain relies on which IT asset (software, hardware, licenses, …) ?
• How to assess the impact of business product /service modifications on IT infrastructure ?
• How to assess the impact of a technological change on business products and services ?

Let’s illustrate that through a real case where the business had initiated a business domain modelling effort while IT was proceeding with the implementation of a Service Oriented Architecture (SOA) framework. After a couple of months and several hundred thousand Euros spent, these governance questions were remaining unanswered and finally both initiatives have been cancelled. Why ?

Well a more optimal cooperation and communication would have certainly helped, but more importantly, what should have connected the business domain (and business objects) to IT infrastructure assets was missing … But what is it ?

Knowing the business needs is not sufficient for a technical implementation because they do not provide all the necessary information needed for a proper technical design. On the other side, the SOA infrastructure in the above example was an off-the-shelf package, a platform, a toolbox. It does not come natively with all the logic (functionality) needed to support the company specific business needs. Consequently there is inevitably some additional work to do. This work comes after the identification and modelling of business needs and before the technological design : This is the functional design or functional architecture domain.

The good news is that the modelling approach adopted by the business normally caters for that. Modelling methodologies allow deriving from business needs the functions that will support them. In turn the functions modelling will allow the appropriate technical design that will implement them.

So what are the learnings from the example described here above ? :

• Business and IT strategy efforts must be synchronised
• Functional architecture connects Business and IT and cannot be spared
• For that purpose, models are helpful provided they cover:
  • Business domains
  • And supporting functions
  • And IT infrastructure/assets
• Agility is key.

What is meant by agility in this context ? Well adopting a “waterfall” ^[1] approach i.e. modelling the entire business and, only after, all supporting functions and, only after, the IT infrastructure is not practical. Results would only be obtained months later, at best. This is rarely compatible with the responsiveness the business reality requires.

So an “agile” ^[2] approach is probably more appropriate i.e. pick one business domain or sub-domain, identify supporting functions and map to (or design) the appropriate IT infrastructure assets. Then pick another domain and go through the all cycle again. Business value is then rendered sooner and more regularly to customers.

One last word about models, they are useful at all levels of the company provided:

• They are maintained
• They reflect reality accurately
• The various model “users” are trained or informed in a fashion that suits their needs !

 

References:

[1] Waterfall model, Wikipedia
[2] Agile software development, Wikipedia

Related articles:

• Quid of the functional strategy ?