Scoping an architecture and comparing alternatives

Why restrict the scope

Few teams can address the whole enterprise at once. The scope of architecture work is restricted for three main reasons, all linked to practical limits.

Ideally, the chosen scope allows the work of all the enterprise’s architects to be governed and integrated. This requires aligned architecture partitions, to avoid duplicate or conflicting activities, together with clearly defined re-use and compliance relationships between those partitions.

• The organizational authority of the team producing the architecture
• The stakeholder objectives and concerns to address
• The people, funding, and other resources available

Four scoping dimensions

Scope is first described in terms of breadth, depth, and time period. Once these three dimensions are understood, the combination of architecture domains suited to the problem is chosen. These decisions are revisited at every ADM iteration.

Example: a mutual insurer wants to modernize claims handling. The team limits breadth to the claims department, stays at a logical level for depth, targets a three-year horizon with a milestone at eighteen months, and selects the Business, Data, and Application domains, technology being handled only through constraints. Each choice is justified by the team’s authority, the sponsor’s concerns, and the available budget.

• Breadth: how far does the enterprise extend, and which part does this work cover?
• Depth: down to what level of detail should the work go?
• Time period: what horizon for the vision, and does the same horizon suit the detailed description?
• Domains: a complete description contains Business, Data, Application, and Technology

Alternatives and trade-offs

Building an architecture almost always means arbitrating between competing forces, such as cost, security, or speed. There are often several possible Target Architectures, all conforming to the Architecture Vision, principles, and requirements.

Identifying these alternatives and comparing them brings out the trade-offs between them. Presenting them to stakeholders triggers reactions that reveal hidden agendas, principles, and unstated requirements that may change the final target. TOGAF provides a dedicated technique for this, Architecture Alternatives and Trade-Offs, which structures exploration and discussion.

In practice, the architect describes each alternative, assesses how it meets the priority concerns, makes gains and sacrifices visible, then submits everything to stakeholders. The chosen target, with the rationale for the choice, then feeds gap analysis. Comparing is therefore not a waste of time: it is a way to obtain an informed and shared decision.