High Security / High Compliance: When Business Architecture needs a System Engineer

Business architecture often describes what the enterprise wants. System architecture explains how responsibility is decomposed, allocated, integrated, verified, and proven. High-security and high-compliance environments require both.

I have my roots in systems engineering. Large systems. Complex problems. No well-established industry patterns for breaking the problem into manageable chunks. I learned that interfaces and software contracts are fundamental to enabling teams of engineers to work independently, side by side.

Business architecture comes from another tradition. It solves a different set of challenges. Enterprise, domain and solution architects usually have the luxury of focusing on business value, processes and data because many technical interfaces are already defined by standards bodies or suppliers. Integration is often considered afterwards, with a focus on data models.

But high-security and high-compliance environments are much less forgiving.

My concern here is with business-oriented architecture in enterprise IT, particularly when its models are not complemented by explicit interface specifications and deliberate allocation of security requirements across subsystems.

The problem

Describing what must be true is not enough. “Protect sensitive data” and “ensure auditability” must become concrete obligations. Architecture must show where they are fulfilled, who is responsible and what evidence demonstrates fulfilment.

The full set of requirements applies to the system of systems as a whole. But passing that entire set to every subsystem does not solve the problem. Requirements must be broken down and deliberately allocated. Each subsystem must carry its share, with neither gaps between responsibilities nor unnecessary duplication.

Interfaces become contracts for the handover of responsibility. They specify what each side must fulfil, what it can rely on from the other, and how that handover can be verified. They are not merely connections for exchanging data, but boundaries for trust, control and verification. This is where an architecture focused on business processes and data models alone becomes too thin.

What is Business Architecture

Business architecture is concerned with how the enterprise works and how it should evolve. What capabilities does it need? Which processes, information and applications support them? Who owns what, and how should change be governed? Capability maps, process and information models, and roadmaps help describe the answers and guide change.

The Good

Its strength is handling organisational complexity. It gives business and technology teams a common language and connects technology decisions to business purpose. Business architecture helps prevent individual systems and projects from being optimised at the expense of the whole.

By relating capabilities, processes, applications and ownership, it can reveal duplication, fragmented responsibilities and gaps that are difficult to see from within individual projects. It provides a basis for deciding where to invest, what to build or buy, and which systems to consolidate, modernise or retire. These decisions can then form a coordinated roadmap rather than a collection of unrelated initiatives.

The Bad

Much of enterprise IT rests on technical foundations supplied by standards, platforms and vendors. Networking, virtualisation, identity and logging can often be treated as available services rather than systems to be designed. The work shifts towards selecting, configuring and combining established building blocks.

The same applies to business applications. HR, finance and customer management systems arrive with predefined workflows, data models and interfaces. Once a product has been selected, much of its architecture is already fixed. Integration becomes something fitted around it, with attention naturally turning to data mapping and synchronisation.

This encourages a habit of treating interfaces as implementation details, delegated to suppliers or integration teams. The question becomes whether systems can exchange data, rather than what each side must guarantee when they do. Buying the building blocks does not settle the responsibilities between them.

The Ugly

Without clear interfaces and responsibility boundaries, compliance becomes difficult to prove. The architecture may describe the processes and applications involved, yet leave unanswered which requirements each subsystem must fulfil. Policy states what must be done, but does not establish where it is done or who must demonstrate it.

Requirements apply to the system of systems as a whole, but their fulfilment depends on deliberately allocated obligations across its subsystems. The architecture must establish how those obligations fit together.

Without explicit interface contracts, there is also no agreed basis for verifying the handover. What must the sending system guarantee? What must the receiving system check? Which evidence demonstrates that their combined behaviour fulfils the requirement? Individual systems may pass their assessments while the gaps between them remain both unspecified and untested.

How System Architecture Comes to the Rescue

System architecture starts by defining the system boundary, its dependencies and its interactions with other systems and actors. It then decomposes the system and allocates requirements deliberately. The same discipline applies at each level, from the system of systems down to its subsystems, including the people, processes and suppliers needed to fulfil the requirements.

Interface specifications make the responsibilities at each boundary contractual. They define what each side must provide, what it may assume about the other and how failures are handled. Security obligations, operational ownership and evidence requirements belong alongside protocols and data formats. The interface becomes an architectural object to design, maintain and verify, not merely a connection to implement.

Requirements can then be traced from their source through their allocation to the relevant interfaces, verification methods and evidence. Each subsystem can be assessed against its own obligations, and handovers can be verified against agreed contracts. Requirements concerning the combined behaviour of several subsystems must still be verified at the system level. Decomposition makes verification manageable; it does not remove responsibility for the whole.

Evidence is planned as part of this work. The architecture identifies what must be demonstrated, where the evidence is generated, who owns it and how it is protected and retained. Verification and audit then have a defined chain to follow, rather than one to reconstruct afterwards.

Conclusions

High security and high compliance expose the gap between stating what the enterprise must achieve and demonstrating how its requirements are fulfilled.

Business architecture remains essential. It provides the purpose, priorities and organisational context needed to make sensible engineering decisions. System architecture brings the discipline to translate those decisions into obligations that can be assigned, integrated and verified.

Interface specifications belong at the centre of that collaboration. Standards and suppliers may define how systems communicate, but the organisation must still establish what each side guarantees and how those guarantees fulfil the wider requirements. Interfaces must be treated as contracts to design and verify.

Explicit interface contracts also allow teams to develop and verify their own parts independently, with a clear understanding of what they must provide and what they can rely on from others.

High-assurance organisations need architects who can connect the enterprise view with these system-level responsibilities. The architecture must show not only that the individual parts meet their obligations, but that those obligations fit together to fulfil both the business and the security requirements of the whole.

Andreas Olsson