The four dimensions of scope

There are four main dimensions that are typically used to limit and define the scope of an Architecture.

  1. Breadth
  2. Depth
  3. Time Period
  4. Architecture Domains

Breadth

Determine the extent of the enterprise or organisation and how much of that extent should the architecture effort focus on. It is important to understand that many organisations are large and are comprised of separate business units. These separate business units can be thought of as enterprises in their own right. Modern businesses further blur this distinction as many businesses embrace a combination of traditional business enterprise as well as partners, customers and suppliers.

Depth

Depth describes to what level of detail an architect should go to when creating an architecture. The challenge here is deciding on how much architecture is enough and when to stop and the delineation between other related activities or systems.

Time Period

Specifies the time period for the initial phase – Architectural Vision and is the specified amount of time realistic based on resources available.

Architecture Domains

Typically when creating an Architecture Description the description should contain information pertaining to all four domains:

  1. Business
  2. Data
  3. Application
  4. Technology

Sometimes, due to constraints such as time and resources there often not enough resources available to create an all inclusive architecture description that covers all four domains.

Typically when creating the scope of an Architecture the scope is expressed in:

  • Breadth
  • Depth
  • Time

Once the scope of the organisation is understood then a suitable combination of architectural domains is selected based on the problem being addressed.

The Scope of Architectural Activities

How to limit and define the scope of Architectural Activities

It is important to understand that constraining the architecture activities is a vital part of how teams are structured within an organisation.

Within TOGAF there are four main aspects to consider when constraining the scope of an architecture:

  1. Enterprise Scope
  2. Time Period
  3. Architecture Domains
  4. Level of Detail or Vertical Scope

Enterprise Scope

The Enterprise Scope is usually defined by using one of two models:

  1. The publish and subscribe model
  2. Segment Architectures

The publish and subscribe model is the most common way of defining an Enterprise Scope and is most useful where an organisation is decentralised and architectures are developed in parallel.

The success of the publish and subscribe model depends on a functioning architecture governance which may include:

  • Compliance projects and reviews
  • Dispensation process definitions
  • Applications or projects that do not comply but are paramount in order for the business to operate

Segment Architectures are to be used where a business or organisation is divided up into segments. Each of these segments are likely to be functional areas and these segments are directly assigned to architecture teams.

Time Period

Transition Architectures are extremely important where an architecture team needs to stay relevant in organisations that are dynamic and fast paced. Where an organisation or business follows a transition architecture the organisation is able to respond to changes or crisis much more easily.

The ability to adapt to change easily is because the value delivery for the organisation is based upon specific and short transitions that will build up to the final architecture.

Level of Detail or Vertical Scope

When determining the level of detail or “Vertical scope” there are four main factors:

  1. Integration of components
  2. Associated risk
  3. Affordable level of detail
  4. Likelihood of change

Architecture Domains

There are four main domains that fall under the title of “Architecture Domains” – they are:

  1. Business
  2. Data
  3. Application
  4. Technology

Some organisations or businesses divide their architecture teams up to work on one of the specific architecture domains only. There is an issue with separating the architecture teams up in this way and that is:

All domains rely on the Business Domain to ensure alignment between the business capability requirements and the proposed solutions that will be implemented to fulfill the requirements.