Monday, March 26, 2012

Five Hurdles in Implementing EA

Photo credit: clappstar
What are the hurdles organizations face when implementing Enterprise Architecture?  This is the first part of a five-part series exploring this question.

Hurdle #1: Differing understanding of what EA is

“Enterprise Architecture” is big term: different people have different understanding of what it means.  When the term is mentioned, some people are referring to a design (e.g. have you updated your EA?), some are referring to a discipline (e.g. I am practicing EA), and there are even a few who use it to refer to physical systems.  An anecdotal example comes from my work experience: I was on a project to IT-enable an organization to improve the organization’s effectiveness.  My colleague asked me to “figure out the enterprise architecture”, while he worked on the project objectives and getting buy-in.  This was not an isolated incident, but I found many who would equate the term “Enterprise Architecture” to “complicated technical stuff” that computer software developers deal with.  Not only so, even EA experts have different definitions.  Figure 1 lists six definitions of EA from authoritative sources.  I tried to group them to tease out similarities, but they still look different from one another.

Objective of EA
Process or Design, and Key Elements

The process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise’s future state and enable its evolution.[i]
Realize business vision

Process: Create, Communicate, Improve

Key requirements, principles and models
MIT’s Nightingale and Rhodes (on Enterprise Architecting)

Applying holistic thinking to design, valuate and select a preferred structure for a future state enterprise to realize its value proposition and desired behaviors.[ii]
Realize business vision

Process: Design, Valuate, Select


MIT Center for Information System Research
The organizing logic for business process and IT capabilities reflecting the integration and standardization requirements of the firm’s operating model.[iii]
Realize business vision


Business process, IT capabilities,
Organizing logic
The Open Group Architecture Framework (TOGAF) version 9.0 (on Architecture)
A formal description of a system, or a detailed plan of the system at component level to guide its implementation; and the structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.[iv]
Guide system implementation


Component level plan, Structure, Inter-relationships, principles
John A. Zachman
The total set of intersections between the Abstractions and the Perspectives that constitute the total set of descriptive representations relevant for describing an Enterprise.[v]
Describe an enterprise


Abstractions, Perspectives

Institute For Enterprise Architecture Developments (IFEAD)
About understanding all of the different elements that go to make up the Enterprise and how those elements inter-relate.[vi]
Describe an enterprise

Process: understand

Elements, Inter-relationships 
Figure 1 EA Definitions from Difference Sources

Reasons for Difference

I see two main reasons for the different understanding and definition.  Firstly, architecture is not a simple concept.  A quick look at the definition of architecture on Wikipedia showed six definitions[vii], and like the term “Enterprise Architecture”, it can refer to a design, a discipline or a physical object.  Furthermore, many different words can be used to describe its key elements.  The definitions in Figure 1 used these words: Key requirements, organizing logic, structure, perspectives and inter-relationships.  Secondly, Enterprise Architecture came out from IT, thus it is often confused with IT system architecture, relating back to the earlier point that people equate the term to the ill-defined concept of “complicated technical stuff”.  The confusion is worsened by the fact that EA is often used to solve IT system related issues, as IT systems have become ubiquitous in business environments and they are often complex and difficult to understand.

Conclusion and My Definition

Without a common understanding within an organization of what EA is, it is very difficult to form a common goal to build towards and thus making it hard to implement EA. 

For the purposes of subsequent discussions, I will provide my definition and I would be happy to get feedback on it.  I define Enterprise Architecture as: 

"A discipline that facilitates the active designing of enterprises, through providing clarity into the enterprise’s key components and their key interactions."

[i] Gartner’s Enterprise Architecture website,
[ii] D.J. Nightingale and D.H. Rhodes, MIT ESD-38J Enterprise Architecting, Course Notes, 2007
[iii] MIT CISR’s Enterprise Architecture website,
[iv] TOGAF version 9.0,
[v] Architecture is architecture is architecture, John A. Zachman,
[vii] Wikipedia’s page on “Architecture”,


  1. Ming Fai, the different definitions and understanding of EA are all valid in their own level and perspective, from top-most business operating model all the way down to guide IT system planning and implementation.

    MIT Nightingale and Rhodes' definition is focus on how to design a more efficient and responsive business operating model to tackle business challenges and take advantage of opportunities, whereas Garnter's definition focuses more on how to translate the business operating model to systems (including IT systems and organization/human) at business vision level, it identifies required changes at business strategy level.

    Anyway comes back to your definition, I felt all architecture ultimately address the same concern irrespective of the level and perspective, it is always trying to "organize its constituent parts and its relationship among the parts, and the principles guiding its evolution". So the "part" can be organization, business unit, human, or IT system, so my definition is more in line with TOGAF definition.

  2. Hi Victor, thanks for your comments, it is interesting to read your thoughts on this subject.

    I agree with you that the different definitions are all valid in their own ways. However, these are definitions by EA experts, so CEOs and CIOs will likely define it differently and in many cases wrongly. Regardless, my takeaway is that it is key for a EA team (and their extended teams) to agree on their own definition of EA. If not, members of the team will be building towards different end-points based on their own understanding.

    Separately, your point about architecture ultimately addressing the same concern irrespective of level and perspective is true. What it made me realize, is the challenge might not be in defining EA correctly, but in creating a definition that all in the team can understand. Concepts like "constituent parts" and "relationship among the parts" might be unclear to many; and we need to be careful that everyone is comfortable thinking in terms of abstractions like "parts" and "enterprises".