What’s In A Name?

One of our client consultancies recently raised an issue about using the name “Enterprise Architect.” Many of their clients, particularly on the business side, didn’t understand the title unless a lot of context was included to help explain it. While I think most IT types have had enough exposure to EA to understand what it is all about, this isn’t true on the business side. Even though the name might be the industry standard and reflect (to some extent) what we do, if it takes explaining then maybe it isn’t the best name.

I do think it is the “architect” term that is the main problem, but “enterprise” anything has also left a bad impression with some companies – and really, what does “enterprise” mean anyway? Who else uses that term in their title? Finance and HR operate exactly the same way as EA – they have enterprise accountabilities – but don’t have enterprise in their titles – or at least I haven’t seen it yet.   

Additionally, when I work with new EA programs, I frequently find that they are in their third, fourth, and sometimes fifth iteration of building an EA practice. Often there is a negative connotation around the EA term built up from past failures. These clients also would like to use a different label for enterprise architects.

Forrester sees EA as primarily a strategy function. It can be focused on business strategy, technology strategy, or both depending on the organizational approach. In a recent client session we brainstormed a number of different names for the enterprise architect including: IT Strategist, Business Technology Strategist, Enterprise Strategist, Corporate IT Strategist, Corporate Business Technology Strategist, Enterprise Alignment Consultants, and Enterprise Strategy Consultants. We also came up with a similar series of names replacing strategist with advisor.

I like Business Technology Strategist or Corporate IT Strategist best, as they seem to align well with what EA teams are doing (or aspire to do) and don’t need much explanation.  


Executive Enterprise Architect

Executive Enterprise Architect Sign-off for the risk of the enterprise. This is external facing to the public and to other companies

Chief Enterprise Architect Sign-off authority on compliance of all solutions, vendors, products, across multiple clients

Enterprise Architect Sign-off authority for rationale, architectural decisions, and alignment of the solution with the plan. This is the first level with direct accountability to the client

Enterprise Domain Architect Sign-off authority on work products from all the artifacts within the business domain

Enterprise Architect Specialist Brief other architects on domain and will be the primary contact with solution architects or systems analysts

Its not primarily a strategy function

Changing the name because of failures? How about those many successful programs that have strong reputations with Enterprise Architecture core capabilities.

- Aligning strategic and operational views of business
- Driving the technology vision
- Transforming and automating operations
- Facilitating and governing organizational change
- Mitigating risk
- Overseeing investments
- Managing the architecture
- Integrating people, processes, and technology

Jeff, you are back peddling for some reason and not standing up – you change the name but please do it for the right reasons and don’t lock yourself into something you will regret five years from now.

The name isn't as important as what we do.

Hi Susan -
You say EA is not primarily a strategy function but the bullets you list are primarily elements of strategy: aligning, driving vision, transformation, organizational change - these are all elements of strategy are they not?

Yes, there are some successful EA programs but they are not in the majority. They weren't successful because they called themselves Enterprise Architects. They were successful because of what they did. And many of the things they did to be successful are not "architecture".

And just for the record I am not advocating a change in name. I am pointing out real issues with the name that have come up from architects themselves. Not 1 in 1,000 business managers and executives could accurately describe what EA is. In fact most EAs disagree on what it is. Adrian, you, and I are good examples of that.

Enterprise Architect name

Were we to look at the name alone, we would conclude that Enterprise Architect is someone performing the role of an architect of the Enterprise.
And architecture produces blueprints typically for building, bridges; and now the Enterprise.
Including Zachman in the assessment we would note that the EA architect would have to ask "w" questions from a number of perspectives to discover how the Enterprise works and what is its structure.
DODAF the oldest EA framework architects the way the whole DoD and its operations operate.
There is nothing much about strategy and even less about IT in this. Solely the Why question reminds us vaguely of strategy.

How did you determine that EA is about strategy alone? You may do strategy, business or IT, and call yourself accordingly a strategist... and not an EA architect. This will be fair. But it would not be fair to attempt to change the Enterprise Architect name for the profession.

But it is true that in practice EA was somehow hijacked by IT and strategists that call themselves Enterprise Architects.

EA is strategy

Hi Adrian -
First I want to distinguish that I am talking about ENTERPRISE architecture. When I create the architecture for an individual system I am being an architect - but not necessarily an enterprise architect. This is a design function and aligns well to the building architect model.
The EA's role is to create a view of the future that is different from the past and to facilitate efforts to get there. It is not to blueprint the current state and let people do with that what they will.

On another point. You say: "But it is true that in practice EA was somehow hijacked by IT and strategists that call themselves Enterprise Architects." I hear this from a variety of people but don't understand it. 1. Though I am not entirely certain who coined the EA term I do know that Zachman is given credit for the first articulation of EA and the original use of the framework was to help IBM sell hardware and software.(John was in marketing). Stephen Spewak wrote the first book on the subject and he was an IT person and his book was an IT book. 2. Going back 30 years I have never heard a business person talk about enterprise architecture and know of no business books (until recent ones - also written by IT guys) that refer to EA
If IT hijacked the EA term from business, show me where the business was using it pre 1990 and who exactly we hijacked it from.

Hi Jeff, I disagree with the

Hi Jeff,
I disagree with the opinion that an EA architect creates a view of the future Enterprise alone; this view is not consistent with the EA name and is not supported by Zachman's view or matrix, by DODAF or by any framework for that matter. And if you do that you should not call it EA but strategy or whatever.
I can well understand that it is convenient for a consultancy to talk about the future instead of discovering the present since they always have little information about the current state.
I explained in my previous reply that Zachman's framework has no IT reference at all and DODAF does cover much more.
TOGAF has hijacked though EA for IT.

IT did not hijack EA

Adrian –
Sorry but I respectfully disagree. To me it is circular logic to define what we do based on the label we gave it before we understood what the label meant. Labels are given to things to describe them not the other way around.

As far as the Zachman framework is concerned. It may not mention IT in the framework but it was developed specifically for IT use. The summary from the 1987 IBM Systems Journal article where the framework was introduced by John Zachman:

In summary, by studying fields of endeavor external to the information systems community, specifically those professions involved in producing complex engineering products ( e.g., architecture/construction, manufacturing, etc.), it is possible to hypothesize by analogy a set of architectural representations
for information systems. The resultant “framework for information systems
architecture” could prove quite valuable for:
•Improving professional communications within the information systems community.
•Understanding the reasons for and risks of not developing any one architectural representation.
•Placing a wide variety of tools and/or methodologies in relation to one another.
•Developing improved approaches (including methodologies and tools) to produce each of the architectural representations, as well as possibly rethinking the nature of the classic “application development process” as we know it today.

Zachman is not IT

As you quoted, Zachman's Framework has no IT and does not come from IT but from "studying fields of endeavor external to the information systems community, specifically those professions involved in producing complex engineering products ( e.g., architecture/construction, manufacturing, etc.)". It may be applied to IT technology as well but not necessarily. Conclusion: Zachman's frameowork is not IT DODAF is not either. TOGAF, evolving from a precursor of DODAF, has changed all that and hijacked EA for IT. QED. And EA is not about strategy alone. None of these frameworks is.

Deja Vu

Here we go again! I went through this 30 years ago with the title Systems Engineer. The problem is that the general public - and even some IT folks (but back then we were Data Processing), think of "architect" as someone with certain types of training and degreed. Generally, these people design buildings, houses, bridges, etc. The analogy is not inappropriate, but the training is different, and the outcome of the work is different (it's not on large pieces of blue paper).

It's just a question of semantics. Many people will never get it. For them, you're just a "computer person."

Shakespeare's View

To quote the great man (in Remeo & Juliette) ""What's in a name? That which we call a rose by any other name would smell as sweet"."

With the greatest respect Jeff (and you deserve it as one of the thought leaders of our field) I must express that I am disappointed with this post. It is not that I disagree with you, enteprise architecture is not a great name, but our profession is spending far too much time navel-gazing and trying to define itself and far too little time generating value for clients.

Look anywhere in the blogosphere or the forums and you will see countless discussions of EA difinitions. Conversely, how often do you see worked examples of EA effort, shared with the EA community of interest, for the purpose of reflection about the best methods for generating value?

The truth is that the same basic set of techniques (alignment, mapping, modelling, abstraction, stakeholder engagement, asset valuation, lumps & gaps analysis, impact analysis, etc...) can be applied to any or all of the traditional (business, information, application, technology) layers.

Relative to the constant introspection or what I refer to (paraphrasing Ross & Weill) as "enterprise as self-licking-ice-cream", there is so little content out there focussed on applied EA.

If practitioners are out there listening to business and understanding business problems and then applying the basic set of techniques; the semantics of our identity should fade away and leave behind the sweet smell of value creation, organisational readiness for exponentially increasing rates of change and organisational capability to manage complexity.

In my defense

Alexander –
I am totally with you on your navel gazing comment. Architects are spending way too much time thinking about architecture and much too little thinking about solving business problems and creating value. But in my defense I posted this entry because it is an issue for my clients:
1. A major consulting company reported they were having trouble selling architecture services because their clients either didn’t understand the name or reacted negatively to it.
2. I have had many clients tell me they need to start an EA initiative but can’t call it EA because of the negative connotation.
3. Architects in their navel-gazing mode are trying to define their role based on the label and thus not providing the value their company needs. (Some of the responses to this post are relevant examples)

Yes, I agree wholeheartedly that his name thing is a tangential issue, but it is one that is causing EAs pain.

Is the viewpoint sensible?


Thanks for the reply, I think we're singing from the same song sheet here. :-) I do have an additional comment if I may.

I think points 1 & 2 may be reflective of looking at the problem from the wrong viewpoint. To give an analogy, I am sure that most practitioners have been in a situation where a client is asking for a technology (e.g. "I need an ESB") but what they really want is better busiss agility or to reduce time to value in apps development.

The point here is that if you are trying to "sell architecture" or implement "EA" then you may be approaching things from the wrong viewpoint and waste a lot of energy. If instead (using the example of the client asking for ESB above) you visit the client, work with them to understand the specific business pain, (lack of business agility or high cost for development of apps,) then you can do three things. 1. Verbalise the problem, to the person that will be making the investment to fix it, in terms they are familiar with. 2. Describe the steps that you will take: practical, palatable, pragmatic advice. 3. Have no need for any reference to EA.

This doesn't mean that you don't do EA it just means that IMO EA isn't a solution as such, it is a set of methods designed to address business problems. In this example the saleable solution might be a pilot SOA project to develop some initial services, establish governance mechanisms, refine your method for decomposing services, etc. This is something that can be packaged by service providers, reused as a business asset and taken to market. Some of the outputs of the pilot will be; the reusable business components, the repository in which they are stored, the methods by which they are discovered. These are the foundation of an enterprise architecture that can grow organically but in my experience hitting executives with "this is EA" is rarely the optimal approach.

Zachman and EA

I had the pleasure of hearing John speak many years ago. It was before he published in the Systems Journal. I was an IBM employee working in headquarters Information Systems (IT) in Canada, John was still an employee of IBM.

I was doing data modelling. For the first time we were engaging with the business in a new way. No longer were we talking about only functional and non functional requirements we were introducing the notion of models, data models (Chen-ER) and process models we were talking about logical and later conceptual levels of models with the business.

Still, we in IS did not see the bigger picture, the fact there was more holistic view of the modelling we were doing. The framework John presented was an IS-wide perspective, not an enterprise wide view and a few of the columns were missing, but it tied everything we were already doing into a larger picture. John's cells were filled with our methods and levels of modelling. That is why it resonated with many of us. That talk changed my perspective in a way that few other talks have.

After his presentation we still called ourselves designers and modellers, but we started to think like architects. It was not a talk on applying engineering, although he used the building architect metaphor.

I am sure we all arrrived at being Enterprise Architects in many ways, but for me it came from IT. It was not the business engaging with IT, it was IT engaging with the business. We introduced logical and conceptual models to the business. John's framework provided an architectural and IS-wide perspective on what we were already doing and started us thinking like architects.

The slide I saw those many years ago is shown here as the 1984 version; http://www.zachmaninternational.com/index.php/ea-articles/100#maincol

EA by any other name

This is an unapologetic IT perspective, but those organizations that think that IT can continue on the way it has over the last 30+ years are mistaken. We have built new systems faster than we've replace old, there has been little or no governance around the introduction of new technologies. All the while IT relevance has increased. We are no longer simply building back office systems for employees, we are building and maintaining the applications that reinforce the organizations brand with our customers. We build the information and analytics stores that allow the business to sense changes in the market place. If IT was a village or a town 30 years ago, it is like a city now, with all the complexities associated with adding anything new to it.

EA, by any other name is needed now, because of what we have created without it.

EA = Strategic Planning for IT/IS

I agree with the sentiment of this blog.

The outputs from EA programmes are the IS Strategic Plans for the Business Strategic direction and needs.
EA in my experience is renowned as being Technology focused and EA people are in an constant battle to convince business and IT peers that they are not (any more) just about technology, thus in my company, whilst the roles are refereed to as Enterprise Architects, the outputs we produce are now referred to as IS Strategic Plans (incorporating Vision, Blueprints, Roadmaps, Investment cases, Position Papers) and the activity we refer to is IS Strategic Planning.

I fully agree with this

I fully agree with this sentiment. Some time back I was talking to an Enterprise Architect friend of mine about how the naming of the field or discipline of Enterprise Architecture must be confusing to a business area person. In my case this was based purely on gut feel. I think the problem is not in the naming of a role of enterprise architect, but in the naming of a field of Enterprise Architecture. After all an enterpise architect is referred as such due to the fact that s/he works in the field of enterprise architecture. Therefore to change the designation of a person practising what is still referred to as enterprise architecture to Business Technology Strategist for example, may not be that helpful. It will still sound strange to tell a business area person that "our business technology strategists are going to do our company's enterprise architecture".

Enterprise Architecture as Strategy?

Strategy, in the business sense, is about how my products or services are competitive and postition my business in an industry. Strategic planning is how do a I prepare my organization to execute that strategy. Strategic planning is not about defining the strategy. It is only feedback and then only if the proper competencies and capabilities cannot be leveraged to support that strategy. The business can then decide that it can build them, buy them, or realize that the strategy cannot be implemented.

Before the wikipedia definitions and dictionary definitions start coming in, the term strategy can be used for anything from tying ones shoe laces to monkey's using sticks to get ants. However, in a business sense, it is used in a very specific way.

In this position enterprise architecture is preparing the company to execute a strategy. The term enterprise, again in the limited business sense, has been used to refer to the integration of people, process, and technology within the organization. It is a manufacturing concept which has a legacy in factory automation. The term enterprise engineering was a sub-field of systems engineering, which has been around since the 1940's (albiet not as part of computers). The term enterprise engineering can be traced back to before 1978 when several companies started using the term to define this integration work. It viewed this integration in a larger more holistic sense. This may be where John came up with the term (although he never admitted to hearing the term, even though the companies that he interviewed for his framework were mostly manufacturing based and would have been well entrenched with these concepts). One can get a PhD in Enterprise Engineering from top 10 universities, without ever learning about IT or hearing about John Zachman.

So yes, the term enteprise architecture was hijacked. It may have been unintentional, I cannot prove otherwise, but it was still taken to relate to information technology only because it was IBM who was paying John to do the work (and as a manufacturing company they were no doubt familiar with enterprise engineering at the time).

Enterprise architecture as a profession, can be what we want it to be, as long as it has a unique way in which it offers value to the business. Considering the hideous mistakes made by businesses in integrating people, process, and technology, costing more money than the growth of the S&P 500 over the same period, I would think that there is a real need here.



If you don't mind I'm going to quote this line every time I see another pointless debate about what EA should be called.

"Enterprise architecture as a profession, can be what we want it to be, as long as it has a unique way in which it offers value to the business."

maybe I'll (crudely) paraphrase it as "Call it what you want, I'm busy creating value" *grin*

Found the same thing


As you and I have spoken about many times, Iasa has found the same thing but far beyond just enterprise architects. The Iasa skills taxonomy, which underpins our entire career path and specializations, actually identifies business technology strategy as the core skill for all architects and the one key differentiator of the profession. We came to this conclusion through exhaustive research with our members over 5-7 years and have yet to find a truly effective alternative.

The reason that the name is so important is that for professionalization to occur enough architects must identify with their common name (much like doctors are proud to be called doctors) and enough laymen must understand what the term represents in personal value. For example you dont got to an accountant with a broken arm. Everyone knows the value of accounting. Any profession must have similar recognition in the long run.

Software, infrastructure, information, business, application, solution, enterprise, chief, etc at the front of the word architect, they invariable translate (though some question and answer) to this one common differentiator, business technology strategist.

However it is important to note that enterprise architecture does NOT work as the right name for the profession for one fundamental reason, the vast majority of practicing architects (and Im talking in the 90-95% range) do not want to be called enterprise architects. They prefer the previous list of titles. They however do not mind being called technology architects.

Glad to see your research and position match.