Why security architecture is not a separate domain, why every stakeholder has security concerns, and how security services differ from a control framework.
From Ultra Transcenders OGEA-102 by Tony Rough (publishing soon)
Security is called cross-cutting because security architecture is not a fifth domain with a phase of its own. It is a consistent collection of views, viewpoints and artifacts, covering security, privacy and operational risk perspectives, objectives and services, which shapes each of the four domains: Business, Data, Application and Technology.
Common trap: Building a stand-alone security architecture with its own stakeholders and roadmap - security artifacts must be developed alongside, and integrated with, the domain architectures in B, C and D.
Integrating security does not mean ticking controls off a list. G152 bundles controls into security services, which behave like Architecture Building Blocks that steer the choice of Solution Building Blocks. Its examples include Identity and Access Management, Continuity Management, Security Intelligence, Digital Forensics, Security Analytics, Audit, Network Monitoring, Compliance Management, and Training and Awareness.
| Item | What it holds | Role in the architecture |
|---|---|---|
| Control framework (such as ISO/IEC 27001/27002, COBIT, PCI-DSS) | Requirements that controls must meet | Listed in the Applicable Control Framework Register; a source of requirements |
| Security Services Catalog | The building blocks that actually provide protection, with shared terminology | Defined in Phase C (the SABSA logical layer); steers SBB selection later |
Common trap: Treating a selected control framework as the security architecture - a framework lists requirements, whereas the Security Services Catalog describes the services that meet them, chosen through business-driven risk assessment.
This note is one section of Ultra Transcenders OGEA-102: Enterprise Architecture Practitioner, an independent study guide that explains every learning unit the exam covers, topic by topic, with comparison tables, diagrams and the common traps, plus a glossary linked to the TOGAF Standard.
Publishing soon on Amazon in Kindle and paperback editions.
About the book · OGEA-102 terms in the glossary · All OGEA-102 study notes
What each architecture state means, why candidate work cannot govern change, and a practical way to organise states and recency in the repository.
How to identify stakeholders beyond the organisation chart, classify their positions, place them on the power/interest grid and tailor what each group receives.
Why more than one option is worth showing, the criteria used to judge them, and how the choice is made jointly with stakeholders at a formal review.
The three basic approaches to change, the implementation methodologies that follow them, and how readiness and risk evidence point to the right fit.
What an Architecture Contract settles, the points in the cycle where contracts arise, and the three kinds of contract with the parties each one binds.
How the governance body decides how large a response a change deserves, the three categories of change and the stakeholder guideline for redesign.
The three classes of standard, the five lifecycle states from proposed to retired, and what a deprecated standard does and does not require.