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.