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:
- Enterprise Scope
- Time Period
- Architecture Domains
- Level of Detail or Vertical Scope
Enterprise Scope
The Enterprise Scope is usually defined by using one of two models:
- The publish and subscribe model
- 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:
- Integration of components
- Associated risk
- Affordable level of detail
- Likelihood of change
Architecture Domains
There are four main domains that fall under the title of “Architecture Domains” – they are:
- Business
- Data
- Application
- 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.