Enterprise Architecture Demystified

Sethuraj Nair’s Enterprise Architecture Thoughts

Enterprise Architecture : How Not To Miss Anything ? -Part I

Posted by snair007 on June 17, 2008

Scoping Problem in EA

In EA , Enterprise comes before Architecture

We know our problem: not many of us get to try our hand on an across- the- board Enterprise Architecture (EA) . But then EA can also be what you like to call EA. The nature and size of architectural collateral could also vary significantly – may be it is just that cute little end-to-end view that your put together to sell your new idea to your economic patrons. Or may be it is that dreadfully large documentation that does a bible for the implementation team. EA, we should say, is one of the most debatable (flexible, for the positive you) terms of the industry. After all, you know how TOGAF’s introduction defines Enterprise:

A good definition of “enterprise” in […] context is any collection of organizations that has a common set of goals and/or a single bottom line. In that sense, an enterprise can be a government agency, a whole corporation, a division of a corporation, a single department, or a chain of geographically distant organizations linked together by common ownership.

And Architecture:

“the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution”.

So a simple fusion of above statements should be good enough a definition of EA.  But frankly, I am not one too impressed. An enterprise is an enterprise. The intuitive image of something holistic that pops up in your mind should be boundlessly more satisfactory than any definition. – the big picture, that is , if not the whole picture. Architecture is big picture. EA is a big picture of a big thing. So, let me try to make a contingent statement on my own right here.

Enterprise architecture of a business/ technological entity/domain “x” is the representation at a pre-defined degree of detail of the way “x” has been/is being/will be rolled out in the smallest possible technologically sovereign organizational entity that can be termed ‘enterprise’ in the purview of the project or program or scheme or system for which the architecture of x is deemed relevant.

Good – though I qualify it to be contingent, it should not be that bad a definition. Well, those who really want to hear a definition for Enterprise Architecture bigger than ‘just enterprise-wide IT architecture’ wouldn’t possibly settle for anything less than something with logical precision such as that one. After all, people do like it when the fence around fluidity is put up as firmly as possible.

But that opens up more problems. Among many, one stands out as the most fundamental question to be answered: How to scope anything that is enterprise- wide? Or at the very least, how to approach the scoping problem?

Who scopes the scope?

An important yet often overlooked sphere of scoping exercise is the “meta-scoping” or scope-of-scoping part. At best, we would get too busy in answering the Zachman interrogative model of What-How-Where-Who-When-Why religiously, only to find ourselves overwhelmed even before the gun goes off. In fact, what we have to essentially do at this point is to be very precise: the scope elements should be captured in words rather than sentences, tables rather than documents or “boxes-of-abstraction” rather than full-blown models. We will get plenty of time before we elaborate on any piece of elementary scoping information, as the key activity in the scoping phase is not done by the architect but the stakeholders and approvers. And this key activity is review and approval! Anyone who thinks otherwise is dealing with a dangerous recipe that has enough potential to perpetuate the burden of redundancy or irrelevance of one or more scope element throughout the life-cycle of an enterprise project.


An architect’s role in the scoping phase for the very first iteration is more of a scribe than a technologist, and rightly so. This is the most objective of all architectural activities and any drive to push in a lot of innovation at this part of affairs would only result in widening the mismatches between the expected and the delivered. And this, I believe, is pretty universal a rule for all scoping exercises.


Even while getting iterative with the scope at hand at a later stage, you essentially keep sharpening the scope, rather than elaborating or expanding it. Shrinking or expanding of it means business and money, and there are people out there who are far more concerned about them than you – in your capacity as a solution designer – are. Even the fine-tuning of the scope, which normally includes activities like defining / describing the scope elements should undergo rigorous reviews with business groups in order to get rid of all traces of subjectivity ( it is slightly different from discretion, though – believe me).


Having said all that, we should not fool ourselves by downplaying the need of systematic scoping in any Enterprise Architecture undertaking. Though there are plenty of guidelines available for scoping activity of EA within TOGAF and elsewhere, a practical approach would cut across frameworks as we are about to see.


Rapid Scoping

You, the architect, are there to deliver an optimum architecture in terms of comprehensibility, usability, efficiency and ROI. The fate of each of these “desirables’” would be influenced by the decisions you make in the planning and scoping phases (I like to see them as separate activities; we will talk on that in just a bit). If you are one among those fortunate or unfortunate ones who should be the master of your own actions by being able to make decision on entire  the architectural activities , the best way is to do the following upfront, before getting too much philosophical, metaphysical or even romantic with the work at hand.

Let us see how best we can start with the scoping problem. Open a text editor or your notebook and scribble (quite literally) the answers to these queries right-away as soon as you, the architect, come out of the project (of enterprise visibility) kick-off meeting:

1. What does the term “enterprise” mean to you? What do you think it means to stakeholders? Did you see a difference?

2. What domains (data/business/process/technology/organization/location/people) would your deliverables consist of?

3. Who is going to take up the architecture from the point where you leave?  

4. What will he/she/they be doing with it – will they go present it to the board-of-the-powerful or just put on the developer spikes and get going with it? That is, who is your deliverable going to face – the development crew or the business world or both?

5. Do they plan to manage /change control / govern the architecture?( only yes or no for the time – details later , just to see if what you plan to do is a proverbial “use-and-throw” architecture )

6. If there is no architectural governance in your side of the world yet, how long will the deliverable be valid? What event(s) would make the architecture invalid or needy for changes?

7. How much detailed should the deliverables be (just in terms of sheer paper space, for now) – can you afford a good 100 pages or 3 presentation slides? 


9. What is the verification mechanism by which you can make sure what you have captured as scope, valid?

After this quick session, the answers you would end up having in front of you may not be enough to spring much surprises in your mind, but will definitely have the potential to avert undesirable future surprises.

Now it is time for systematic scoping.


The Classic Interrogatives – power of simplicity

To ensure comprehensiveness, the best next foot forward is to go by Zachman Framework’s first horizontal. What-How-Where-Who-When-Why (We may term this as Rigorous Interrogation Method)

is a time-tested, robust way to pursue truth about almost everything imaginable – so there can not simply be a better way for upfront scoping.


This time, though, we don’t go as fast as we did in Rapid Scoping phase – we do it really meticulously. But before getting into potential challenges in the activity, let’s see what questions we need to actually ask in place of just What or How or .


What:    List of Business Objects,

Question: Which entities constitute the business?

How:     List of Business Processes:

Question: What does the business call various collections of activities that transform the enterprise inputs into enterprise services?

Where:  List of Business Locations

Question: Where ( which geographical entities ) is business rolled out ?

Who:     List of Organizations

Question: In which organizations does the responsibility for execution of processes and services rest?

When:   List of Events

Question: What are the events to which the enterprise responds ( upon their occurrence or relative to time) ?

Why:     List of Business Goals

Question: Where can we find pointers or references to business goals, objectives, strategies, or critical success factors significant to the enterprise relative to motivation?

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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s

%d bloggers like this: