 |
| Photo credit: clappstar |
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.
Source
|
Definition
|
Objective of EA
|
Process or Design, and Key Elements
|
Gartner
|
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
Structure
|
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
|
Design
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
|
Design
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
|
Design
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, http://www.gartner.com/it-glossary/enterprise-architecture-ea/
[ii] D.J. Nightingale
and D.H. Rhodes, MIT ESD-38J Enterprise Architecting, Course Notes, 2007
[iii]
MIT CISR’s Enterprise Architecture website, http://cisr.mit.edu/research/research-overview/classic-topics/enterprise-architecture/
[iv]
TOGAF version 9.0, http://www3.opengroup.org/subjectareas/enterprise/togaf
[v]
Architecture is architecture is architecture, John A. Zachman, http://www.zachman.com/ea-articles-reference/52-architecture-is-architecture-is-architecture-by-john-a-zachman
[vi] http://www.enterprise-architecture.info/Images/Presentaties/How%20valuable%20is%20EA%204U-06-2005.PDF
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.
ReplyDeleteMIT 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.
Hi Victor, thanks for your comments, it is interesting to read your thoughts on this subject.
ReplyDeleteI 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".