As a first step in your efforts to develop an Enterprise Architecture, you could think of chartering the EA exercise to answer important questions, such as:

• Why would you need EA? objectives/goals?
• What is the vision of your EA practice?
• What would be your scope in your first iteration (typically, you cannot have EA in one shot!)?
• What kind of deliverables are expected as outcomes of your EA practice?
• What kind of governance you’re proposing in order to facilitate execution?

In this post, I will try to answer what goes into a typical scope of an Enterprise Architecture practice.  But first, what’s scoping anyways?!

In its simplest forms, scoping is knowing what to do, and more importantly what not to do. 

In order for you to know what (not) to do, you need to know three (3) important things of any effort or practice:

• The final outcome desired – result.
• The steps or activities needed to achieve that outcome – process.
• The available inputs to those steps that enable them to richly and adequately achieve the desired outcome – input.

By scoping, you might fully consider the whole outcome (the result).  You also might think of chopping that up into smaller outcomes and tackle those one by one to help you achieve the whole result, gradually.  Note that these smaller pieces need to be logical and each need to get you closer to your grand one.

Chopping (scoping!) can affect the steps or activities to be carried our (the process itself).  That can be accomplished by either eliminating or focusing on some of the steps. Also, an important guide to chopping is the available inputs – both hard inputs such as documents and processes, and soft inputs such as people and time.

Let me give a simple example before we dive into how to scope EA itself. 

Example: Developing a new learning website.

This is originally adapted from a great book by Dan Roam – The Back of the Napkin: Solving Problems and Selling Ideas with Pictures.  As Dan states, in order to develop a new educational website, all you need is the following:

Everything we need to know to create a learning/educational website
(adapted from “The Back of the Napkin” book)

This constitutes your desired outcome: a website that delivers content to be consumed in a variety of ways which would result into a brand that people will admire.  In order for you to have a manageable and effective scope, you’ll need to chop it up according to the above circles individually while maintaining the overall framework and connections. 

For instance, you may focus on digital text content, and exclude multimedia or vice versa.  You can think of delivering focused content for KG vs. K12.  For the brand, you would need to take it as a whole (no chopping), cause you cannot plan for a partial brand!.  Function can tackle delivering courseware, exams, on-site vs. off-site, self-service vs. sponsorship, etc.

On the other hand, you can see how your process (steps and activities to achieve your above outcome) will be minimized accordingly.  You would take different approaches when delivering different kinds of content (text, media, games, art, …).  You will also have focused activities on the method of delivery and consumption.

If you stop at this stage, then you’re risking the whole thing!  You didn’t consider what available inputs (or resources) you have that will enable you to practically scope that project.  For instance, delivering media content without the right people in your team who are specialized in media production/editing can be dangerous.  Including your entire portfolio of content and consumption will be different if you have a 3-month or a 1-year project, and so on.

What to scope in EA?

Similarly, we need to consider the three important things in developing an EA in order to know what to scope: the result, the process, and the available inputs.

Result – desired outcome of an EA practice:

• What does an EA look like in its final form? – the hard/concrete part.
• What is EA set to do or achieve? – the soft part.
• What are the typical components and/or deliverables of EA?
• What are the levels of detail for these components/deliverables?

Process – the steps and activities that need to be conducted:

• Which approach or framework your planning to follow in developing your EA?
• Which standard process (in the chosen framework or approach for instance) exist to help in knowing the step-by-step process?

Inputs – available data and resources:

• What kind of data are available at the moment that are crucial to developing your EA?
• What timeframe, people, and budgets you’re planning to shoot for, or already have in hand?
• What budget are you possibly allocating for this practice?

To summarize, I’m including here an adaptation of the “Structure of the TOGAF Document” which gives a simplified view of what an EA looks like:

TOGAF – simplified

One could scope an EA by chopping off its final form into pieces.  For instance:

• By focusing on building the capability (the team), and founding the process.
• By focusing on specific content and deliverables such as business architecture vs. technology architectures.
• By serving specific units of business vs. the whole enterprise.
• By affecting critical business operations leaving the rest for later.

You could also guide your scoping effort by looking at the available inputs:

• Having a documented base of business processes gives you a head start at developing the overall business architecture.  When that’s not available, then you need to consider the effort needed to do at least a high level business architecture for you to have a meaningful scope, and hence a meaningful EA.
• Having a timeframe of 6 months is tight compared to a 1- or 2-year horizon.  Hence, you will need to chop off your desired outcomes with time in mind.
• The presence of senior business analysts, architects, and overall knowledge of EA within the leadership team will be a push or a pull to your efforts.  Considering this will enable you to put the required resources and plans of readiness in your scope.

Scoping according to the process steps is also possible.  The risk lies in the potential of not showing enough value in the early stages while waiting for future ones to cover and build momentum.

Objective-driven scoping:

Your objectives and goals out of developing and having an EA practice should be your guide when scoping.  If the main goal of EA is to formalize the relationship with the business and to better align with them then it wouldn’t be wise to excessively document the current and future states of the technology architecture.  Instead, you need to focus on developing the EA Governance (team, committees, rhythm of collaboration, …).

On the other hand, if your approach is technological where you need to better understand current environment to rationalize your application portfolio (by eliminating redundancy, for instance).  This will trigger a need for a scope that focuses on data and application architecture guided by a high level understanding of business vision and processes (business architecture).

This explains why breadth (which architecture domains to cover) and depth (to what degree of details you need your models to capture) of architecture is a critical element and view of your scoping exercise. 

See my post on why would you pursue an enterprise architecture for a bit of details on different approaches in developing an EA.

To Recap

You have the following views to look through when scoping your Enterprise Architecture (EA):

• Outcome view:
  • Scope of the enterprise (business units, partners, …)
  • Scope of the architecture domains (business, information, technology, …)
  • Depth of details (considering the variety of models)
• Process view:
  • What does your proposed process of developing an EA look like?
  • How many steps (and which ones) of that process can you plan to conduct for the present vs. the future?
• Inputs view (works as both constraints and enrichment of your scope)
  • Available time
  • Available team and knowledge
  • Available details (documents, data, previous efforts, …)

Hope you enjoyed it, and please remember me with a piece of comment!

Further reading

For some extra reading, have a look at the following:

• Gartner: Toolkit – Sample of a Starter Enterprise Architecture Program Charter
• TOGAF® Version 9.1 – ‘The Book’: 5.5 Scoping the Architecture.
• Enterprise Architecture : How Not To Miss Anything? by Sethuraj Nair (Part I and Part II)