When IT Architects Describe EA to other IT Architects

Sometimes, I have a hard time being upbeat about the emergence of EA as a profession.  This felling is especially acute when I come across a slick, well-prepared guide to Enterprise Architecture, written by an IT Architect, that is incomplete, inaccurate and/or misleading.  That happened to me today.

The guide is written by Wolfgang Keller and was published in its final form in November of 2009.  His guide is titled “TOGAF 9 Quick Start Guide for Enterprise Architects.”  The document can be found here

Most Enterprise Architects have their roots in IT organizations, and there is a great deal of interest in both the role of EA and the TOGAF framework’s stated goal of becoming a framework useful for Enterprise Architecture.  That said, most practicing Enterprise Architects have some level of difficulty applying the TOGAF to their work, largely because it is a guide to producing Enterprise IT Architecture (EITA) artifacts, and not EA artifacts.  One such architect, Adrian Grigoriu, writes about his experience applying TOGAF to EA in his blog (link). 

EITA is to EA what a Biologist is to a Physician… a respected colleague with a similar area of concern, but totally different role.  Since TOGAF is a framework for EITA, it can be tough to expect an EA to use it.  Now, I know that the Open Group is making progress, and I have acknowledged that progress in past posts.  But let’s face it: TOGAF is about 20% there.  It is not wrong… just wildly incomplete.  Learning TOGAF to do EA is like learning to fly a business jet in order to take on combat missions in an F16.  The skills you’d gain are somewhat useful, but not even close to being sufficient.

So when I opened up Keller’s guide, I expected to see some tables showing typical scenarios for an Enterprise Architect, the ways in which a framework can support EA, and an indication of the gaps that TOGAF still has in providing that support.   That is not what I found, and I’m not happy with what I saw.

  1. First: it was not written by an EA or even listing EAs as contributors. There is no indication whatsoever that the author actually has ever worked as an EA. It would be like a nurse writing a guide to the Physicians Desk Reference.  Worse, “experienced” Enterprise Architects are supposed to use this.  What does it say about the student if he chooses a fool as his teacher? 
     
  2. Second: The author describes Enterprise IT Architecture, not Enterprise Architecture. He doesn't know, nor has he taken the time to find out, what an Enterprise Architect actually does. It is one thing to be speaking outside one's area. It is another to describe the role in completely inaccurate terms.
     
  3. Third: The author, while attempting to describe the much more limited role of EITA, gets that wrong as well. The author has placed the role of EITA in an untenable and ineffective position with no authority (or even role) in program portfolio prioritization and funding. If that were my job as an EITA, I’d quit.  I have seen EITA’s struggle and fail, time and time again, in this role.  This makes the guide not only a bad way to access TOGAF, but also provides some elements of seriously bad advice for any IT architect.
     
  4. Fourth: His document misrepresents itself.  Only about one third of it is a guide to using TOGAF.  There are two other parts.  One is a description of software architecture (including a history lesson), and the final third is a supplement that attempts to fill in some perceived gaps in TOGAF. He attempts to address two specific gaps: Formulation of IT Strategy, and IT Portfolio Management. He makes an attempt in both cases, and I will credit him for the effort.  The output is average.  Were TOGAF to include his supplement sections, it would be helpful to a small number of EITA’s, but not any EA’s that I know.   
     

There are two use cases for reading the document, outlined by the author: (a) An Experience EA wanting to understand TOGAF, and (b) A Student wanting to learn EA and TOGAF.  For both cases, the guide fails to be practical and, in many ways, is actually harmful.  I cannot recommend this document for either case.

Of course, that means that there is still an opportunity for an actual Enterprise Architect to do what Adrian tries to do, and provide insight into how TOGAF can be used to in the practice of Enterprise Architecture. 

If you know of one… please let me know.  If you develop one, I’ll be happy to review it.  (If you’d like my feedback to be private, let me know before you publish it and I will do what I can to provide feedback in a timely fashion.  Once it is published, my feedback on the published version will be public as well.) 

Technorati Tags: Enterprise Architecture