Truth or myth?

It is not easy to know what is right or wrong when you read about enterprise architecture or hear about it on seminars and lectures. Most often the statements made aren’t based on solid research, sometimes they aren’t even based on best-practice or real world experience. This post tries to capture some of the truths and myths and explain what is or at least could be truths.

Truth or myth? Enterprise architecture takes to long time to be of value to anyone!

Myth. Probable cause of the myth is that early efforts in enterprise architecture did not do partitioning and sequencing properly. Resulting in phenomenas like analysis paralysis, ivory tower and hide and seek.

Today most enterprise architects know techniques for partitioning and sequencing. Good sources of knowledge are OpenGroups Togaf, Roger Sessions SIP method and Zachmans concept of cell width, cell depth and cell slivers.

Truth or myth? Enterprise architecture exists whether you have defined it or not!

Myth. Probable cause of the myth is that any organisation has a structure, represented in a visualization or not.

Most of the common definitions define enterprise architecture as a being some kind of blueprint and associated methods of producing and governing such a blueprint and its implications.

Truth or myth? Even a single piece of enterprise architecture is better than none at all!

Myth. Probable cause is that it takes a lot of work to do even one piece of enterprise architecture correct. This has led to recommendations that one piece or a select few small pieces of enterprise architected areas is better than none at all.

It’s true that even a single piece architected with the whole enterprise in mind is better than none at all. But the problem turns out to be that most who do only a single piece or a select few forget that it must be an enterprise wide piece.

Truth or myth? Enterprise architecture can be produced as a byproduct of the projects running within the organisation!

Myth. Probable cause is people who feel threatened by the promise of an optimized enterprise or people who like to keep the “whole” under control in the project alone.

Sure it’s allways been known that some of the work products of enterprise architecture is a result of well planned projects. What this mean is that it just doesn’t happen by chance.

Truth or myth? The common view of enterprise architects is that “they think they are too important to get involved in the daily operations”!
 
Truth. Probable cause is that enterprise architects appear to be busy all the time. This leaves operations and projects unable to vent their daily challenges with the only people who could actually make a real difference to the whole enterprise.
 
This mean that an enterprise architect should make time available to get attuned with the people doing the operations and projects. Kicking back and doing email and phone communication will not cut the jam.
 
Truth or myth? You can do just as well without a specialized enterprise architecture tool!
 
Myth.Probable cause is that the toolings have been (and still are) expensive and often hard to get started with.
 
If you are serious about enterprise architecture then there will be so much information produced that not having support of a dedicated tooling, consisting of at least a repository with versioning and configuration management, users and rights maintenance, browsing and searching, publishing and reporting, metamodel and modelling, integration and communication, standard notations and methodologies. Not having all that will stop you from reaching the promise you made to management by starting up with enterprise architecture. Sure you can do all this by using lots of different tools together, but then you have to put effort into integrating them (or use the old human integration pattern). 
 
Truth or myth? It is a lot more effective to invent your own light weight enterprise architecture development method than using any of the methods on the market!
 
Myth. Probable cause is that it has been hard to understand how to use the methods available because they have been more or less complete (and still are).
 
Any good methodologist will tell you that it is far more effective to configure an existing method than to invent one of your own. By configure I mean add, subtract, rearrange, translate and rewrite. You don’t have to tell anyone that you used any particular method, you can even put your own internal name on it, just don’t sell it to anyone outside your organisation. 
 
Truth or myth? When doing enterprise architecture development you should start with process or goal or organisation or information!
 
Myth. Probable cause is that different people proposing the use of enterprise architecture came from the field of architecture that centered around one of process, goal, organisation or information.
 
It doesn’t matter which one you start with as long as you get the answers to the questions you needed to ask your enterprise architecture. So the proper way would be to start with the questions you’d like to have answers to.
 
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s