Do Today's Enterprise Architecture Practitioners Get at all Close to the Original Vision of EA?

In most organizations, EA has been delegated to either the CIO or CTO. Moreover, most EA efforts focus on infrastructure and are completely devoid of the impact from the applications. I mean, geesh, if you're gonna bastardize the thing at least focus on the relative importance of the entire environment, not just a subset.

In order for EA to be successful, it needs to report the the COO or CFO and it needs to be supported by all top line business leaders in the organization. Moreover, these leaders need to be willing to relinquish ownership to other lines' leaders if the EA demonstrates that doing so is to the benefit of the entire company.

Given my last statement, and having fought the hard battle to do EA right for the past 10 years, I'm relatively sure that no one wants to "open the can of worms", so they focus EA efforts on what they anticipate to be the biggest hurdle to efficient operations, which is IT.

Oh yeah, one more thing, EAs are supposed to draw pretty pictures depicting the IT mess, but should not actually express that the picture is dysfunctional.

The intent is mostly to understand and take a holistic approach which is enterprise wide but I guess with pressures from all quarters and other political factors, vendors included, EA's tend to overlook certain details. Having said that - there are many aspects that we need to look at before concluding (to name a few):

• 1) Who is sponsoring the initiative - IT or Business
• 2) The time-frame allocated
• 3) Participation from the internal folks - top level
• 4) Its tactical or a strategic initiative
• 5) The target audience - at the end of the day!

I agree with JP on the eye-wash part as often pretty documents are presented which may not correctly represent the current state of affairs and above all may not even benefit the enterprise in the long run. So, yes - in a way it starts with a holistic approach but ends up being an IT initiative!

YMMV, but I find that there's a pareto principle at work. 20% of EAs that I've met really "get it". The problem is that the overlap between those EAs and organizations that "get it" is often rare.

Although changing the reporting structure would be a fix, I dont see a lot of Enterprises taking the "Bait" so to speak. We absolutely need to find folks who can understand the whole picture, they are extremely rare.

Not to take a pot shot, but there's a phrase that has bugged me in the SOA Manifesto that strikes me as part of the problem:

"Pursue uniformity on the outside while allowing diversity on the inside"

This phrase seems to abdicate the responsibility of EA to maintain the "big picture"... and sticks SOA into a holon. (A Holon is a term from complexity theory that signifies a part of a whole that itself appears to be a whole). Inside of what? Outside of what?

If you consider for example the concept of service "reuse" one would hope that a diversity of different consumption patterns would use the same underlying service. This would be diversity on the "outside" wouldn't it? Making vague phrases about inside and outside without specifying an antecedent just adds more fuel to the conflagration that is Enterprise IT.

I'd like to see, as I think all of us would a shift closer to the original conception of EA--someone needs to maintain the "big picture" in all of its bigness.

My 2 cents,
Miko

My 2 cents..

Today more and more EA is mistaken as Infrastructure design & architecture. The main point here is to differentiate between the two. Enterprise Architecture term is used very loosely these days. The overall EA is step away from drawing boxes and pigeon hoing in a solution set, but think of the overall impact of not only today but also incorporate strategic roadmaps too.

I have met a very few EA's who actually poractice the EA framework, rest are all infrastructure architects calling themselves as EA.

Ajay

I would say it really depends on what you call your "Original Vision of EA". If it is Zachman, then I would say we tend to do the parts of the framework we are familiar with (typically EA is run out of IT). On the other hand, if you were fortunate to have EA start elsewhere in the enterprise (it may still be housed in IT), then there is probably a vision (that isn't just technology) that EA can work with.

For us, our EA practice started from a strategic plan for learning, teaching, research and business. The underlying culture of our EA practice always embeds our published strategy. The other key for us was to embed EA practices into existing processes like project management, change management and technology procurement.

Leo

Poor little enterprise architecture - it’s been around for years but has yet to make a significant business impact - the perennial bridesmaid. In theory, it sensible - document and understand the enterprise from a variety of stakeholder perspectives (e.g., business owner, application owner, etc…) so that all stakeholders know what exists, how it all works together (current state) and how it could work together (future state). However, in practice, EA often fails miserably.

First, there’s no standard EA definition. 10 people give 13.3 unique definitions.

Second, there’s no standard EA framework. Countless ones exist, with one more contorted than the next.

Third, people expect the business to participate. The business will never participate in an EA programme. Never has, never will.

Fourth, and most importantly, engineers try to “engineer” the enterprise architecture - they aim to document every infinitesimal detail from every angle. And, therein lies the problem. An enterprise is too complex (people, process and technology and dynamic (new regulations, new competition, etc…) to model using current modeling notation and tools.

Perhaps the original enterprise architects led us down the wrong path? It’s my understanding that their original intent was to understand why “Industrial Age engineering projects” (e.g., trains, planes, automobiles) were primarily successful yet “IT engineering projects” were often disastrous. From this analysis they marketed persuasive metaphors like “city planning” and “architecture blueprints” in suggesting ways to better align the enterprise and information technology. Although their vision is compelling, the reality is that EA is really about “enterprise art-itecture” – communicating current conditions and future intent through simplified renderings. As they say, a picture is worth about 1024 bytes. A “pretty” picture is worth even more.

Yep! EA is still trying hard to be understood - but I think slowly people are beginning to cotton on.

I believe one reason it is not understood by more organisations is because those organisations that "get it" generate massive competitive advantage from it. And they rightly do not want to give that advantage away to other less informed organisations.

From what I see EA seems to be more accepted and used in government bodies than private companies – USA, South Africa, Singapore, Korea, etc, etc. Maybe we just hear more about these because governments don’t really compete with each other and therefore have nothing to hide.

On another tack, there is a new framework (oh no not another one!) that takes a much more pragmatic approach. It was released around a years ago and V2 will soon be released.

PEAF – Pragmatic EA Framework – (www.PragmaticEA.com) and it’s FREE to use for Individual Consultants, End-User Companies, Government Bodies and Academic Institutions.

If v1 blows your socks off (as one senior and well respected industry analyst said) v2 will blow you legs off…

The original vision was about the entire Enterprise. Nevertheless Zachman was an IBM-er, looking at how to build IT systems with the rigor of the airplane industry. So the vision was directed to IT which embraced it gladly, liberally using terminology like Enterprise for its technologies: EAI, ESB, EJB...

The existing EA "frameworks" help but not much. In fact, are they really frameworks? According to whatis.com, a framework is "a real or conceptual structure intended to serve as a support or guide for the building of something that expands the structure".

Zachman's matrix tells us what the cells are not how to model them. It helps us think about EA (or any system for that matter) but not how to built the EA which is the job of the architect. The matrix stands for a taxonomy to store artefacts rather than for an Enterprise structure which is what we need from a framework.
TOGAF serves us with a simple process (we use it every day to move from point A to B) with delivery checklists for the known layers. In fact, it may be called a process "framework". Views are considered in isolation. No navigation, impact analysis or integrated view of the Enterprise is possible. Also, for TOGAF, the business architecture is an afterthought, a late addition to IT. TOGAF was created by the Open Group an IT forum, with no obvious interest or expertise in business matters.

Neither TOGAF nor Zachman provide a generic Enterprise structure, as a framework should do, where components and artefacts fit back into the EA frame. As such, even if widely adopted, the existing "frameworks" cannot ensure consistent, predictable or repeatable results, fact confirmed by practical results. People, aware of the dire situation, are bold enough to come with their own EA definitions and easily claim the rank of Enterprise Architect in business or IT.

EA is currently driven by IT for IT. Infrastructure architecture is predominant because it can be done separately. But no matter who drives or sponsors the EA, it would hardly deliver, except in cases where the architect builds an own approach and framework claiming compatibility though with de facto standards.

The EA, as a concept and asset, is still valuable. It should start though from modelling the business. Then continue with the alignment of the technology and organization resources.
I discuss at http://it.toolbox.com/blogs/ea-matters/ a new approach.

An interesting question. I have seen people and organisations who say they do EA but they really doe EITA. For me it is all about perception. EA does usually start in the IT function of an organisation and what is created is EITA. However to add to this the Business Architecture elements to do true EA is all in the influencing and communication of the architects do the EITA.

The approach I tend to use is to talk about how we can create more value for an organisation and what we need to do. I never mention the words EA, BA or Architecture. These words tend to have an affinity to the IT profession. I talk and show what we can do to create value, people get it and do it. The organisation doesn't know it but it ends up doing EA.

This to me is more important than having the EA badge. It is all about the outcomes and the value delivered rather than the PR exercise of saying "We do EA"

Sorry for answering so late. I was out of office participating in a Bridge tournament. In order to succeed in bridge you should see the whole picture. The picture is dynamic and changing during the game. The same principles, namely seeing the whole dynamic changing picture, are applicable to Information Technology. The realization of the principles is Enterprise Architecture. Due to growing complexity and distributed systems EA is a must (as well as SOA). However, EA evolution is gradual. Gartner's technology evolution chart is also relevant to EA. Original EA was in the Architecture (Technology) Trigger and Peak of Inflated Expectations stages. I think we are now in the Trough of Disillusionment stage. Like other commentators, I think that good Business Architecture is rare (actually I never seen a good Business Architecture). The reason for that is that architectural charts are abstract while programs code is concrete. EA is composed of different layers, and I think that good Data Architecture, good Infrastructure Architecture and good Application Architecture could be very useful, even if no adequate Business Architecture is available.
In order to reach the Slope of Enlightenment stage we need a good Business Architecture in addition to the IT Architecture layers and a adequate synchronization between the layers. Reaching that stage will require advancement in solving the more general issue of Business and IT alignment.

For my part, I find that the practice of enterprise architecture too often tends to devolve into the day-to-day business of standards and technology selection or in exercises in developing far-ranging strategic roadmaps that are often divorced from business realities due to (sometime necessary) divergent priorities between architects and business leaders.

That's not to say that enterprise architecture isn't an enormously useful discipline. I believe it is but not necessarily in its present form.

I explored this in detail in recently in a post here on ebizQ:

http://www.ebizq.net/blogs/enterprise/2009/09/fixing_enterprise_architecture.php

You can get my sense of how we, as modern EA practitioners, can and should deploy in the trenches and use our wide area vision and possession of the big picture to drive business improvement and opportunities more locally and with more responsiveness. So to with being good at responding to change instead of following a fixed plan and heading down the path of agile models of EA. The discussion of so-called "emergent architecture" is a valuable direction I think.

But I don't think enterprise architecture in its present form is going to adapt quickly enough. And classical EA provides enough value in its present form to continue going on its current course for some time and this is probably good news for our profession. But it won't last forever. So I welcome improvements to the art and science of EA such as TOGAF 9 to give us a clear, practical, and unifying influence to work with.

That said, I don't think the original vision of EA has as much attraction as it used to and we are beginning to see how we can do much better than we have in the past.

(sorry for the late response - I wanted to talk to some of our senior EA practitioners before responding)

We see many companies developing the models and descriptions that provide this “understanding” that you ask about. Unfortunately, EA is having problems because this knowledge is not being focused on the vision and goals of the business. A number of the EA programs that we are familiar with have not made a significant impact on the corporation’s bottom line.

We feel the problem lies in the interpretation of the original vision. Many EA programs have decided to develop an analytic toolset, not a solution that has value to the corporation. It is reasonably easy to go down this path. The TOGAF, Zachman, DoDAF, etc. frameworks are all descriptions of how to build their version of this analytic tool set. Not one of them spends much time on how to apply it.

We recently asked a Chief Architect at a large corporation, what the goals of the EA program were and how they were being measured. The response was a description of a rather abstract set of targets with no short term objectives and no measures at all. This is a typical illustration of the EA landscape – a lot of effort to develop an EA toolset that provides little to no measurable impact on the corporation’s bottom line.

As consulting enterprise architects, we worked to take that abstract set of targets and focus them on stated corporate goals and less visibly stated problems and issues that the business was working to address; for instance, the goal of being first to market. We refocused the analytic tool to address a series of questions that senior mangers asked about time to market. We also identified several of the “constraints” that make it difficult to achieve the time to market goals.

This program will succeed because it provides a solid analytic tool that can demonstrate measurable impact to the corporation’s bottom line.