The first step is figuring out where the EA team fit within the organization, and being clear about their role within the operating model.
Quite frequently I get asked about the scope of Enterprise Architecture. Sometimes the question is a simple one: what is included in a typical EA initiative? But sometimes there’s a bit more to the question, with an implied: why is that included in EA? This question came up a couple of times this week, so it seemed a good time to go over some of the key points in this blog, and explain what TOGAF has to say about scope.
It’s worth pointing out that the scope of a project is always limited by the role of the EA team within an enterprise. If the EA team works only within IT, and has little contact with business people, then the scope of an EA project isn’t likely to directly cover business processes. Similarly, if your enterprise is large conglomerate covering many different business ventures across the world, then there may be more than one EA team and a number of independent enterprise architectures.
TOGAF says that the “business operating model concept is useful here to determine the nature and scope of the enterprise architecture within an organization” [1. Introduction]. In the Preliminary Phase one of the objectives is to determine the architecture capability required by the organization, and this is where you “review the organizational context for conducting enterprise architecture” and “identify and scope the elements of the enterprise organizations affected by the Architecture Capability”.
So the first step is figuring out where the EA team fit within the organization, and being clear about their role within the operating model. Now that we know our place within the company we can think about the scope of a particular architecture initiative. This task is covered in Phase A: Architecture Vision of the ADM [7. Phase A: Architecture Vision]. The scope is determined by several things:
- Stakeholders, Concerns and Requirements. It almost goes without saying, but a surprising number of EA teams forget that they are there to address these needs!
- The Request for Architecture Work declares what the stakeholders are expecting. Scope should never cover anything more than what is being asked for!
- The available resources, and their competence, experience and knowledge. It’s OK to stretch people, but an inexperienced team won’t be able to deliver a complex EA outcome without additional help!
- Whether the organization is ready and able to undergo the change. This is covered in TOGAF by the Business Transformation Readiness Assessment [30. Business Transformation Readiness Assessment].
Practical considerations may also mean that a large scope is subdivided into smaller chunks, and each of these may be covered by a separate iteration of the ADM.
Once the scope is clear, it needs to be documented! TOGAF suggests documenting the scope:
- In the Statement of Architecture Work [36.2.20]
- From an intentional, qualitative view in the Architecture Definition Document [36.2.3]
- From a quantitative perspective of the implementation in the Architecture Requirements Specification [36.2.6]
- When the scope changes, in a Change Request [36.2.11]
- Of course, deciding what is in scope means that some things are likely to be out of scope. Any requirement that is out of scope should not be forgotten! It should be an input to the Requirements Repository, and managed through the Requirements Management process as part of another scope in the future.
- Finally, the scope is formally managed through an Architecture Contract [36.2.2], which is “the joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture” .
One final point I’d like to mention – because TOGAF doesn’t make this so clear – is that the Content Framework and metamodel provide a great checklist of subject matter that might need to be included within the EA scope.
Getting the scope right is so important to every EA initiative, and TOGAF has quite a lot to say on the subject! It is well worth spending the effort to check that what you are going to deliver is exactly what is required, and it’s important to get this documented and signed-off in the Architecture Contract so that everyone has a common understanding and commitment. And it’s equally important to know whether the organization has the necessary skills, experience or appetite to make the changes!
