SECURITY ARCHITECTURE THAT THE TRANSFORMATION PROGRAMME CANNOT OVERRULE.
The problem
Security architecture fails most often not because it is wrong, but because it is disconnected.
A security team produces a target-state design. It is technically sound. Six months later a transformation programme, a cloud migration, or a new core banking platform arrives with its own architecture, its own governance, its own timeline — and the security design is either retrofitted awkwardly or quietly abandoned.
The root cause is structural. Security architecture that is not anchored into the organisation's enterprise architecture has no mechanism to survive contact with a funded programme. It has no seat at the design authority, no place in the change process, and no leverage when a delivery date is at risk.
The organisations where security architecture holds are the ones where it is a domain within the enterprise architecture, governed by the same board, gated by the same process, and expressed in the same language the business already uses.
Where security architecture fails
Four failure modes, and every one of them is an integration problem rather than a technical one.
It is produced in isolation. Written by the security team, for the security team, in security vocabulary. The transformation programme never reads it.
It has no gate. There is no point in the delivery lifecycle at which a design must pass security architecture review to proceed. Where no gate exists, review becomes advisory, and advisory becomes optional.
It is not traceable to business capability. A control that cannot be traced to a business capability it protects cannot be defended when its cost is challenged. It is the first item cut.
It has no owner after the consultant leaves. Architecture that is not governed decays within eighteen months. Without a design authority, a review cadence and named ownership, you have bought a document rather than a capability.
OUR APPROACH
-
Anchor to business capability. We start from what the organisation actually does and what would constitute unacceptable disruption. Security architecture that cannot be traced to a business capability is a preference, not a requirement.
-
Structure the architecture properly. We work in SABSA and TOGAF structures — business, information, application and technology layers, with security as a domain rather than an overlay. This matters because it is the structure the enterprise architecture function already uses, and it is what many GCC enterprise and financial-services procurement processes expect to see.
-
Establish the design authority. Charter, decision rights, gate criteria, escalation route. Which designs require review, at which stage, who approves, and what happens on disagreement. This is the single control that determines whether the architecture survives.
-
Embed security gates into the delivery lifecycle. Secure-by-design gates at initiation, high-level design, detailed design and pre-production. Defined entry and exit criteria at each. A gate with no criteria is a meeting.
-
Produce the roadmap sequenced by dependency. Not by ease, and not by budget year. Asset inventory gates most downstream capability. Identity gates most of the rest. A roadmap sequenced for political comfort will stall in month nine.
-
Transfer the capability. Reusable patterns, document templates, review checklists and documented decision rationale — so your architects can operate the model without us.
ENGAGEMENTS
EA-01 Enterprise Security Architecture Baseline
Typical duration: 15-25 days
Current-state capability assessment, target-state reference architecture, dependency-ordered gap roadmap
EA-02 Architecture Review Board Establishment
Typical duration: 8-12 days
Charter, decision rights, gate criteria, escalation model, templates, first three sessions chaired
EA-03 Secure-by-Design Gate Framework
Typical duration: 10-15 days
Security gates embedded into your project and delivery lifecycle, with entry and exit criteria
EA-04 Security Reference Architecture Library
Typical duration: 15-25 days
Six to ten reusable patterns for your own delivery teams and bid library
EA-05 Estate Rationalisation Assessment
Typical duration: 12-18 days
Tool overlap analysis, consolidation roadmap, recoverable annual licence spend
EA-06 Design Assurance
Typical duration: 3-7 days
Independent review of third-party HLD/LLD, risk-rated findings, sign-off memorandum
EA-07 Greenfield & Giga-Project Secure-by-Design
Typical duration: 20-40 days
Security architecture embedded at the design phase of a new build or major programme