|
Issue No: 30
Enterprise
Architecture - 10 Common Myths
Printable
PDF Version
By Natty Gur
CONTENTS
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
http://www.portalsevent.com/
He will also be presenting two
seminars in London "Rapid Delivery of Enterprise
Architecture for Business Integration" on Nov 21-23
http://www.irmuk.co.uk/59/
and "Rapid Delivery Technologies for Enterprise Integration"
on Nov 24-25
http://www.irmuk.co.uk/56.
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.
AUTHOR
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:
natty@theeagroup.net.
For More Information about The Enterprise
Newsletter,
Contact:
|