Is EA relevant anymore?
I was recently asked a set of EA-related questions that are probably on the minds of many CIO’s these days:
o Given the current and emerging set of architecture patterns (e.g., cloud computing, SOA, open source, etc…), is there a need for Enterprise Architecture?
o What difference does EA make for those CIO’s who buy ERP vendor platforms built on Oracle or SAP platform since once would assume that these platforms dictate a de facto architecture?
o Is the Zachman Enterprise Architecture framework as relevant today as it was 10 years ago?
o Give me 5 reasons why I should care about Enterprise Architecture.
In sum, is EA relevant anymore?
EA is more relevant than ever before!
A CIO’s most important responsibility is establishing an Enterprise Architecture program. Without such a program and its relevant models, it is nearly impossible to achieve the standard set of CIO goals:
1. Reduce cost
2. Achieve business – IT alignment
3. Improve business processes
4. Enable compliance and privacy
5. Enhance information security
6. Provide quality data and business insights
7. Innovate
EA – the what and the why
Enterprise Architecture is the set of models (i.e., illustrations, lists, etc…) that define the enterprise. Specific model examples are:
§ Business Process Taxonomy (BPT): is the art of classifying business processes into a hierarchical structure.
§ Information Technology Taxonomy (ITT): is the art of classifying information technology assets into a hierarchical structure.
§ Business / IT Alignment Diagram (AD): is a matrix of business processes and IT assets.
There are many more models that help in describing an enterprise’s design. (In fact, an Enterprise Architecture framework defines the superset of all relevant models.) However, these 3 models alone not only help to frame approaches to satisfying goals 1, 2, 3 and 4 from above but also give insight into:
a) What the business does and how is competes [via the BPT]
b) The complexity, maturity, risk profile and cost of its software and hardware environment [via the ITT]
c) The level and maturity of business/IT alignment
In essence, Enterprise Architecture is the uber-business management paradigm as it defines the enterprise from all relevant perspectives. Given the increasing complexity of information technology, it’s critical that CIO’s have such a framework in which to design the enterprise.
The top 5 reasons why ever CIO should care about EA
1. Enterprise Architecture models help to define the current state of the enterprise – i.e., what business processes exists, which application(s) enable these processes, etc…Without this baseline, it’s difficult to appreciate how to optimize the enterprise design, understand its technology cost structure, understand its technology risk profile, etc…
2. Enterprise Architecture models help to envision the future state of the enterprise – i.e.,
a. what business processes will the organization require in the future,
b. what technologies should be replaced,
c. which technologies should the organization invest in,
d. which applications should the organization migrate to the cloud,
e. how does the organization reduce its technology risk profile, etc…
3. Enterprise Architecture gap analysis defines the bridge from current to future state. With a comprehensive understanding of where the organization is and without a vision of where it’s going, how can one define the gaps between the 2 states? Thus, without such a gap analysis, the CIO is simply left to gut feel as to what should be done next.
4. Enterprise Architecture principles aid in establishing technology strategy and governance. A principle is a normative rule or codes of conduct. Without principles how can a CIO direct and govern the technology landscape? Example Enterprise Architecture principles include:
a. Use Common Applications and Services in order to reduce cost
b. Control Technical Diversity in order to reduce complexity and cost
c. Use Standard Integration Techniques in order to increase agility
5. Above all else, Enterprise Architecture models, principles and related artifacts help to communicate enterprise design and intent. Enterprise Architecture, when done correctly, helps employees, investors and all interested enterprise stakeholders, understand all salient aspects of the enterprise:
a. Its business strategy
b. Its business model (i.e., its set of business processes)
c. Its application portfolio
d. Its data
e. Its infrastructure
f. Its security paradigm
g. Etc…
The future of EA
Enterprise Architecture is still a relatively immature discipline; it’s only 30 years old. Other business disciplines and paradigms, such as finance, accounting and general management are on the order of 100 years in the making. As EA theorists, academics and practitioner learn and share more knowledge, the practice of EA will one day reach the theoretical vision – i.e., the uber-business management paradigm.
Posted By : Ray Bordogna


Thanks for keeping us EAs relevant. Good post about the need for EA to help CIOs. I was interested to see your top 5 reasons. Is this the order you would do this in?
Your approach has some similarities to John Polgreen’s. I wrote a post about Building An EA Practice …. http://leodesousa.ca/2009/11/building-an-ea-practice-what-is-your-process/ I am interested in your opinion on what I wrote.
Thanks very much,
Leo de Sousa
http://leodesousa.ca
Treating EA as a model development and communication process, as a major engineering challenge, does not have a good track record at the moment. While the CIO and Chief Architect might think that their carefully crafted models present a strong vision and plan for the future to the C-level and board, the C-level and board often have a different view. The major business transformations these plans require also have a startling habit of failing, taking massive amounts of CAPEX down with them.
While EA as an engineering challenge might have been the right approach 20 years ago, today this approach only has marginal value, and what was a useful doctrine seems to have become dogma. Business is the art of making a timely decision, and then making it work. EA needs to adapt to support this.
r.
PEG
Peter,
First, thanks for taking the time to comment. In effect, I agree with many of your points. “Carefully” crafted models often tend to be misunderstood by both the business and the board. In fact, I promote “express” enterprise architecture – one in which the blueprinting exercises are done in an agile manner and the models are simple in nature. In my experience, these simple pictures help to better bridge the proverbial business technology communication divide as well as better communicate vision and direction than a traditional 6×6 Zachman matrix. Having “tried” to implement Zachman and other overly elaborate frameworks, I came to the same conclusion that Big Al came to and which you reference – i.e., “insanity is doing the same thing over and over again and expecting different results.”
I enjoyed reading your “from doctrine to dogma” article. Certainly, the pace of business has changed such that the hackneyed “3-to-5 year” strategy is perhaps no longer relevant in many industries. However, the troops need some direction. Otherwise, every decision is, by definition, tactical. Several technology advisory firms are promoting “emergent” architecture to align with several business advisory firms marketing similar emergent business strategy methodologies. As for me, I like to split the difference between the “t+0” and 3 years strategic plans – i.e., a 1.5 year plan. I feel that this time horizon drives executives to model future scenarios, plan future responses and implement realistic programs.
I also concur with your simile: that the corporate IT application factory is like an albatross around the business unit’s neck. However, this will change as cloud computing is adopted by the business.
Second, thanks for sharing the CIO article with me. There are several threads worth commenting on:
“Company boards are often unable to understand and evaluate the investment required for large information technology programs.” In my opinion, this points to 2 issues. First, we still struggle to estimate the cost of large-scale, information-technology based transformation projects. Either we need better estimation tools, more experience or leverage the agile approach more often. Second, the typical company board members have a comprehensive understanding of finance, marketing and other traditional business administration disciplines. However, they often lack a solid foundation re: information technologies – what they are, how much cost, how to implement them, etc…I believe this ignorance to be a lack of education. Business schools should take on the responsibility to mandating some form of IT Strategy & Enterprise architecture as part of its core curriculum.
“The data strongly shows the CIOs believe they have presented a vision and a road map where the board and CEOs do not agree.” I believe that this vividly points to the urgent need for a common set of diagrams that clearly communicate the business strategy and its associated sub-strategies (i.e., marketing, finance, operations and information technology). Without such a gallery of illustrations, we will continue to experience the business/IT mis-alignment.
Leo,
Thanks for pointing me to your excellent summary of your EA program design and rollout. I also appreciated your comparison with alternative EA programs.
My post referred to some of the benefits of EA. I didn’t mean to imply a methodology or sequencing of activities.
This approach invariably leads to a customized EA methodology and deliverable set for each organization I advise.
Your comment, “EA is a cultural thing and needs to be implemented in the context and culture of an enterprise” is right on. There isn’t a “one size fits all” approach. In fact, perhaps that’s why early EA frameworks, like Zachman, simply prescribed a diagram taxonomy and eschewed presenting an approach for populating it?
I encountered the “EA” field when a former “Big 5” consulting partner threw Spewak’s Enterprise Architecture Planning book at me. I became fascinated with “designing the enterprise” and tried many different frameworks, methodologies and tools. These days, my approach is typically to:
First, define the objectives of the program (e.g., define a standard technology reference architecture, Rationalize our IT asset portfolio, Improve enterprise information quality, etc…)
Second, to list the superset of EA “governance” deliverables (e.g., EA Vision Statement, EA Definition, EA Framework, EA Team structure, etc…)
Third, to list the superset of EA “product” deliverables (e.g., Business Architecture diagram(s), Application Architecture diagram(s), etc…)
And, then finally select, sequence and prioritize the governance and product deliverables.
This approach invariably leads
Is EA relevant? I was surprised one day while attending an industry Healthcare conference by a senior business VP who claimed she just inherited the EA group for her firm. I had not provided my title as yet and she exclaimed that she had no idea what architecture is, does, or delivers. I decided that by offering my title “Chief Architect” would have been somewhat disconcerting for both of us so I asked her – “tell me what you view as your primary business challenges in your group”.
Since she managed the eCommerce and B2B areas of a healthcare provider firm, she believed her biggest goals were driving improved customer interactions by a unified customer experience, managing to HIPPA regulatory changes (e.g. HIPPA 5010, ICD10,etc) and ofcourse reducing costs.
So I asked “what is your biggest challenges or issues internally to achieve those goals”. Her first statement was related to understanding where to start and ofcourse concerns about cost and IT capability to deliver anything large like these type of efforts in her firm on time and on budget.
Well, after a few minutes of this I asked,”… what would say if you had the ability to understand what your current IT capabilities were, mapped to your business strategy and aligned with business process and supporting solutions so you could understand what the impact of the above goals were and had a roadmap with options to achieve those goal”?
She smiled and said yes essentially “… I have never seen any one who can do that….” .
I replied, “…not a single individual, but a group can…”. Somehow for some reason your CEO just provided you with the team to do it.
“You mean that EA team I just inherited”,she said.
“Yep”, I said, ” That is the charter of every EA team – you just need to ask them. If they are worth their salt they will jump at the opportunity. If they don’t know what you are talking about consider changing out the team members but NOT the function. You have an advantage over any othe group in the organization at this point. Use it well, and you will be rewarded. If you don’t believe me take some moments and Google Enterprise Architecture Mission – it includes business strategy, current and future state mapping, technology roadmaps, data/information architecture, etc. ”
Finally, she well what do you do for your company and I told her my job. She was surprised and said I guess no one every discussed EA’s capability to me. This is the first time I ever knew they could do that. My reply was essentially the same -”… EA can be on helluva of a strategic weapon if only we are asked to do more..” The struggle with EA is getting the right level of visibility and at times this is very difficult to do since corporate culttures and politics tend to get in the way.
EA is still very relevant, it struggles with Visibiltiy and beating Corporate culture and Politics.
Bottom-line: