Architecture blueprints · Insight
Blueprint before you build.
Nobody would put up a building floor by floor with a different architect for each. Many organisations build their security estate exactly that way.
In brief
A blueprint makes the common security decisions once, so each programme only has to make the decisions that are genuinely its own.
Every significant change programme meets the same security questions. How do people and systems prove who they are? Where may sensitive data live, and how is it protected there? What is logged, and who watches it? Without a shared answer, each programme answers under its own deadline, with its own suppliers. The estate that results works, more or less, but it is expensive to run, hard to explain and full of gaps between solutions that were never meant to meet.
What a blueprint contains
- Context: the business objectives, critical services and risk scenarios the architecture must answer.
- Principles: a short list of design rules, each with its reason and its consequences.
- Capabilities: what security must be able to do, independent of any product.
- Target architecture: conceptual and logical views across identity, data, cloud and platforms, applications and operations.
- Patterns and transition: reusable designs, a roadmap from today to the target, and the design authority that keeps delivery on course.
It speeds delivery up
The usual objection is that architecture slows projects down. In practice the opposite tends to happen. When patterns exist, a project starts from an approved design instead of a blank page, and security review concentrates on what is new. The slow path is the one where every design is argued from first principles, late, by people who were not in the room when the decisions were made.
Signs you need one
- Two programmes have solved the same security problem in different ways in the past year.
- Nobody can say quickly why a given control exists, or what would break without it.
- Security review is seen as the step that delays go-live.
- A cloud move, acquisition or platform change is about to multiply the number of design decisions.
Questions for your next leadership meeting
- Do our delivery teams have approved security patterns to start from?
- Can we trace our largest security investments back to the risks they address?
- Who has the authority to say a design does not meet our security architecture?