The Open Group OGEA-103: Architecture Principles That Guide Decisions
Architecture principles are durable rules that help teams make consistent decisions when detailed standards do not cover every situation. A principle should be broad enough to apply across multiple initiatives but concrete enough to influence design. Statements that merely sound desirable—be secure, be scalable, use standards—do not provide enough direction to resolve tradeoffs.
Within enterprise architecture, principles create a stable layer between strategy and solution detail. They help teams evaluate alternatives, explain why a design is preferred, and recognize when an exception needs governance. The TOGAF approach treats principles as part of the architecture foundation that informs subsequent work.
The strength of a principle comes from its rationale and implications. Those elements explain why the rule matters and what teams must do differently because of it.
Write principles around decisions, not slogans
A useful principle describes the direction for a recurring decision. “Reuse shared capabilities before creating duplicates” can influence platform choice, funding, ownership, and integration. “Be efficient” cannot. The wording should be memorable, but the explanation should make it possible for two teams to apply the principle in a similar way.
Least privilege is a good example because it changes how identity, permissions, administration, and automation are designed.
Connect each principle to a business rationale
A principle without rationale feels arbitrary. The rationale should identify the enterprise outcome being protected: resilience, regulatory compliance, data consistency, cost control, customer experience, strategic agility, or another material concern. This makes the principle easier to defend when it imposes short-term delivery cost.
The rationale also helps determine when an exception is reasonable. If the original business concern does not apply to a particular context, governance can evaluate the exception without treating the wording as an absolute law.
Implications turn abstract direction into action
Implications should explain the consequences for teams, processes, information, technology, funding, and operations. A data-sharing principle may imply common definitions, data ownership, metadata, access controls, quality measures, and integration standards. A cloud-first principle may imply network connectivity, identity federation, cost controls, skills, and exit considerations.
This connection between words and delivery prevents governance drift. Teams can see the operational behaviors expected by the principle instead of treating it as poster text.
Avoid principles that duplicate standards
A principle should not hard-code a product version or implementation detail that belongs in a standard. Standards can change more frequently as technology evolves. Principles should remain stable enough to guide several generations of solutions.
For example, a principle about interoperable interfaces can survive changes in API gateways or messaging platforms, while the specific protocol or product belongs in a technical standard or reference architecture.
Use principles to compare alternatives consistently
When architecture options are evaluated, principles provide criteria that are already agreed. Teams can show which option aligns, which conflicts, and which tradeoffs require an exception. This reduces the risk that every project invents a new decision framework.
Architecture governance can then focus on material conflicts rather than reopening settled enterprise preferences for every initiative.
Review principles when the enterprise changes
Principles are durable, not permanent. Strategy, regulation, operating models, technology, and risk appetite change. A principle that once reduced complexity may later prevent a necessary platform shift. Periodic review should ask whether the rationale remains valid and whether the implications still reflect how the enterprise operates.
Retiring or changing a principle should be deliberate because downstream standards, roadmaps, and designs may depend on it. The repository should preserve the history so teams can understand why prior decisions were different.
The best set is small enough to remember
An enterprise with dozens of overlapping principles makes it hard for teams to know which ones matter. A smaller, coherent set supported by domain standards is usually more useful. OGEA-103 candidates should be able to reason about how principles guide the ADM, while practitioners should be able to show how those principles change real decisions.
That decision focus connects principles to roadmaps and capability planning: strategic direction becomes useful only when it shapes priorities and change.
Manage principles as a coherent decision system
Principles should be tested for overlap before approval. If two principles frequently point teams in opposite directions without explaining which has priority, the set creates confusion instead of guidance. Sometimes the conflict is legitimate—such as standardization versus local autonomy—but then the enterprise should state how the tradeoff is resolved or which decision authority interprets it.
Each principle needs an owner or steward. Ownership does not mean the person can unilaterally change the principle; it means someone watches how the rule is being applied, gathers exception themes, and proposes updates when the rationale or implications no longer fit. Unowned principles tend to remain in the repository long after teams have stopped using them.
Principles should be visible in design templates and review criteria. If teams must remember to search a repository for them, the rules will be applied inconsistently. Architecture decision records can include a short field for which principles influenced the choice and which ones required an exception, making the relationship between guidance and decision explicit.
Training should focus on scenarios rather than definitions. Teams learn a principle better by applying it to competing architecture options than by memorizing wording. Scenario exercises also reveal ambiguous implications. If reasonable practitioners interpret the principle in very different ways, the text or examples need improvement.
Domain principles can exist beneath enterprise principles when necessary. Data, security, integration, infrastructure, and product architecture may need more specific guidance, but domain rules should not contradict enterprise direction silently. Traceability between levels helps reviewers understand whether a local standard implements or overrides a broader principle.
Exception patterns provide evidence for review. A principle that generates many justified exceptions may be too broad, too rigid, or based on an outdated operating assumption. Conversely, a principle with no visible influence on decisions may be so vague that teams can claim alignment regardless of what they choose.
Principles also help during mergers, reorganizations, and platform consolidation because they provide a stable statement of intent when individual standards are in flux. A team can use the principle to evaluate temporary coexistence choices before the target technical standards are fully defined.
A healthy principle set creates constructive constraint. Teams should understand the direction before they start solution design, but they should also have a clear path to challenge the rule with evidence. Principles are strongest when they make decisions faster and more explainable rather than when they are treated as unquestionable doctrine.
Architecture principles can also reveal hidden strategy conflicts. A principle that emphasizes local product autonomy may conflict with a strategic need for enterprise data consistency. Rather than masking the tension, architecture should make it explicit and define which concern takes priority in different contexts. That conversation is more valuable than producing two principles that every team can selectively quote.
Examples improve application. For each principle, teams can document one or two aligned decisions and one example of an exception that would require governance. Examples are not part of the rule itself, but they give practitioners a shared interpretation and reduce debate over basic meaning.
Principles should influence sourcing as well as design. A vendor or managed service may be technically attractive yet conflict with requirements for portability, data residency, interoperability, or operational ownership. Including principles in evaluation criteria ensures that procurement decisions do not create architecture constraints that are discovered only after contracting.
Principle changes require migration thinking. If the enterprise adopts a new direction, existing systems will not become noncompliant overnight in a useful sense. The organization needs transition guidance that distinguishes new-build expectations, modernization priorities, tolerated legacy states, and deadlines for critical remediation.
When principles are applied consistently, they reduce the number of decisions that require escalation. Teams know the default direction, governance focuses on real exceptions, and roadmaps can assume a more coherent future state. That is a practical measure of principle quality.
Principles should also be tested against real portfolio decisions before they are declared final. A draft principle may appear sensible until teams apply it to cloud sourcing, data sharing, platform ownership, resilience, or vendor selection and discover that the implications are contradictory or impractical. Pilot application provides evidence about whether the wording is too broad, too narrow, or missing an important tradeoff. Once adopted, the principle can then enter governance as a stable default with much higher confidence that teams understand how it affects real design choices.
Finally, principles should be written so they can survive different delivery methods. A rule that only makes sense in a traditional project stage-gate model may become irrelevant when teams move to products, platforms, or continuous delivery. Outcome-oriented principles remain usable because they constrain what must be protected while allowing teams to decide how the outcome is achieved. This makes the principle set more durable across organizational and technology changes.
A concise principle catalogue also helps onboarding. New architects and engineering leaders can understand the enterprise’s default direction without reading every historical decision. That shared baseline shortens design discussions because teams can begin from established intent and spend their time on the parts of the solution that are genuinely new.