12   Special Cases

12.1      Architecture in an Agile Enterprise

There has been a great deal of conversation about aligning to agile implementation methods. Ink has been spilled trying to align the phases of the ADM to these development methods. All of this conversation has blurred the line between implementation and architecture. The TOGAF Standard aligns to agile development in Phase G. Full stop.

A good Architecture to Support Portfolio, or Project, will identify what products the Enterprise needs, the boundary of the products, and what constraints a product owner has. In short, a good architecture defines the Enterprise’s backlog.

Architecture to Support Project and Solution Delivery will have a set of constraints that limit the choices of the agile team. These constraints are where an individual product must bend to Enterprise issues and the parochial preference of a product owner is not valid.

Then Phase G, Implementation Governance: the Practitioner serves the stakeholders guarding the mission, vision, goals, and investment roadmap. In short, guarding Enterprise value.

12.2      Architecture for a Domain

A common failure path is for domain architects to work to a different purpose, or pretend that they are working on a different Architecture Project than the rest of the team. A domain[33] must fit into the whole of the EA. Also, the rest of the EA must fit with a domain. Anything else is a tourist dashboard decision (see Section 6.2).

A distinct domain is security. A security architecture only exists in reference to other domains and is best considered a concern. Practitioners will always address their stakeholders’ security[34] and risk concerns.

12.3      Architecture in Response to an Incident

Something happened, and the organization’s response is to fix it.

As a starting point the Practitioner should understand risk as the effect of uncertainty on reaching objectives, risk appetite, and risk tolerance. Achieving all objectives is uncertain, and an Enterprise’s response is driven by risk tolerance and risk appetite.

The risk appetite provides guidance balancing the amount of risk taken to achieve an expected outcome. Risk appetite is typically expressed as a boundary on a risk/business impact and likelihood grid, or qualitative measures. For example, the Enterprise will risk $x for $y reward this year, or has zero tolerance for loss of life. A well understood risk appetite defines both the level of risk the organization is willing to accept as well as its strategy in defining this level. For risks above this acceptable level, it defines the strategy used for mitigation. Strategy for risk in excess risk appetite is typically transference or avoidance.

Risk tolerance addresses deviations from what is expected. In short, what to do when the Enterprise’s uncertainty is exceeded. The most common expression of uncertainty is failure to achieve expectations. At this point, the Enterprise is certain it will not achieve its objectives.

An incident changes the stakeholders’ preferences with regard to risk. This is a change in requirement, and the architecture must adjust. The central role of the Practitioner is to provide solid advice on what changes to the target, and the associated work to achieve the change will reach an acceptable certainty of reaching the stakeholders’ objective. Practitioners should not be surprised when there are few changes that have an acceptable cost, and the stakeholder is faced with the option of canceling the objective or canceling the change.

return to top of page

---

---