In my last post, I criticised the movement that aims to take enterprise architecture into the business strategy arena. The basis of this argument was that it is impractical and unsustainable. I stated that:
- The chief strategy officer (CSO) should clearly have responsibility and final answerability for defining the enterprise operating model. The enterprise operating model defines the macro structure of the extended enterprise, its internal and external interactions and how these deliver the organization’s purpose and goals.
- The chief operating officer (COO) should clearly have responsibility and final answerability for implementation and operation of business processes that deliver the enterprise operating model.
- The chief information officer (CIO) should clearly have responsibility and final answerability for implementation and operation of IT solutions that underpin the business processes.
There is another argument that may be more compelling to some. It is the argument of separation of concerns. I have worked in the strategy area reporting into the CSO, I have set up and run enterprise architecture functions and business change functions, so I have some idea of what the work involves. The diagram below gives a high level and non-rigorous indication of the artifacts that are used in each area. You can obviously infer the activities of creating, analysing, communicating, governing and preparing plans based on these artifacts.
The key point is that the artifacts are disjoint (but related), the activities are disjoint (but related), involve different people, and operate to different time-frames. They are different (but related) things!
The important issue is how do you manage that interrelationship. I think I have said enough already to debunk the idea that a large centralised enterprise architecture function will do the job.
In most organizations that I have encountered there is little recognition that the disciplines, approaches and techniques that enterprise architects use are of value in business strategy, business change or business operations management. This leaves enterprise architects with the job of formalising the output of those activities, often after the event. I would describe this as the normal, pragmatic and sustainable approach to enterprise architecture.
However, in a fast changing organization, this approach is not ideal.
- At the strategic level, getting the macro structure wrong may mean significantly higher costs of operation, longer process execution times, longer time to time market, and reduced competitiveness.
- Similarly, with poorly defined business processes, there are likely to be higher costs of operation, longer process execution times, longer time to time market, and reduced competitiveness.
- Without a clear view of current business processes, target processes, progress of all solution elements, delivering business change is likely to be very painful.
- If business change is not under close control then it will be near impossible to ensure that IT releases are coordinated with business change.
So what organization models for enterprise architecture are useful in avoiding these issues? I have worked with two models successfully which I will describe.
Layered enterprise architecture…
The first model assumes that the CSO and COO recognise the value of the type of modelling that business architects carry out and is preferable (but potentially does have the issues of long term sustainability).
In this model, the CSO has a small strategic business architecture team. The architects will be very senior with broad business experience and well respected at director and VP level within their organisation. This team will liaise with teams in business operations and IT to ensure that strategic options are viable.
Within business operations, there is a team that maintains business process documentation and manages business change. It consists of a team of business architects, business analysts, procedure writers and business change managers. There is close coordination with IT to ensure that what IT delivers is what the business is geared up to expect.
IT has the usual functions of applications, information and technology architecture.
Business architecture as a service (presumably BAAAS!)…
Rather than formalise business architecture after the event when IT needs to deliver, a better model is to offer a business architecture service to the relevant parts of the business at the time it is needed.
This means offering the best, most experienced and most credible business architects and business analysts to the business well in advance of any IT delivery.
The key sell points for this are above. This is where establishing clear objectives that balance longer term objectives with short term delivery is an essential prerequisite.