I was asked, this week, about a page that I had put into Wikipedia nearly three years ago.  Far from being able to take credit for it, I discovered that many of the edits made since I put the page up corrupted it to the point of uselessness.  Alas, after changing that page back, I checked out my favorite page: Enterprise Architecture. 

And it was unrecognizable.

The entire page had been rewritten by a single person (Matthew Kern) who, apparently, believes that “Enterprise Architecture” == FEAF (The US Government EA Framework).  While I applaud Mr. Kern’s desire to include cited sources for his statements, his decision to ignore all of the prior content and contributions and toss out all of the compromises along the way seems both short-sighted and arrogant, to say the least. 

I endeavor to let the current author settle a bit, and then change most of the article back, but for the sake of documentation, I wanted to share the direction that Mr. Kern wants to take the Wikipedia article on EA.  Gentle readers, do you agree with Mr. Kern’s decision, or do you support my intent to revert to the original material?

Previous Opening Section (compromise text) New Opening section
An enterprise architecture (EA) is a rigorous description of the structure of an enterprise, which comprises enterprise components (business entities), the externally visible properties of those components, and the relationships (e.g. the behavior) between them.

EA describes the terminology, the composition of enterprise components, and their relationships with the external environment, and the guiding principles for the requirement (analysis), design, and evolution of an enterprise.

This description is comprehensive, including enterprise goals, business process, roles, organizational structures, organizational behaviors, business information, software applications and computer systems.

Enterprise architecture (EA) is a term first used in print in NIST SP 500-167 a US Federal Government Document from the National Institute of Standards and Technology) in 1989. It is currently a mandatory practice in the US Federal Government: OMB Circular A-130 describes enterprise architecture and subordinate activities in some detail, in response to the Clinger Cohen Act (IT Management Reform Act) of 1996 mandatory requirement for government organizations (enterprises) to have an "IT architecture". The term has subsequently (after first use in 1989 by the US Federal Government) been used in foreign governments and in commercial practice.

According to the U.S. Federal Government: "An EA is the explicit description and documentation of the current and desired relationships among business and management processes and information technology. It describes the "current architecture" and "target architecture" to include the rules and standards and systems life cycle information to optimize and maintain the environment which the agency wishes to create and maintain by managing its IT portfolio. The EA must also provide a strategy that will enable the agency to support its current state and also act as the roadmap for transition to its target environment. These transition processes will include an agency’s capital planning and investment control processes, agency EA planning processes, and agency systems life cycle methodologies. The EA will define principles and goals and set direction on such issues as the promotion of interoperability, open systems, public access, compliance with GPEA, end user satisfaction, and IT security. The agency must support the EA with a complete inventory of agency information resources, including personnel, equipment, and funds devoted to information resources management and information technology, at an appropriate level of detail."


What say you?

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

18 thoughts on “Wikipedia and the definition of Enterprise Architecture”
  1. The US-specific definition is fine to include, but a more generic definition is much more appropriate for Wikipedia. Move Government or vendor-specific definitions to later paragraphs.

  2. Nick,

    I like your generalised statement but I have to give Matthew some credit as the second of his paragraphs do describe the core process of EA quite well – that is, it mentions current and target states, transitions and roadmaps.  So I don't think we can necessarily curse his efforts.

    That said, his text is far to specific to US Government matters , particularly the first paragraph (for which i can see little value).

    Could you extend you definition slightly to include a basic description of the process for EA? That way, you may have the best of both worlds whilst sticking to an accurate, generalised core description.

    However I do sincerely agree with your complaint about being over-written – when reviewing/editing someones work, you need to consider the viewpoint of the original author and, out of courtesy if nothing else, make contact with them to discuss potential changes.

  3. Hi Mark,

    I agree that Matthew's updates do include the notion of present state, future state, and transition models.  I see no reason not to include those notions in the basic definition, as they are common elements for Enterprise Architecture practices.  (Note that not all EA frameworks describe these particular artifacts.  That said, I agree that functioning EA programs nearly always provide them).

    — Nick

  4. I would typically agree that non-specific is better. But is this case, the US government invented the term EA and there is a very specific FEA/F definition that is different from "commercial EA". So deference should be shown to the inventors.

  5. Hi Nick

    Many thanks for your efforts here: cleaning up this kind of mess really does matter.

    Apologies, but I'm going to have to be really rude here: Matthew Kern's 'definition' is not only garbage, but actively-misleading garbage at that. As indicated by its assertion early on about "IT architecture", it's clear that at best it approximates to the already seriously-inadequate (mis)understanding of enterprise prior even to TOGAF 8, let alone anything more recent. In an all too literal sense, it puts us back half a decade at least, and probably more. And given that Open Group, for example, is now working hard with TOGAF 9.1 to break the EA discipline out of the 'traditional' IT-centric box, this whole absurdity has got to go before it causes serious damage.

    A couple of people above have nodded vague approval at the inclusion of 'current state' versus 'future state', but I'm going to have disagree with that too, because again it's fundamentally misleading. There is no state: 'state' is an invention of worried project-managers trying to control something that by definition cannot be controlled. There is no future-state: by the time we get there, the world has changed anyway – especially at the current rate of change in technology and business-models and the like. And there's no current-state either: by the time we look at 'now', it's already moved on to another 'now'. It really is time that put that sad delusion out of its misery, and devise a better way to describe intent in relation to architectural change.

    I'm happy enough with the 'previous opening-section': it could do with a few tweaks, of course, but the core is all there: it's not constrained to any arbitrary subset such as IT or business or the dreaded (mythical?) 'IT-business alignment. It works. So please, do swap it back in again, as a matter of urgency: and some one, please contact Matthew Kern and read the Riot Act at him, so that he doesn't inflict his inanely narrow 'definition' on the world again?

    Thanks again, anyway

    — tom g.

  6. Hi Tom,

    I can count on you for unfiltered input, Tom, and I appreciate it.  While my words may be more gentle than yours, I assure you that my response to Matthew's updates were pretty visceral as well.

    I have already reverted the text (and cleaned up some of the duplication in the previous article) to improve readability.  I did add some text on current-state and 'target' state knowing that the practice of EA often includes that element but I added it as a third paragraph.  Please feel free to provide direct comments in the TALK page on Wikipedia if you don't like where I went.  Realize that Wikipedia is crowd-sourced but that crowd is filled with individuals, where real changes actually happen.

    I have attempted to contact Mr. Kern using three different mechanisms, with no response yet.  I will be collaborative and respectful and will honestly welcome his input.  I honor his desire and his bold efforts.  The results were not on par with the necessary level of quality needed by an often-quoted encyclopedia.

    — N

  7. To the person whose comment is signed "anonymous coward", you mentioned

    "But is this case, the US government invented the term EA"

    I'm comfortable stating the obvious… EA was not invented by the US government.  Anyone who wants to state that it was… should have a nice long conversation with Sam Holcman and John Zachman, who were having a coffee conversation on the goal of John's framework when John coined the term.

    The FEAF definition belongs on the Wiki page for FEAF, not the general EA page.  There are links to the EA frameworks page as well as links to each individual framework from the general EA page, so the reader has access to all of the data about EA from the perspective of different frameworks.

    — Nick  

  8. Nick – "I can count on you for unfiltered input, Tom" – uh, oops… sorry… 😐 – though thanks for the "I appreciate it". 🙂 And, uh, what I wrote above was the filtered version: apologies, I do tend to fulminate a bit when things are that far wrong… – though I'm really glad to be fulminating in your support, rather than 'against' you.

    On behalf of us all (or me, at any rate 🙂 ), many thanks again for your efforts on this – my turn to say "I appreciate it", I think?

  9. Nick,

    Thank you for bringing this to our EA community's attention.  I very much prefer the original text and find that Mr Kern's version is more a description of the FEAF than our various approaches and practices that are equally valid.

    Please let me know what support you need to revert the text.

    All the best, Leo

  10. Hi Leo,

    Your comment is sufficient for now.  It stands as public documentation of community feelings.  This provides some basis to Mr. Kern (and others) that I'm not challenging his edits on the basis of irrationality.

    I have already reverted his edits and documented my rationale, including pointing to this blog.  I've had one exchange with him and am waiting further for feedback from him.

    — Nick

  11. I support your decision, the FEA should be a separate page.

    I will reiterate a semi-related recommendation I've proposed to you and other EAs in the blogosphere STOP COMMENTING on Federal EA.   The more I read commercial EA's comments the clearer it is that you do not understand what we are up against, the same goes for fed EAs, your job has very little in common with someone working at Microsoft, Apple.. .  The government is not a business, EAs seem to like analogies, so maybe one of us are veterinarians and the other is medical doctor, that's how tenuous the connection is IMO.

  12. Hi Joe,

    I have not heard you make that comment to me before.  I will have no difficulty respecting your wishes, since I don't largely comment on the FEA now.

    I find the tone of your request curious.  Our lead EA methodologist in the Microsoft IT Enterprise Architecture team is a former Federal EA (HHS, I believe) and is well aware of FEA rules and guidelines.  We are actively learning from him and many of our practices internally are based on experiences from the trenches of federal EA.

    From a methodology standpoint, the FEA is fairly strong and stands as a useful mechanism for understanding EA.  That said, the FEA is not oriented around strategy, since the mission and vision of federal departments, as well as many elements of structure and governance, is described by congress and is written in myriad, sometimes conflicting, legislative edicts.  That creates a very different environment for Enterprise Architecture to leverage and use the artifacts that are produced.  

    I'd like to discuss this disconnect further.  If you are willing to reach out to me personally, via this blog, I will respond and perhaps we can set up a Skype call, where you can share your perspective.  I am honestly curious about the kinds of messages that you are hearing from the commercial community.

    — Nick

  13. I agree with you, Nick.  You should redo the page.  You should take down what Mr. Kern did.  You work for Microsoft, after all, so therefore, you have greater authority and qualification to be writing technological articles over on Wikipedia.  

Leave a Reply

Your email address will not be published. Required fields are marked *

9 − 6 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.