EA - Enterprise Architecture or Extreme Aggravation

Hi Andrew,

This article is very interesting and I fully concur with your view of associate meaningful job titles to enterprise architect role. I am in the process of migrating from team lead/ application architect position into an enterprise architect role and am thinking how to quantify value of an EA? What you have suggested is great in that you clearly get a sense of what an EA does by looking at his/her title. "EA" is too vague any way in my opinion too.
Thanks for this great blog.

Having spent 5 years as a partner with one of the people considered to the "father of enterprise architecture", and having delivered the EA at over a dozen Fortune 100 companies, I have a pretty good idea what EA should be (at least initially) defined as. However, I have struggled for many years to come up with an adequate analogy that can be quickly and effectively communicated to anyone.

The analogy that I have found to be most understandable, is the following; If the CIO is the conductor of an orchestra, made up of strings (communications), brass (software), percussion (infrastructure), woodwinds (security), etc. then the EA role is the composer - the one that writes the musical score that allows all the sections to play together to create harmonious music. The inputs to this orchestrated plan for the business are strategy, legacy environments, budgets, skills, and future trends.

Enterprise Architecture fundamentally results in a "system of systems" view of the environment, solving a business and management problem.

Technology architectures are a "system of components" (where systems produce stand-alone value, and components have to be composed into a system to produce value) - solving a technical set of issues. Software, data, network, security, ... architects fall into this category, optimizing their silos.

Most of the so-called EA roles out there are technical architects, and not true enterprise architects. The EA role deals with corporate strategy, business initiatives, the technical domains (platforms, storage, communications, application development, packaged software, tailored applications, databases) process and methods, staffing/skills, and organizational design, and how they should all fit together to enable business value.

Historically, software was NOT the center of the universe (enterprise) - the delivery of IT service capability was. This has been lost by many technocrats, relegating the EA leadership role to a glorified programmer. The Problem - relatively low dollar (software / data driven) architecture efforts typically drive the bigger dollar IT infrastructure investments – often not the best approach, nor the one that can benefit a company the most.

@Mahesh - Thank you for your comment. You raise an interesting point about quantifying the value of EA. Some thoughts on the topic are here: http://infosysblogs.com/ea/2008/05/quantifying_the_value_of_enter.html

Andrew,

You raise some excellent observations at a time when there is a recruitment spree for Enterprise Architects. Almost wished you had more delayed flights for more blogs like this, but think I will spare you of that trauma.

Architect is best defined going to first principles of home building and separation of concerns (plumber, electrician, mason, etc) and the architect taking requirements, designs, sourcing, etc.. and orchestrating to the finish. Many unseen items like risk and budgeting are taken into account. To a very limited extent this is also true in the case of the symphony conductor mentioned. However, in most of the above cases the designated leader is chosen and the governance laid out in advance.

Enterprise Architecture in the IT environment is a different animal. The size of the need defines the architect. You mentioned a few interesting ones. To a certain degree the “architect” title is given to entice the candidate to take on the seemingly impossible task. The challenges follow immediately as the governance is not laid out and appointed leader quickly plays a mediation and cajoling game.

EA is maturing and the tooling and getting the end to end process more connected. By far the architect’s biggest task is the ability to bring a team from ambiguity into convergence and lead them to the end result.

**** Horizontal Roles ****
Enterprise Architect - platforms, storage, data, application, packaged software, development tools, data structure and standards, security, enterprise management (operations), methods, staffing, organizational design, business strategy, business initiatives alignment.

Solutions Architect - the same set, but not for the enterprise; for a solution; may not have the business acumen and strategy expertise.

Not the deep specialist in any one discipline, but well versed in all. Able to effectively communicate complex technical issues to technology illiterates as well as domain architects, coordinating understanding across domain areas.

ALL architect roles must be able to deal in abstract, conceptual views, and be able to instantly switch to concrete implementation approaches - this point is really key to a person's ability to transcend the technologist's role, into a architect.

**** Vertical Roles ****

Domain Architects - deep understanding of their domain area, be it application, data, network, security, etc.

2 levels - one that has an enterprise view, albeit limited to the technical discipline; the second, a product focus.

A model I have found that works (and have implemented in a couple Fortune 20 companies) is a Community of Practice approach, with 3 CoP environments; Hardware (network, platforms, storage, etc.), software (applications and data), and Operations (Enterprise management and security). Domain architects fit in one of these 3, solution and enterprise architects span all.

An interesting analogous point is a very similar distinction exists between PROGRAM management and PROJECT management. Program management is similar in scope to an enterprise architect; project management is similar in scope to a domain architect.

My $0.02 worth.......

I belive Enterprise Architects are those who come out with ideas, strategies, process and structures etc for Transformation of Enterprises for better performance, market penetration, and growth as an organization.

Transformation Service consulting can be done by such Enterprise Architects, who have to avoid nitty gritty or business pains, but look at how a broad transformation could be realized by certain drivers or levers. Only when that is agreed and actual work started, solution architects etc come in to go into individual phases or pain areas.

This is my first posting and I hope I am communicating properly.

Great Topic to think through, but one thing I am wondering with SOA and Web 2.0 emerging as the next gen solutions for all those older enterprise Integration ,Infrastructure issues.
Just to make it simple, there shouldn’t be architects specialized in thinking in one zone but Architects who think in multiple zones like ROI, Social/collaborative networks (web 2.0) built on SOA with enough consideration to virtualization, Grid computing and security ..........In today’s world it is more important for an Architect to draw out a Facebook or a Google kind of technical business spec than any time before ..............

@ Suneel
Agreed. My original post intentionally shows the extremes of types of EAs and in reality overlap. The 'ideal' EA would of course be able to cover all dimensions!!. The increasing importance is towards 'extraprise, collaborative architects with a business and consumer orientation' with an understanding of how things work now in their context. This will increasingly include the use of web 2.0/enterprise 2.0 concepts (and beyond), including social networks. Another point to ponder is how WOA and SOA could interrelate. Sort of like thinking of WOA for Software As A Service and SOA as originating from Software As A Service within the organisation.

Some more architect titles - Enterprise Business Architects, Enterprise Integration Architects, Enterprise Security Architects.. some of those that come to mind.. Thinking of the merger and acquisition scenes, there would be more such roles, specific to consolidation of two enterprises.. Enterprise Merger Architects?

A very valid discussion as EA and its practitioners are more mainstream now.

I can identify with the temptation to specialise the title of enterprise architect. As seen in comments, an EA (as in enterprise architect) is supposed to do all the above listed. I strongly believe that the focus will vary according to the inflection point of the day in the industry. EAs solve the "system of systems" problems. Many of these systems may be external.
I have seen some people from another consulting company with a title "Executive Architect" instead of enterprise architect. That in my opinion reflects the advisory or decision-making focus of their work, rather than implementation architects.
We should also not forget the fact titles such as Benefits Architect can clash with people from the Finance organisation.
My battle scars tell me that EAs are essentially change strategist and change agents, to use organisational change terminology. The change being delivered varies by initiative, industry and organisational inflection points and handling system of systems issues.
To summarise, use of a title such as Executive Architect is most helpful as it reflects what these people do. So, what do others think?