Freigeben über

When IT Architects Describe EA to other IT Architects

  • Artikel

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

Comments

  • Anonymous
    September 02, 2011
    All of the points you articulate make a lot of sense to me, an aspiring EA who recently read the TOGAF guide you refer to.  Whilst reading the guide I often asked myself two questions:
  1. How does an EA actually make use of this framework?
  2. Is this really an EA framework? Time and time again I concluded the answer to the latter question must be a no.  What about the first question? My thirst for answers actually lead me to knocking on the door of a few EAs that work for the financial services organisation that I work for.  Unfortunately I never really felt like I received a succinct answer. Both Adrian's and your posts are eye opening and insightful, thank you for sharing.  If you manage to find better TOGAF literature out there please let me know!

  • Anonymous
    September 06, 2011
    Well, quite harsh a criticism, for a piece of work that is basically a 'well-meaning' contribution to the 'How to explain TOGAF'-category, not even 'guilty' to the offense of 'false or misleading labelling': The author states very early on in his publication, that the term "Enterprise Architecture" is being used and meant in the sense of "Enterprise IT Architecture". Or as Mr. Keller has put it  in the (German) title of a book, he authored back in 2006: It's about "IT-Unternehmensarchitektur", literally "IT Enterprise Architecture" (i.e. "IT" being "the Enterprise" in the focus of 'architecting' activities). Me too, I  feel a bit uncomfortable with the ' trials and tribulations' expressed by many in the 'blogosphere' around the 'right interpretation' of Enterprise Architecture, what it is or should be. However,  what gives me an impression of 'mission impossible' here, is a kind of 'pride and prejudice' attitude some authors exhibit, when blaming others for 'looking at it in the wrong way'. To me, this is simply the sort of 'locked-in' thinking we, as the community of practicing EAs (at least 80% coming from somewhere within IT), need to overcome. It is not my intent, to counter your criticism, but simply to ask a question: Do you think, with the 'right' definition of "Enterprise Architecture" we're 'done'? And could you please share your "Definition of Enterprise Architecture" with us, just in case you have it? And I am not joking here, believe me, as I think I don't underestimate the degree of complexity handling, conviction changing and consensus making necessary for this very task at all - being pretty much involved in the evolution of TOGAF, I continuously try to remember people to the fact, that TOGAF as a industry consortium consensus specification has embarked on a (admittedly, rather long) journey towards 'the new paradigm', being the evolution from 'Technical Architecture' (thinking) towards 'Enterprise Architecture' (thinking) as stated, but rarely cited, on this page since December 2002: www.opengroup.org/.../index7.htm

  • Anonymous
    September 26, 2011
    @Robert, With all due respect, a well-meaning guide that misinforms is counterproductive.  I have defined Enterprise Architecture in prior posts, including a job description.   Do I believe that we are done when we have the "right" definition?  No.  Of course not.  EA does not have a definitional problem.  If you ask an actual EA what he does, you get a good definition.  The problem is that we are asking the wrong people. The role is clear to someone who has performed it, just as the role of physician is clear to a physician.  However, just as a physician would be rendered a disservice if his role were "defined" by a biologist, I do not believe that the role of Enterprise Architect gains in clarity when it is described by a person with no understanding or experience in the role.   Understanding the role is the first step but far from the only one.   Describing the scenarios that an Enterprise Architect interacts with, describing common practices, and offering templates for improvement... this is the stuff of frameworks.  This activity is necessary in order to build a common understanding that allows progress in the profession.  That is the practical goal of a framework, although the Open Group has made the mistake of allowing non-Enterprise Architects to describe their work as Enterprise Architecture, thus contributing to the confusion reflected in Mr. Keller's guide.   Getting consensus among biologists about the definition of medicine is difficult, and unnecessary.  Sometimes, the answer is to ask fewer, more qualified, people.   That said, TOGAF has made strides.  It is about 25% there.  Most of the really obvious mistakes have been removed.  It is a solid yet partial product.   Mr. Keller's guide is not so fortunate.  It represents a poor contribution to both EA and EITA, and should be actively avoided by both target audiences described within it.   My criticism stands.  That said. I welcome your opinion and am grateful to you for sharing it. --- N