Please note that for existing customers services will continue to operate as usual for the immediate period and you do not need to take any action.
TOGAF Scope Partition

What’s the Difference Between Scope and Partition

Published: April 1, 2015
Share on:

Newcomers to TOGAF sometimes find scoping and partitioning to be rather confusing. This is partly because scope and partition both use similar criteria to create a boundary to what is included in the scope or partition, and what is excluded. The question came up again with an EA team embarking on their first use of TOGAF – so I thought it would be useful to explain the differences between the two.

You might also find it useful to refer to one of our early posters on TOGAF – #9, which covered Architecture Partitioning and Integration. The dimensions used to partition or integrate the architecture are typically the same ones that must be addressed when scoping architectures.

The first point to make is that the architecture of an enterprise is a huge monster to tame, understand or manage!

EA is not the same in all companies, but it typically covers the components, their structure, their relationships and their behavior across all of IT, all business, all management disciplines, and all relevant external factors from areas such as government regulations, partners and suppliers, customers, or the broader environment in general.

Even with a very large EA team and unlimited resources it would be impossible (and unnecessary) to deal with the whole architecture at once. So we need to break it down into more manageable chunks.

Accredited Training Courses

The second point is that, even though we break EA into smaller units that are easier to manage, each of those sub-divisions remains part of the whole. And because a change to any part of the architecture can have an impact on other components – because a functional architecture operates as a single, complete unit or system – we also need to understand how each subdivision fits into the bigger picture of the enterprise architecture as a whole.

I’ve shown why we need to break the architecture into manageable chunks, and why we need to make sure that each chunk fits into the bigger picture of the whole enterprise architecture.

We need to do this to manage the overall evolution of the enterprise architecture, and to manage a particular architectural project. This is the essential difference between partitioning and scoping.

We partition so that we can keep track of evolution of the complete enterprise architecture. According to TOGAF this is to help us manage:

  • Complexity, by dividing the enterprise into chunks with manageable complexity & effective governance.
  • Divergence, by providing a mechanism to handle differences & conflict between organizational unit architectures.
  • Change, by allowing different teams to own & work on different elements of the architecture at the same time.
  • Resources, by helping us to accommodate the realities of time, funding and resources.
  • And Reuse, by creating modular architecture segments that can be reused in other contexts.

We scope so that we can keep track of evolution of a part of the complete enterprise architecture through the efforts of a particular program or project. In TOGAF terms, this is an iteration of the ADM.

This distinction between partition and scope seems quite simple – partition to manage the whole enterprise architecture, scope to manage a part of the enterprise architecture in a project. I think there are two reasons why it gets confusing:

  1. TOGAF describes three levels of detail or enterprise organizational depth: enterprise, segment and capability.TOGAF then describes three broad architectural roles: enterprise, segment and solution. The levels of detail and the roles are not an exact match, which is confusing! [I said in an earlier blog that the role of segment architect doesn’t usually appear under that name; and I also haven’t come across any organization with the role of capability architect.]
  2. TOGAF suggests using the ADM at each of the three levels of detail: enterprise, segment and capability. But the ADM is only described once – in Part II of the documentation – as a generic architecture development methodology. So the TOGAF documentation doesn’t make it very clear on how the ADM would be used differently at each of the levels.

What can we do to Remove This Confusion?

  1. One way is to think of the TOGAF levels differently. You might find it more useful to give them alternative names. One option is to use enterprise / segment / project.TOGAF use capability for the lowest level of detail, which can be confusing because a business capability is typically an aggregation of a large number of architecture components from different domains that contribute to a particular, and often unique, enterprise competence. Whereas in practice, at this more detailed level, EA teams often need to show how a particular project fits into the higher levels of segment and enterprise.
  2. Keep in mind that although the Preliminary Phase talks about architecture partitioning and scoping, you are more likely to be doing partitioning in an iteration of the ADM at the enterprise level, and possibly the segment level. While you will be doing scoping when you use the ADM for a particular project.

One final point – I’ve explained why scoping and partitioning can be confusing in TOGAF, and suggested some ways to remove this confusion.

Just remember that when you take the exam to get TOGAF certification, you will be tested on what TOGAF says in the TOGAF documentation! The things I’ve written here are just to help make sense of what happens in practice!

More Free Resources