TOGAF 10 Architecture Principles: Structure & Business Continuity Example

Architecture Principle Components

TOGAF 10 defines each architecture principle with four elements:

Name : Must capture the rule's essence and be memorable. Should not reference specific technology platforms. Avoid vague words such as "support", "open", "consider". Use "avoid" cautiously because it lacks clear measurement criteria; prefer "govern" and eliminate unnecessary adjectives and adverbs.

Statement : Should concisely and unambiguously convey the fundamental rule. Principle statements across organizations tend to be similar; clarity is critical.

Rationale : Uses business terminology to highlight the business benefits of adhering to the principle. Draws parallels between information/technology principles and business operating principles. Describes relationships with other principles and the intent of trade‑off explanations. Specifies situations where one principle takes priority over another.

Implications : Emphasizes the resource, cost, and activity/task requirements for both business and IT when executing the principle. Acknowledges that existing systems, standards, or practices may conflict with the adopted principle; context determines the scope. Must clearly state the business impact and consequences so readers can easily answer "How does this affect me?".

Example: Business Continuity Principle

Name : Business Continuity

Statement : The enterprise maintains operations despite system interruptions.

Rationale : As system operations become ubiquitous, dependence on them grows; therefore reliability must be considered throughout design and use. All business premises must be capable of sustained operation regardless of external events. Hardware failures, natural disasters, and data corruption must not be allowed to interrupt or halt enterprise activities. The enterprise must be able to operate using alternative information delivery mechanisms.

Implications :

Dependence on shared system applications requires that business interruption risks be identified and managed in advance. Management includes but is not limited to regular reviews, vulnerability and exposure testing, or designing mission‑critical services to ensure continuity through redundancy or alternative functionality.

Recoverability, redundancy, and maintainability must be considered at design time.

Application criticality and impact on enterprise missions must be assessed to determine the required level of continuity and the corresponding recovery plan.

Reference: TOGAF 10 Standard Edition .