Methodologies and Technologies for Rapid Enterprise Architecture Delivery


| Home | Courses | Projects | Papers | Contact Us |


Issue No: 30

Enterprise Architecture - 10 Common Myths

Printable PDF Version

By Natty Gur



Sep 30, 2005: It has been some time since the last issue of "The Enterprise Newsletter" (TEN). This has been due to the pressure of final revisions to my next book: "Enterprise Architecture for Integration; Rapid Delivery Methods and Technologies". I am pleased to report that the book is now in production and is expected to be available in March 2006. The publisher is Artech House, located in Norwood MA. I will provide further details in TEN, closer to the publication date.

This issue of TEN differs from other issues. I am pleased we have a guest contributor, Natty Gur. He has written an excellent article on the 10 common myths of Enterprise Architecture. Enjoy his comments and observations below. He has also contributed another paper on the IES web site in the Papers page. This is an excellent method for Monitoring and encouraging Systems Compliance with the Enterprise Architecture.

Clive Finkelstein
Publisher, The Enterprise Newsletter (TEN)

Upcoming Events

A series of 2-day seminars, titled: "Rapid Enterprise Architecture Delivery" will be presented in October - December by Clive Finkelstein. These are scheduled in Canberra (Oct 24 - 25) and Wellington NZ (Dec 1 - 2).

Clive Finkelstein will also be presenting a 1-day version of this seminar in the USA for TDWI in Orlando on October 31, titled: "Enterprise Architecture for Business Integration" and "Enterprise Architecture for Technology Integration"

He will be presenting a 1-day pre-conference seminar on Monday November 14, 2005 titled: "The Role of Enterprise and Service Oriented Architecture" and a session on Tue Nov 15 titled : "The Latest Developments in Composite Applications and Service Oriented Architecture" at DCI's Portals, Collaboration and Content Management Conference in Miami FL November 15-17, 2005. See

He will also be presenting two seminars in London  "Rapid Delivery of Enterprise Architecture for Business Integration" on Nov 21-23 and "Rapid Delivery Technologies for Enterprise Integration" on Nov 24-25

Back to Contents

Enterprise Architecture - 10 Common Myths

By Natty Gur

Being aware of our weaknesses and obstacles is one of the most important steps in order to complete successfully any task. Running Enterprise architecture (EA) efforts as it is, is not a simple task, but a process with many obstacles, most of which has a lot to do with enterprise politics. Being aware of colleagues’ mistakes and the usual myths might prevent you from stepping into known traps. Myths are an important aspect of enterprise politics since they inhabit our beliefs and therefore shape our behavior in one way or another. Being aware of common myths might help you to be prepared when you’re engaged in enterprise political debate or process.

I’ve compiled a guide to the 10 most common myths that I’ve came across in my years of experience conducting EA processes. I’ve tried to sort these myths by their frequency of appearance, yet bear in mind this was done according to my personal experience and might differ from any other.

Myth No. 1 – EA is a long and tedious process

It’s true that the entire EA process is a long process; actually it won’t stop as long as the enterprise is running.  But there are several agile EA methods that will provide essential and productive outcomes out of the EA process every couple of months (3-5). Adopting agile methods actually cuts the long and tedious process into small processes with proven outcomes that will ensure their continuum. This myth roughly correlates with reality so you’d better prepare a corresponding agile EA process when trying to convince top management to start such a process. When you have a chance to present your EA process always emphasize its agility by mentioning the EA steps and the outcomes that they will provide. 

Myth No. 2 – it’s all about the technological aspect of how to build systems

Most people treat EA as part of the technological aspect of IT. They think that EA is all about how to build systems and what infrastructures are needed in order to support those systems. While it’s true that EA deals with system structure and infrastructure but - those are just a few aspects of EA, not the whole process. On the contrary, EA does not focus on technological aspects at all. EA roots and efforts are found in the business side of the enterprise. The main goal of the EA process is to maximize IT solutions to enterprise demands:, therefore  one must understand the enterprise needs before finding the perfect IT solution.  Therefore make sure that there is a common grasp of the term “enterprise architecture” all around your organization. Invest time in order to educate others what enterprise architecture is all about.

If you don’t do this you might find yourself in an inconvenient situation (especially political ones) because managers in the enterprise might think that you’re dealing with aspects that you shouldn’t have touched in the first place.  I had to handle, more than once, situations where managers complained about interviews that we’ve made with their employees in order to map enterprise operations and data. They were furious when their employees told them that we found out that certain enterprise operations were being done by other parties in the enterprise, and not by them (who were exclusively assigned to perform that action). Their complaint was “why do those guys map enterprise operation? They should have been handling technological aspects only!  It is pretty clear that if we’d agreed upon the term of enterprise architecture, we wouldn’t have found ourselves in such a situation.

Myth No. 3 – I’ve heard about it before, it’s useless!

Unfortunately EA is not an easy process and as such there are many examples of EA efforts that weren’t successful or failed. Those failures, usually spread as rumors, find an honorary place in CEO minds. When you start to talk with them about the need for he EA process they will bring up this argument. Failures tend to get more publicity than success and to stay longer in people’s minds. Needless to say, most EA processes do not fail.

Those stories should not harm you. On the contrary they- might help you. People tend to publish failures so others will study those failures and find out how to prevent them from recurring. Use those publications to find out similar cases to that of your enterprise and learn from them.

To overcome this myth simply find out three or more enterprises like yours that have already gone through a successful EA process (at least one cycle). Try to contact those enterprises and ask them to meet your CEO so he can hear how such a process already helped other enterprises. Usually those meetings will convince CxOs that EA really helps enterprises and is not a useless effort.

Myth No. 4 – All I need is a strong chief EA to run the process successfully

Although a chief architect to manage such a process is a necessity, the process will fail if it’s only carried out by a single person. EA touches almost every aspect of the enterprise. Furthermore, the outcome of this process should be executed by employees all around the enterprise. Therefore such a process should be done by groups of users representing all parties of the enterprise. The chief architect’s job is to train and guide those groups. Group members must feel that they’re the ones who did the job and that it’s their responsibility to make those changes happen. As EA group members, you should appoint those who are amongst the most appreciated by other employees in the enterprise. These members exercise power to some extent and might help you with in spreading EA awareness.

It’s a good idea to create a task group for every one of the Business, Information and System architectures. Those groups should be made up of users that represent the IT department as well as all other relative parties in the enterprise. It’s also better to create those groups from managers all around the enterprise. Managers are more capable of enforcing the chosen architecture. Furthermore, managers could enforce enterprise changes if they find out that change is needed in the course of running EA.

The most important group that should be made up from managers is the business architecture group. While mapping the enterprise operations we tend to find out many cases where enterprise changes are needed. As I’ve mentioned before, the most common is a case of one single operation being carried out by more than one group in the enterprise. In those circumstances managers who discover such a situation might do something to fix it.  

Myth No. 5 – It’s a process that is run by the IT department

Most of the architectural effort of today concentrates on the infrastructure rather than on the application. Most of the time the recognition of the need for enterprise architecture comes from IT staff, as they find the need to align the business with IT. For that reason many tend to believe that the EA process should be run by the IT personnel. The fact is that EA process should be run by both business and technical teams. Furthermore, it is recommended that the EA architecture effort will be directly under the supervision of the enterprise CEO and not under the enterprise CIO. Such hierarchy implies to users all over the enterprise the importance of EA as well as that the process is part of the business needs of the enterprise and not an exclusive IT requirement. The best practice to go through such a process is to form a group of ‘super users’ together with IT architects. Such a group should be made of more super users than IT architects and should be trained by the chief architect. It’s very important to let the super users have the a feeling that they’re the ones who run the process. Such collaboration between business and IT should decrease the usual suspicion that exists between those two parties in the enterprise. 

Myth No. 6 – It’s a one effort process

Wrong! Enterprise architecture is a never-ending process. Indeed the first cycle of that effort is longer then the others and takes much more effort and resources but the process doesn’t stop after the first cycle. As a matter of fact the other cycles include governance of the given architecture, governance which may never end. In real life situations, something always changes. It could be new enterprise processes or demands, change in the enterprise structure or even new technology that might improve the enterprise performance. Therefore there are always continuous cycles that deal with the new input.

One of the toughest questions is “how do I know that I need to start a new cycle?” Well there’s no clear answer for that. As a rule of thumb, a new cycle is in need after a major change in the business has taken place, the emerging availability of new technology that might help the enterprise - and once a year (if nothing has already caused a cycle to start). Usually in a year’s time something always changes, requiring the initiation of a new cycle.

Myth No. 7 – this process will solve all the IT problems

Beware of this myth! Add it as one of the parameters of your EA project risk management. If you see that this myth emerges in people minds, do something to stop it! The reality is that the EA process might improve IT and the business situation but certainly not solve all the enterprise problems. If people tend to think that such a process might solve all of the problems they will see the first cycle of the Process as a failure and you may then not be able to continue with the enterprise architecture effort anymore.

It is a mistake to market enterprise architecture as a process that solves all of the enterprise problems, even though it’s appealing. It’s better to market EA as a process that will help the enterprise to improve itself and its performance. The enterprise architecture process will improve the current situation and every new cycle of the process will advance this progress. Due to the dynamic notion of the enterprise there are always new problems that need to be solved, but with EA you can at least monitor those problems and create plans to solve them either in annual or multi-annual programs.

Myth No. 8 – I can do that process without framework/by my own

Enterprise architecture processes are complex and tedious. It’s simply impossible to go through such a process without a methodology that guides you through this process. There are several frameworks available in the market today. Most of these frameworks target certain types of enterprises (Telephony, defense, business, financial, etc’). Find the framework that fits your enterprise the best. As frameworks are highly adaptable, you should invest time to adjust the chosen framework to your enterprise needs. If you decide to create your own methodology you’re facing two possibilities: failure of your process or you might gain fame and fortune for inventing a methodology…

Myth No. 9 – What’s the point in running such a process when I’ve already got operating systems

That’s a strong one and its roots are pretty obvious. Every enterprise already has its own set of running applications and regardless of the mess that actually takes place within these applications and the state they’re running in, the enterprise is: A) working; B) cannot afford to change the current situation (mostly due to the amounts of money that are have already been spent on the existing applications).

In effect there are always some problems that we would like to solve, so wouldn’t it be better to do deep work and find out the architecture that is currently in use and what would be the ideal one for your enterprise? Then, without ignoring the current situation, you could build a migration plane that will guide the enterprise to move toward the desired architecture.

Usually, to work around this myth suffices to leave the current applications as they are and to build the new applications following the new architecture with several limitations:

  • To warp-change existing applications that expose services to new applications in order to prevent duplications in the enterprise.

  • To rewrite existing applications by using the new architecture if the former require alterations that demand significant changes in the application.

For the other applications the enterprise needs to build a long term plan for rewriting the applications from the beginning. That plan should be guided by the IT department budget and the significance level of the application in the enterprise business process. 

Myth No. 10 - Any talent system/infrastructure architect with the right background can coach that process

Well, sadly that myth isn’t true. I’m not trying to say that no technical architect can run the enterprise architecture process, but that enterprise architecture requires another set of abilities and qualifications that most technical architects do not normally have.

The most predominant difference is the ability to maneuver through political forces in the enterprise. Business and information architecture (especially business architecture) are profoundly bound to the enterprise politics. One mistake in that domain and your process is doomed, or you’ll find yourself facing new oppositions inside the enterprise. Therefore enterprise architects should be able to engage with politics, be convincing and mentor and move forward a group of people with different aspirations towards a certain goal. Sounds complex, but it’s possible.


Natty Gur is the founder and CTO of “The enterprise architects group” an international enterprise architecture consulting group based in Vestal, NY. Natty has 13 years of experience in the IT field, 7 of them focused on running enterprise architecture in companies and governmental bodies. Natty has written many articles and is a well known speaker on EA topics. You can reach natty at:

For More Information about The Enterprise Newsletter, Contact:

  Clive Finkelstein, Managing Director
Information Engineering Services Pty Ltd
PO Box 246, Hillarys, Perth WA 6923 Australia
Web Site:



TEN Archive
Contact Us





Clive Finkelstein is the "Father" of Information Engineering (IE), developed by him from 1976. He is an International Consultant and Instructor, and was the Managing Director of Information Engineering Services Pty Ltd (IES) in Australia. 

Clive Finkelstein's books, online interviews, courses and details are available at

For More Information, Contact:

  Clive Finkelstein
59B Valentine Ave
Dianella, Perth WA 6059 Australia
Web Site:

(c) Copyright 1995-2015 Clive Finkelstein. All Rights Reserved.

| Home | Courses | Projects | Papers | TEN Archive | Contact Us | [Search |

(c) Copyright 2004-2009 Information Engineering Services Pty Ltd. All Rights Reserved.