Is the enterprise architecture a town plan? I’m not sure I agree with the idea that the enterprise architecture is analogous to a town plan. For example, under the work-in-progress ‘Coherent Enterprise Archiecture’ (CEA) e-book maintained here, the follow definition applies:
“The CEA strategy [is to] to lay out the Notional and holistic enterprise master plan at the high level, establish the common foundation and building blocks at the low level. The high level master plan serve[s] as the master [guideline] similar to a city plan for a city for holistic consideration. The low level common foundation and building blocks enable agility and simplicity. “
This idea of a ‘master plan’ leads the discussion into teritory best avoided. It is at odds with the MWT Model in that it is planning rather than market/architecture focused It implies that development of the enterprise architecture is a planning process that might result in a plan that should be executed.
Where the town planning analogy is helpful is in zoning. In this respect the town plan is useful in that it enables decisions. The enterprise architecture, rather than containing the organisation, enables decisions about the organisation to be made.
It also allows for anybody to raise an exception by means of identifying the a zoning law is being broken. Not only that but it’s the basis for configuration management for the town because making changes to the town will require various notices to be posted depending on zone that relates to the proposed change.
You can see other parts of the CEA framework address Buy In (http://www.liteea.com/lea.php?catid=298&blogid=1). This seems to imply that somebody else is deciding an enterprise architecture presenting it for approval. This isn’t really the purpose of EA. The purpose of EA is to allow joint decision making at the executive level.
An ‘architecture’ under MWT definition is a deliniated shared understanding. A collaboration architecture is a delinitaed shared understanding specifically for collaboration. In the case of enterprise architecture, this is collaboration during the executive decsion making processes on business process sharing and/or standardisation and data sharing and/or standardisation (which in today’s world tends to be technology spend and TEBT (http://www.managewithoutthem.com/tebt).
I’m not picking on CEA here. I think it’s well thought out and it represents a very useful ontology providing terms of reference talking about enterprise architecture. However, as I’ve said before an ontology is not a management process in itself. More importantly, the process of execution is likely to not be isomophic to the solution under development. The process is in fact likely to look conceptually like the opposite of the solution.
So while the CEA material (again, referenced here http://www.liteea.com/lea.php?catid=135&blogid=1?) effectively shows a hierachy of ‘master plan’, ‘segement architecture’, ‘solution architecture’, and ‘building blocks’ these are trying to build a picture the enterprise which fits together. Which is interesting, important, and certainly descriptive of the enterprise – but is it the enterprise architecture?
Specifically, regarding the idea of a ‘segment architecture’ I’ve seen discussion (such as here http://it.toolbox.com/blogs/lea-blog/what-is-segment-architecture-25945) which describes the rational as:
… EA [utilises a] segment architecture approach rather than the traditional big bang effort. It is a divide and conquers approach to enable incremental and continuous enterprise architecture effort based on business owners need.
This approach may be in fact become nessecary for the same reasons I’m coming to which relate to people trying to do to much in the descriptive aspects of EA and not enough in the aspects relating to the enabling of collaborative decision making. But it doesn’t tell me what enterprise architecture actual is – it only narrows the scope you are applying the definition to.
So the history of how we view EA has determine that we need to break it up into segment architectures; but the fact remains that a segment architecture is not an enterprise architecture. More importantly one particular organisation I work with takes it’s segmentation strategy very seriously – having spent considerable time aligning financial treatments to segment boundaries to allow segment level reporting of financial data. This organisation would require both segement architectures to allow decision making at a segment level and also a true enterprise architecture (not simply the sum of the segments) to enable discussions around the unification of value across segments and to reduce the risk of segment based performance optimisation at the expense of enterprise performance optimisation.
In recent communications to this particular client I have tried to raise the point that the conversations about how to apply the financial rules during the transition to segmentation have created value but that unless these conversations continue via the mechanism of enterprise architecture (not segment architecture) there is a risk that value will be los through independant optimisation of performance of the type described above (at the segment level).
Where is platform architecture?
If you want to delve into the details underneath the enterprise architecture you could ask ‘where is the platform architecture’? Where have the decisions been made on which platforms will be the standardised for particular functional areas (be it business functions, integration functions, storage, etc)? This could also be called a technical reference architecture. But again, this misses the point of why I think this approach to EA is wrong.
What if you just had an enterprise architecture?
I have prepared a simple enterprise architecture for a client I’m currently working with. It is not the ‘master plan’. It is not divided into particular segments (except where they are formally seperate and independant business entities) – and may never be. It does not yet trace to a system architecture of any description. Nor does it describe any particular platforms, applications, technologies. There are a few IT related terms in the architecture but these relate to specific areas of functional groupings such as enterprise event management and shared data access which are important to the organisations operational processes.
Some people would say I have created an ‘enterprise business architecture’ and that this is just part of the enterprise architecture. But why is it only part? An application architcture doesn’t need to contain the code. The application architecture can be delivered without the code – so why can’t the enterprise architecture be delivered without the application architecture!?
