Month: January 2009

Does the enterprise architecture really ‘contain’ the organisation?

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 (  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 (

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 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 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!?

Update to Enterprise Architecture Worksheet

I have updated the MWT/TEBT Enterprise Architecture Worksheet (pdf).  The major change is that I have included a better template diagram.  I have also included some references to the Enterprise Architecture As Strategy book which make it clear that a different diagram template is probably required for enterprises with different operating models.  The worksheet is now suitable for a unification operating model as defined in the EA as Strategy book.

The reason for the update is that I have been trying to visualize the enterprise architecture of a client organisation I am working with and this process has helped my thinking.  I’m a big supporter of the approach to Enterprise Architecture prescribed in Enterprise Architecture as Strategy.  However, the client I am working with at the moment that has a number of important characteristics which don’t come out very well in the example and template EA ‘core diagram’ formats show in the book.

The book itself isn’t about a modeling notation so it doesn’t actually prescribe a specific diagram style. It’s focus in more iterative development of the enterprise architecture and the sequence of components to focus on during development of the architecture.

The organisation I am working with, while certainly operating under a Unification model at the highest level, has a number of unique pillars in their competitive strategy which don’t come out when taking the book’s approach. So I have altered the generative sequence for EA development in this organisation.

Firstly, the unique strategic pillars for this organisation are:

  1. High need for operational capital
    1. Resulting in a need to support the organisation’s share price
    2. Resulting in a business segmentation strategy to increase visibility of value to the market
  2. Need to manage markets and customer types across two distinct operations in order to remain competitive
  3. Need for detailed product accounting to ensure accurate profitability of each ‘product’ can be determined
  4. Need to be able to quickly change ‘product’ mix across two operations
  5. A natural fit to a service oriented business architecture

MWT/TEBT Enterprise Architecture Template (Unification)

Because of this I have developed a template EA core diagram structure which takes these into account. I believe it works very well for this organisation and others like it. I have included the diagram to the right with a full sized version (as well an overview of it’s main zones and analysis patterns) available in the pdf file.

Traceability in enterprise architecture

Whenever I read about enterprise architecture I’m always struck by how technical the conversation seems. I’m not anti-technical; but in my mind architecture is more important than what we generally call management.  This is also implicit in the principles of the MWT Model.  It is in fact architecture which I see as the centrally coordinating mechanism of organisations rather than management. 

This means that at the specific level at which you are coordinating the architecture needs to be understood by all participants – not just technical people.  If the level of coordination is the executive team making IT investment decisions the particular architecture is the enterprise architecture.

Now I’m the first to complain when IT Management becomes a race to the bottom and when IT Managers wear the statement ‘I’m not a technical person’ as a badge of pride (isn’t management ‘technical’?) but I’m talking about something different and specific here. If enterprise architecture has an intended audience that includes so-called non-technical people it cannot be technical.

The problem is, I find that enterprise architecture is always defined as something too all encompassing. It is always defined inclusively of all the business processes, goals, objectives, technologies assets, etc of an organization. It’s almost defined as something that isn’t valuable until it is complete at all of these levels.

However, this causes immediate problems that are reflected in every analysis of enterprise architecture (or failures in EA effort) that I ever read. It always appears to be that EA efforts fail because they are not maintained, through ‘lack of governance’, or that they are misunderstood or ignored by senior management.

Analysis of EA effort actually spent is one thing, but other field reports indicate that the effort never even officially gets off the ground before it’s too difficult to define the ROI of the investment.  Nobody seems to question the ROI of dedicating resources to blocking and passively obstructing enterprise architecture efforts but that is another issue altogether.

I think the solution to these problems is very simple. It’s a solution that eliminates the high-cost of enterprise architecture initiatives (and therefore the issue of ROI), it also helps incorporate enterprise architecture efforts into the rest of the organisation (therefore making alldesign effort enterprise architecture effort), and it takes enterprise architecture to the board room (or at least the CIO’s office) where it belongs.

The three fifteen step plan for solving your enterprise architecture issue is as follows:

  1. Hire a real enterprise architect
  2. Establish only ‘dotted-line’ reporting to the enterprise architect
  3. Use the phrase ‘enterprise architecture’ only to refer to ‘enterprise business architecture’
  4. Establish ‘planned traceability’ from the EA to project documentation
  5. Establish ‘planned traceability’ from the EA to system documentation
  6. Establish ‘planned traceability’ from the EA to software development life-cycle (SDLC) documentation
  7. Hold a workshop to established a baseline enterprise [business] architecture
  8. Schedule reviews of traceability each 6 months for each application system
  9. Include traceability reviews in the organizations project methodology at each phase gate
  10. Schedule a review of the baseline enterprise [business] architecture yearly
  11. Report, monthly, all EA traceability analytics
  12. Publish a quarterly analysis of EA traceability analytics
  13. Publish a whitepaper on how to interpret EA traceability analytics
  14. Co-sponsor at least one project concept / idea per year with a business growth outcome based on EA-level transformation
  15. Sponsor at least one project concept / idea per year with a IT efficiency outcome based on EA analysis and / or improving one or more measured based on traceability analytics

The most important step here is that you are no longer defining EA as a complete, integrated, end-to-end, endeavor. You enterprise [business] architecture is complete by step 7 above. It’s done. The assumptions about how value in the enterprise is generated are defined. The definition of enterprise architecture is also re-defined as only the enterprise [business] architect + the planned traceability to other key assets. In this sense, your EA is complete.

Steps 8-10 ensure that your enterprise architecture is always up-to-date. But up-to-date shouldn’t be read to mean complete. The EA is up-to-date in the sense that the enterprise [business] architecture is up-to-date and you know the status of all traceability. Within the status of the traceability is the key to understanding how complete you understanding of systems is – including the completeness ‘alignment’.

Steps 11-13 ensure that the information in the EA is known, understood, and utilised for decision making. Steps 14-15 ensure that the enterprise architecture (and the enterprise architect) delivers value. It also allows for additional specific, targeted EA effort to be managed through the normal project approval processes.

If the following steps are followed – and this of course depends on you finding a ‘real’ enterprise architect to hire – you will be well on your way to best practice in enterprise architecture. More importantly, the communication and organizational engagement issues will be solved. If you have hired correctly, the enterprise architect will also be an enthusiastic and invaluable member of the IT management and / or executive team.

As far as EA becoming more valued than ‘management’, I’m not sure when this will happen. But if we can stop whining about how difficult it is to get EA established and get on with the job (see above process) we at least won’t need to defend our failed efforts anymore.

Powered by WordPress & Theme by Anders Norén