This is a well written article which covers the definition of an Enterprise Architect and the role they play in an IT organization. While I agree with most of the aspects presented, I would like to draw specific attention to some social aspects that every Enterprise Architect needs to work on to succeed.

Social aspects being
1) People
2) Politics
3) Corporate culture

While social skills are vital in almost all high value jobs, they are especially important for an Enterprise Architect. Almost every Architect these days has to manage and thrive on conflicts and figure out ways to resolve them. Every medium to large organization is going to have a heterogeneous mix of technology platforms, business silos, multiple methodologies/ practices and people with various backgrounds/ skills.

The moment we start talking “Enterprise” one of the first things Architects need to convey is “why do we need to do this” and demonstrate “what is in it for me” for various parties. Architects need to do this on a day to day basis. In spite of these basic techniques Architects frequently get into conflicts on technology strategies that the organization as a whole may be divided. The Architect needs to step up and “unify” teams… How?

Here is a technique that I have used and have had good success with to resolve conflicts and foster buy-in. I call it as a “Technology Strategy Document”. It outlines the following
a) The state of the union (Architecture) sometimes including a SWOT analysis.
b) Problem at hand and business drivers
c) Who are the decision makers
d) Solutions to the problem – Atleast 3 options
e) Pros and Cons of each solution contrasting cost benefits.
f) Recommended solution (Architects recommend & CIO may be the decision maker)
g) Implementation strategy (a high level swag at resources, timelines, tools etc.)

While working through such technology strategy initiatives I have been pleasantly surprised at the support folks provide to Architects - many times setting aside their turf and stepping out of their comfort zones; thereby allowing the organization needs to be placed in front. Even if the decision is contrary to what the conflicting parties wanted, it provides an avenue to have their concerns raised and their perspectives documented. This further helps them to “disagree and commit” to the decision. This also ensures that when the parameters change in the future folks can refer back to “why we did what we did”.

I believe as the concept of Enterprise Architecture matures in the industry, CIO’s will see increasing value from Architects who have the technology expertise, business acumen but the icing on the cake will be how architects can interface with people and “unify” organizations.

Ramesh Elaiyavalli
Director IT - Enterprise Architecture
First Advantage CREDCO

It all sounds very grand. It seems to have escaped your notice that the business activities you are describing have mostly already been done by Business/Systems Analysts for the last 40 years or so already.

These Strategic Business Analysis activities are also sometimes called Enterprise Analysis. So what is in a name? It is the concepts that are important.

However, there is a fundamental distinction in allegiance, and business ethics, in these roles.

The Architect has a vested interest in Pushing a Technology solution on the customer. Maybe not always a specific solution from a specific supplier; although this may often be the case.

The Business Analyst has no such allegiance to any technology solution, or even to a CIO, although the CIO may be their manager, in some cases.

The Business Analyst must be firmly on the side of the customer, period. This premise must be accepted by any IT organisation that employs a Business Analyst; otherwise the role is compromised and not effective.

The role of the Business Analyst is also to Facilitate Communication within the customer organisation and within the Supplier organisation; and between the two organisations.

After scandals such as Enron, Arthur Anderson, Worldcom ... leading to the Sarbanes Oxley ... it is even more blatantly obvious why this "separation of concerns" and allegiance is vitally important; and actually in the interests of Architects at all levels of the enterprise.

The Business Analyst is mainly concerned with understanding the business needs of the customer. The primary focus of the Business Analyst is to find the most useful questions to ask. What does the customer really, really want and need?

When we have asked the most important questions then it is time to consider the answers, or solutions, technical or otherwise, to those questions.

It is only at this point that there is any point in talking about a Technology Architecture, at Enterprise level or otherwise, which may be only one part of a business solution.

"Architects", literally chief builders,
usually want to build or supply something technical, it's natural that is what they love to do and may even be passionate about it; but sometimes it is not what the customer really, really wants or needs.

A warning to "Enterprise" Architects: don't fall into the trap of the Auditors/Business Consultants who want to be Solution Suppliers as well.

It will come back bite you in the posterior! Remember Anderson's the largest accounting firm in the world? Where is it? - gone ! They crossed that invisible business ethics line. They broke the professional trust.

Let the Business Analysts do their job of finding the Questions separately first and then start to talk about Answers and Building/Procuring Solutions.

Some concurrency, parallelism, agility, great leap forward ... add your favourite buzz word ... may help but the roles must not be confused or merged otherwise the business trust with the customer is broken; and that is, shall we say, not good for any of the stakeholders, customers or suppliers.

A Senior Business Analyst

EA Is Not for IT Alone

At its lowest level, the real goal of EA is the alignment of processes and technology in support of the strategic needs/direction of the business. This article (and most others addressing EA), implies that EA is an IT discipline, and the responsibility of the IT organization alone. Isn’t it a little presumptuous of IT to assume that it’s all our responsibility, and we’re the only ones who know how to address these topics?

Enterprise architects shouldn’t take on the sole responsibility of defining the processes, data and technology for the organization, but rather facilitate discussions and guide the business toward articulating their vision and needs. How much more successful could the entire organization be if we educate the business on how to think more strategically through the use of EA tools and principles? Our users still know the business better than IT ever will.

With regard to the comments above, the primary domain of the Enterprise Architect is (or should be) around issues involving platforms and technical standards. I am speaking of Governance. At the low end of the spectrum, the decision to standardize on a single Network Operating System or Hardware platform. At the upper end, decisions involving an SOA plan or even having a say in the choice of an ERP system. All of these decisions affect the business and most are highly technical. A Business Analyst may play a part in many (but not all) of these.

Mr. Elaiyavalli's Technology Strategy Document as outlined above makes perfect sense in the context of these matters. What it does is describe exactly how the proposed technology will improve IT support for the business. It makes no attempt to drive the business process. The reason the BA is not mentioned here is because the Enterprise Architect is in a better position to explain the strategic nature of the (often new) technology.

The traditional Business Analyst role of defining new business processes, creating system requirements documentation, and facilitating communication between the business and IT remains firmly in place and is under no threat by the Enterprise Architect.

Enterprise Architecture at most corporations is neither Enterprise in focus or Architecture in practice. Had John Zachman –arguably the father of Enterprise Architecture—known what would have happen to EA in the future I think he’d have never published his paper in the IBM Systems Journal several decades ago. After auditing many of the major corporations and IT firms the past ten years what passes for architecture could be labeled at best Design Standards in other disciplines. While I hate to slam the growing profession, it is not doing architecture it is doing S/W Engineering in an pragmatic manner. Much of what has been delivered is nothing more than design at a macro level. If EAs were to apply the same tools, techniques and deliverables in the construction industry from where the term Architecture was borrowed clients would have their heads.

I have yet to see an EA sit down with a Business Strategist (Functional not IT) and develop an Architecture for supporting the business and the processes that it sees as necessary; instead I see IT departments growing into BPR, defining processes that make people adjuncts to the computer system and assuming that these new “streamline systems” perform some value to the business. Additionally, I see the term system architecture used as a replacement for design. Architecture is not a design, it is a system of rule or heuristics that when exercised yield a consistent and repeatable style and results:

What is Architecture? Within the construction industry there are numerous definitions and it becomes the topic of many heated debates. When one changes disciplines the use or rather misuse of the word can become downright ridiculous. Just recently I became embroiled in this debate again within the Information Technology domain.
I listened patiently as a Technical Evangelist and Marketing manager tried to sway me to their perspective regarding what an architecture is and what is a platform. Arguing about semantics, yes. Esoteric conversation most likely, splitting hairs maybe. However, having an architectural background –the real one—I find the hair on the back of my neck stand on end when I heard ill-informed opinion and poor logic specifically when It comes to my original training and occupation. I still consider myself as an architect on loan to the software industry.
That being said, I thought I would document a universal definition of architecture I derived several years ago during a similar argument in the same information technology domain. My definition I believe is succinct and to the point:
“Architecture are the rules for the selection and usage of components and/or elements to achieve a stated functional objective.”
The proof to this theory is as follows:
If you examine the National Cathedral in Washington D.C., Notre Dame’, and St. Patrick’s Cathedrals, you unquestionably state that each is an excellent example of Gothic Architecture. If however, you match up floor plans, site elevations, and detail sheets they’ll not quite match up. Thus blueprints are not architecture, but rather a representation of an instance of architecture. Then maybe it’s the materials? If we compare material call-out sheets for each of these fine structures we notice some similarities and some differences. However, we’ll notice the same material call-outs for other architectures. I could build a very nice Gothic Cathedral out of Steel, Plexiglas, and Epoxy. So the materials are not the architecture. Maybe it’s something else?
I can see the materials being used in specific structural and functional ways. An Architect created these dwellings by selecting and using the materials in specific ways. S/he would create cavernous rooms with towering walls, exaggerated by shadows and sheets of muted light through stain-glass windows. These non-structural elements are used to create a specific aesthetic or functional objective. Thus, it is not the stone, glass, and wood that created the architecture, but the why or the rules that determined the selection of the stone, glass, and wood that are selected and used that creates the architecture.
So, if we generalize this statement we arrive at my original premise. “Architecture are the rules for the selection and usage of components and/or elements to achieve a stated functional objective.” A test to determine whether one has drawn an Architecture or a Design instance is rather simple Knowing these two facts: 1) Architectures can have multiple instances 2) Designs can only have one instance (i.e., you can only implement them one way.
Here is the test I call Seitz’s test case for distinguishing between design and architecture and its corollary, Seitz’s Probable Architecture Maxim. “If you can only implement a specification one way, you have a design.” “If you can implement the specification in more than one way, you have a high probability you have specified and architecture”

Coming from a systems architecture background, it took me a bit to get my mind around what I now believe to be the definition of EA.

Those of us trained by Dana Bredemeyer (see bredemeyer.com) would say that Enterprise Architecture is "Business Capabilities Architecture." Or the Architecture of the Enterprise, with Business Strategy as the driver. The components of the systems EAs architect are made up of people, process and technology.

As such, EA is a link between Business and IT. This is not just Business informing IT; but also IT constraining business through envisioning an Enterprise Architecture that speaks to the Strategic Planning of business leadership.

I've just come out of 4 days of Business Analyst training. Most of the BA requirements eliciting techniques are useful in soliciting architecture - even Enterprise Architecture - requirements. However, the difference between BA and EA appears to me to be context. The context of BA activities, even the enterprise analysis step, are focused on solving a problem or business need. EA is focused on alignment IT solutions with strategy, across projects (connect the dots) and across time. While EAs may work within a project to draw out and document requirements that keep the project "strategic," this is traced back to the "long view" I described above.

This is a description of the "ideal" state of EA and certainly every organization is different. Our organization is definitely not operating at this level of maturity. However, we are separate from Business Analysts and operate generally with the context described above.

Hopefully this helps!

Jim Hooper
Enterprise Architect
Saint Louis University
Saint Louis, MO

I believe I have had the opportunity to witness the evolution of Enterprise Architecture and find that the industry has misinterpreted what it is. EA is not isolated to just IT, it is the understanding and management of the complete lifecycle of change within any organization (enterprise) applying proven architectural principles and engineering methodologies (frameworks) in a cohesive manner. EA provides the oversight of strategic planning and tactical implementation by decomposing a complex environment into manageable components. EA provides and documents an organization's line-of-sight from the enterprise strategic mission, goals, functions and information that will provide the decision makers prudent recommendations (initiatives) that will improve the business processes and enable technology that will provide more effective governance and efficient (optimization) operations..

I liked Diann's explanation of Enterprise Architecture as addressing the 4 Cs of connection, collaboration, communication and customers. However I agree with Anonymous Fri, 2007-04-27 08:02's view that this has been done in the past.

I would add my "2 cents worth" and state that Enterprise Architects should be focussing on addressing issues with interfaces and unnecessary complexity. This includes IT and non IT systems and processes such as interfacing paper based and implicit knowledge methods that only exist in the human brain.

Although job titles vary from region to region in my experience Business Analysts typically look at systems and Enterprise Architects focus on systems of systems.

Regards

Ian
www.consult4you.biz

EA is the 21st Century way to get your arms around complexity. If you look at it from an IT perspective, Data perspective or a business process redesign perspective, SOA or any other stove piped perspective only, You never get a holistic view of the complexity landscape. The EA discipline (or whatever name you want to attach to it) is methodology and framework modeling that integrates and is used in the requirements, design, implementation, operation and decision making of complex "systems" to enable exploration, common understanding, unity of effort, disciplined control of expectations and saving money. "Systems" can be defined as organizations, projects, LOBs, M&As, or any complex situation needing a holistic approach to see the light at the end of the tunnel.