Objectives

1. Ensure that the Requirements Management process is sustained and operates for all relevant ADM phases
2. Manage architecture requirements identified during any execution of the ADM cycle or a phase
3. Ensure that relevant architecture requirements are available for use by each phase as the phase is executed

Stakeholder Engagement and Requirements Management

The TOGAF framework places requirements management and stakeholder engagement at the centre of architecture development. Practitioners develop EA in accordance with the preferences and priorities of their organisation’s stakeholders. Architecture is never sold to a stakeholder. Stakeholder preferences are never manipulated.

Stakeholders own the architecture and the value preference and priority the architecture is expected to enable. Practitioners must completely submerge their preferences, biases, and priorities. Practitioners must act for their stakeholders.

This is one of the most difficult activities a Practitioner must perform. Good Practitioners are passionately engaged in the future of their organisation, as well as participating in defining and realising the target state. Practitioners typically perform several roles: they will act as Subject Matter Experts (SMEs) and agents for their stakeholders in addition to developing architecture – see Chapter 15 for a discussion of roles. As an SME, the Practitioner is a source of expert advice. As an agent, the Practitioner may speak on behalf of a stakeholder. In order to be successful when performing these roles, the good Practitioner must understand when they are acting in a different role and behave appropriately.

Effective requirements management is dependent upon clear traceability from the organisation’s vision, mission, business model, and strategies through the most detailed statement of requirement. In order to perform this, the Practitioner must carefully distinguish between direct effective support and loose association. Things that do not best enable the complete set of stakeholder preferences are distractions from the main chance.

When engaging with stakeholders, Practitioners must maintain the complete set of every stakeholder’s preference, and the implications of those preferences. Success requires abandoning absolute and entering the realm of satisficing¹. Bluntly, if there is a single obvious best answer, the organization’s stakeholders do not need an architecture.

Effective engagement is based upon effective communication. Effective communication is based on the concept of view and viewpoint. Different stakeholders have different concerns about the architecture. These concerns must be addressed and represented effectively to the stakeholder to enable the stakeholder to approve the Target Architecture.