A security architect's map of capability

Part of the series: Getting it organized properly. Notes from a field still finding its shape.

The view from one stack

The word capability shifts meaning depending on who is using it. Across disciplines this is well known. Inside a single architecture stack it is less obvious and easier to miss.

The SABSA framework organises an enterprise into five layered views, from the Business View at the Contextual Layer down to the Tradesman's View at the Component Layer (figure 2). A sixth view, the Service Manager's, sits vertically across the other five. Each view answers a different question. When a security architect uses the word capability in conversation with a TOGAF colleague, the question being asked depends on which view the conversation is in.

The Open Agile Architecture standard acknowledges a related confusion. Its Operations Architecture chapter notes that operations management uses the capability concept without a commonly agreed definition, and lists clearer terminology as one of its design goals. The same pattern shows up inside the SABSA stack.

This piece reads the SABSA views from a security architect's vantage and notes the question each one is asking when it uses the word capability. Seven viewpoints, seven questions, one word.

Seven viewpoints

Each SABSA view names a different concern about the enterprise. The Service Manager's view is structurally different from the other five. It holds no concern of its own and asks an operational question of each.

Figure 2 shows the TOGAF role for each SABSA layer. The Enterprise Architect does not map directly because it has a cross-cutting concern. It's work spans the stack as a whole.

Each layer asks a recognisable question to the TOGAF role about capability. The table below pairs each SABSA layer with the TOGAF role and the question that the layer asks about capability.

The Service Management capability question is a capability question about another view's concern. The view asks whether each of the others is real.

Read across, each row holds one viewpoint and the working vocabulary that goes with it. Read down the Named Capability column, the word capability takes seven shapes inside a single stack.

A closer look at one row

The Conceptual layer question is wider than the others, and the width is worth examining because the choice of phrasing changes what the row appears to cover.

One candidate phrasing is what value do we deliver, and to whom. That phrasing is recognisable. It draws on value stream work, service design, and the business model canvas. It is also narrower than what the row actually holds.

The Business Architect, in ADM Phase B, owns more than the value proposition. Phase B covers business strategy, governance, organisation, key business processes, capability mapping, value streams, and organisational structure. The SABSA Conceptual Layer is similarly broad. It is where the abstract model of the enterprise is expressed in business terms, before any solution shape is chosen. Asking only about value delivery answers part of the question and leaves the rest of the row unrepresented.

Widening the question to what does our business do, and how is it organised to do it matches the role and the layer. It is a design choice rather than a correction. Value delivery sits inside the wider frame.

The other rows do not need this treatment. Each names a concern at its own layer cleanly. The Conceptual layer is the one row where the question has a real width to it, and where the choice of phrasing changes what the row appears to cover.

What this gives the reader

The table is not a proposal. It is a working vocabulary that a security architect can carry into a meeting where the word capability is doing several jobs at once. The translation work is the point. The vocabulary is what makes the translation possible.

The questions matter more than the labels. A capability question identifies the view the speaker is standing in. Once the view is known, the rest of the row follows. The role becomes clear. The artefact becomes clear. The kind of evidence that would answer the question becomes clear.

The Named Capability column is the practical part. The seven labels can be reached for when precision is needed. A speaker who names one is identifying a different concern than a speaker who names another. Naming which shape is in use is a small habit that saves a larger conversation.

Organising this is harder than naming it. The work is collective and slow. The field gets organised by many people writing carefully about what they can see clearly. This article is one small contribution to that work.

• Jacco Meijer
• |
• May 11, 2026

Reading the security architect three ways

CISSP, TOGAF, SABSA and what each one is for

read more

Sources cited

• The SABSA Institute. SABSA White Paper (W101, 2009 revision).
• The Open Group. TOGAF Standard, 10th Edition. Architecture Roles and Skills Series Guide. 2024.
• The Open Group. TOGAF Series Guide: Business Capabilities.
• The Open Group. Open Agile Architecture (O-AA) Standard. 2020.