Contextual Layer
The business context that everything else must serve: domains and sub-domains scope the area of concern, and the Business Attribute Profile is the normalising lens — the chain of accountability from business drivers down to technical implementation. (SABSA contextual layer.)
Breaking Down Each Concept
Each concept below sets out what it is, exactly what an architect needs to do to establish it well, the inputs it depends on, the outputs it must produce, and the mistake most likely to undermine it.
1. Business Driver
What it is: what the business actually needs from security — the requirements, goals and constraints that every downstream choice must trace back to.
What you need to do:
- Capture drivers directly from business stakeholders — strategy documents, regulatory obligations, board risk appetite statements, customer commitments — not from what security already knows how to deliver.
- Word each driver as a business statement, not a control statement: "customers must trust that their payments are safe," not "implement 3-D Secure."
- Trace each driver to a named business owner who can confirm it is real and current, not an assumption security has been carrying for years.
- Feed every driver into the Business Attribute Profile. A driver that never gets profiled is a requirement nobody is actually accountable for delivering.
- Revisit drivers whenever strategy, regulation or risk appetite changes; a stale driver quietly corrupts everything built on top of it.
Inputs: strategy documents, regulatory obligations, risk appetite statements, customer and stakeholder commitments.
Outputs: a documented, business-owned set of drivers ready to be profiled into business attributes.
Watch for: drivers written by security on the business's behalf. A driver nobody outside security recognises as their own will not survive the first serious challenge.
2. Business Attribute Profile
What it is: the normalising lens of the whole model — a curated set of business attributes that turns diverse drivers into a common language, anchoring the chain of accountability from business need to technical implementation.
What you need to do:
- Derive a small set of business attributes directly from the business drivers. Each attribute should be traceable to a specific driver, not invented in the abstract.
- Keep attributes measurable and testable — "Confidential," "Available," "Fast" — not vague aspirations nobody can assess a design against.
- Use the same attribute set across risk, control objectives, services and technical components. The value of the profile is entirely in it being one shared vocabulary, not a different list per team.
- Prioritise the attributes; not every attribute matters equally to every domain, and an unranked profile cannot resolve a genuine design trade-off.
- Keep the profile short enough that architects actually use it day to day. A profile with eighty attributes gets filed away, not applied.
Inputs: the business driver set, prior risk assessments, existing SABSA or enterprise architecture attribute catalogues if any exist.
Outputs: a prioritised, curated business attribute profile that domains, policies, control objectives and services can all be traced back to.
Watch for: an attribute profile built once at the start of a programme and never revisited. Attributes need the same governance discipline as any other architecture artefact.
3. Domain
What it is: the broadest scope within the service management architecture — an entire area of business concern, providing a high-level view of overarching goals and the foundation more specific architecture is built on.
What you need to do:
- Scope domains around genuine areas of business concern — "Payments," "Workforce Identity," "AI Governance" — not around existing team or system boundaries.
- Keep the number of domains small enough to govern. A domain map with fifty domains is a directory, not an architecture.
- Assign each domain an accountable owner who can speak for its policy and its sub-domains.
- Make sure every domain traces back to the business attribute profile. A domain that cannot explain which business attributes it protects is scoped around the wrong thing.
- Reuse domain boundaries already established elsewhere in the enterprise architecture — TOGAF architecture domains, ArchiMate capability areas — where they already exist, rather than inventing a parallel structure.
Inputs: the business attribute profile, existing enterprise or business architecture domain maps, organisational risk appetite by area.
Outputs: an agreed set of domains, each with a named accountable owner, ready to be governed by domain policy.
Watch for: domains that quietly mirror the org chart — the same failure mode capability maps fall into, and for the same reason.
4. Sub-Domain
What it is: a refinement of a domain into a focused, specialised segment, addressing particular aspects or components of its parent domain and enabling detailed, tailored architectural modelling.
What you need to do:
- Split a domain into sub-domains only when a genuinely distinct policy or risk profile requires it, not simply to mirror a team structure underneath the domain.
- Keep sub-domains at a consistent level of granularity across the domain map, so architecture reviews and gap analysis can compare like with like.
- Trace every sub-domain back to its parent domain's policy. A sub-domain with no distinct policy need probably shouldn't exist separately.
- Use sub-domains to enable tailored architectural modelling — different technology, different regulatory regime, different risk appetite — where the parent domain's treatment would otherwise be too coarse.
Inputs: the parent domain and its policy, evidence of a genuinely distinct risk or regulatory profile within the domain.
Outputs: a refined sub-domain structure that supports detailed, tailored architecture work without fragmenting governance.
Watch for: sub-domains created for organisational convenience rather than architectural need. They multiply governance overhead without adding traceability.