Architecture That Serves the Business: Cloud-Native, Platform Thinking, and Compliance as Code

TL;DR: Seven business-architecture principles decide whether an Azure environment serves a capability the organisation actually needs, and compliance as code is the one that turns regulation into enforcement instead of paperwork.

A control written into Azure Policy enforces itself. The same control written into a Word document only describes itself.

Everything below hangs off that one difference.

Seven principles sit in this track: business capability mapping, platform thinking, compliance as code, minimising vendor lock-in, cloud-native first, API-first design, and microservices where they actually earn their keep. The technical pillars ask whether a workload is reliable, cheap, secure. These ask something ruder. Is this the right workload at all?

They lean on the Cloud Adoption Framework rather than any one Well-Architected pillar, because business alignment cuts sideways through all of them. What follows takes each into Azure practice, with compliance as code as the hinge between business architecture and the evidence a regulated organisation has to produce on demand. It is one of five companion walkthroughs under the architecture principles a real Azure assessment measures against.

Compliance as code, the sharp end (BA03)

Codify a control and it runs on every deployment, forever, whether or not anyone remembers it exists. That is the whole pitch. Compliance as code means putting regulatory and security requirements into automated validation: each control written as an Azure Policy definition, checked continuously instead of assessed once a year by someone with a spreadsheet and a deadline.

Compliance stops being an event and becomes a state.

On Azure the mechanism is unglamorous and concrete. Policy definitions encode the requirement. Storage accounts must enforce HTTPS. Resources must carry a data-classification tag. Public network access must be off on databases. Assign those in Deny mode and the violation never lands. Initiatives group them into regulatory bundles for NIS2, DORA, ISO 27001 Annex A, and GDPR, and a landing-zone design applies them at the management-group level so every subscription inherits them without anyone remembering to opt in. Defender for Cloud’s regulatory-compliance dashboard then reports posture against each framework.

That is the design. Here is what I keep finding instead: policy assigned in Audit mode.

Audit tells you about the violation after it exists. Deny stops it existing. Most estates I open are sitting almost entirely in Audit, which means the policy is not enforcing compliance at all. It is documenting non-compliance, politely, at scale, into a blade nobody opens.

Audit mode is a smoke alarm with the battery taken out.

“But if we flip everything to Deny, we break every deployment on Monday morning.”

Yes. Some of them. That is the point, and it is also the honest measure of how far the estate has drifted from the thing you told the auditor it was. If Deny would break your pipelines, your pipelines are currently producing non-compliant resources and Audit mode is the reason nobody has had to care. Start with the controls where a violation is genuinely unacceptable, run those in Deny, and let the noisy ones sit in Audit while you fix the templates behind them. What you cannot do is leave the whole estate in Audit and call the result a control environment.

I will say the uncomfortable version plainly, because this is where a competent peer is allowed to disagree with me: a control in Audit mode is worse than no control at all. Not equal. Worse. Nothing enforced, and a dashboard that lets everyone believe otherwise, including you when you sign the attestation.

Whether a policy enforces or merely observes is the same question I pull apart in Azure Policy versus architecture assessment. Both jobs matter. They are not the same job. Compliance as code is the distance between a control you can prove was always enforced and one you hope somebody followed.

Cloud-native first, and what it rules out (C01)

Lift a virtual machine into Azure unchanged and you have moved a workload. You have not adopted a cloud.

Cloud-native first means designing the application to exploit what the platform does (elasticity, distributed architecture, managed services, self-healing) rather than dragging a 2014 architecture onto someone else’s hypervisor. It rules out the lift-and-shift that relocates a VM and gets reported upwards as cloud adoption. It asks for different design patterns than on-premises applications, real expertise in cloud-specific technology, and the willingness to refactor or replace legacy applications instead of just migrating them. That last one is where most programmes quietly stop.

On Azure it means Azure Kubernetes Service or Container Apps for orchestrated workloads. Functions for event-driven compute. Managed data services like Azure SQL Database and Cosmos DB instead of database servers you patch yourself at two in the morning. Platform scaling and platform self-healing rather than the hand-built approximations of both that someone left behind when they changed jobs.

The finding is the migrated estate that runs on Azure without ever once using Azure. Virtual machines patched by hand. Databases backed up by a script. Scaling performed by a human being watching a dashboard and clicking. It works, in the narrow sense that the lights stay on. It also forfeits every reliability, cost, and operational benefit the platform offers, because the architecture predates the platform and nobody was ever funded to redesign it.

Hosting on Azure and being built for Azure are different things. Only one of them earns the platform’s advantages, and you are paying platform prices either way.

API-first and microservices (C04, C05)

These two get welded together in conversation constantly, so lead with the difference. API-first is nearly always right. Microservices are a trade-off that is right sometimes.

API-first design means defining the API before implementing any specific interface, so capabilities are exposed through contracts that were thought about ahead of the code sitting behind them. Microservices means decomposing into independently deployable services only where that decomposition creates business value.

API-first on Azure runs through API Management as gateway and contract layer, OpenAPI definitions written before implementation, and managed identities securing service-to-service calls. One backend, many front ends: web, mobile, partner integration. Clear boundaries. Integration that does not require a discovery project first. The cost is design work up front, which the principle treats as an investment rather than overhead, and which is usually the first thing cut when a delivery date moves.

Microservices carry the deliberate qualifier: decompose only where it creates business value. Independent deployment, specialised technology per service, team autonomy. Those benefits are real. So is the operational complexity, which is not appropriate for every application or every organisation.

The finding cuts both ways. Sometimes it is a monolith that should have been split at an obvious domain boundary years ago and never was. More often, in mid-market estates, it is the reverse: a system shattered into a dozen services that bought all the operational overhead of a distributed system without the scale, the traffic, or the team count to justify any of it. Now four people own eleven deployment pipelines.

Architecture by fashion, in both directions.

Capability mapping, platform thinking, vendor lock-in (BA01, BA02, BA04)

Three principles, one shared job: make the architecture sustainable rather than merely functional. Anchor it to something durable. Make the next build faster than the last. Know what leaving would cost.

Business capability mapping (BA01) ties technology to stable business capabilities instead of the org chart, which never stops moving. Organise architecture around “claims processing” or “customer onboarding” and it survives the reorganisations that would otherwise trigger a rebuild of things that were working fine. It also gives you a way to discuss architecture with people who do not want to hear about subscriptions.

Platform thinking (BA02) builds reusable internal platforms (landing zones, shared services, golden-path templates) that abstract the complexity so each new capability ships faster than the one before it. The price is upfront investment and ongoing product management. A platform nobody maintains becomes a platform everybody routes around, and then you have two platforms.

Minimising vendor lock-in (BA04) is the explicit trade-off principle: weigh the advantage of Azure-native services against a realistic exit. It does not tell you to avoid proprietary services, because that forfeits the reason you came here. It tells you to know the cost of leaving and keep it bounded. This is exactly the concern DORA Article 28 raises for financial entities: concentration risk on a critical third party, plus a documented exit strategy.

The finding is almost never too much lock-in or too little. It is that nobody ever made the trade deliberately, so the exit cost stays unknown until an examiner asks and the room goes quiet.

The evidence a business-aligned estate leaves behind

Do all of the above and you produce, almost as a side effect: a capability map, landing-zone and platform documentation, policy initiatives encoding regulatory controls, API contracts in API Management, and a documented vendor-exit assessment.

That list is architectural maturity and examiner material at the same time. Compliance as code is the centre of gravity, because policy initiatives running in Deny mode are simultaneously the enforcement mechanism and the proof of enforcement. One artefact, both jobs.

The mapping is direct. DORA Article 28 wants a critical-third-party register and a documented exit strategy: the vendor lock-in assessment is that evidence. NIS2 Article 21 wants governance of security measures: the compliance-as-code initiatives are the continuous record. ISO 27001 wants documented controls, and the codified policies are the controls, version-controlled and dated, which is more than most control documentation manages.

A business-aligned estate throws off this material because the principles that align architecture to the business are the same ones that produce auditable governance. Nobody plans it that way. It just falls out.

Writing that Audit-mode paragraph by hand into consecutive assessment reports is what eventually annoyed me into building Platform Architecture Authority. Same finding, same estate shape, same slightly re-worded explanation of why a dashboard full of green ticks was not evidence of anything. So I taught the thing I do to a tool, and now it reads the environment and writes the boring parts. Which capabilities to platform-ise first, or where lock-in is an acceptable trade, is still a decision a person has to make.

FAQ

What is the difference between compliance as code and Azure Policy? Azure Policy is the mechanism; compliance as code is the practice. Compliance as code is the discipline of translating regulatory requirements into testable, automated controls and enforcing them continuously. On Azure, Azure Policy in Deny mode is the primary tool that implements it, grouped into initiatives aligned to NIS2, DORA, and ISO 27001 and applied at the management-group level.

Does cloud-native first mean I must use Kubernetes? No. Cloud-native first means designing to exploit cloud capabilities (elasticity, managed services, self-healing), which Azure Kubernetes Service provides but so do Container Apps, Azure Functions, and managed data services. It is about exploiting the platform, not about a specific orchestrator. The right cloud-native service depends on the workload.

When are microservices the wrong choice on Azure? When the operational complexity they add exceeds the business value they create, typically in smaller environments without the scale or team structure to absorb the overhead. The principle decomposes only where it creates value. A well-designed modular monolith is frequently the more reliable and cost-effective choice for mid-market workloads, and over-fragmentation is a common finding.

How does minimising vendor lock-in relate to DORA Article 28? DORA Article 28 requires financial entities to assess concentration risk on critical third parties and document an exit strategy. The vendor lock-in principle produces exactly that evidence: a deliberate assessment of what depending on Azure-native services costs to exit, kept bounded and documented rather than discovered when an examiner asks.

Architecture in service of the business

The technical pillars make a workload reliable, affordable, operable, and secure. The business-architecture principles decide whether it should exist: aligned to a capability the organisation actually needs, built to exploit the platform it sits on, governed by controls that enforce themselves, and honest about its own exit cost.

The things worth keeping from all this. Compliance as code turns regulation into enforcement, because NIS2, DORA, and ISO 27001 controls written as Azure Policy in Deny mode make validation continuous instead of a periodic scramble. Cloud-native first means exploiting Azure, not merely hosting on it. Map architecture to business capabilities rather than the org chart, because capabilities outlast the boxes that keep being redrawn. Platform thinking accelerates everything after the first build, if somebody owns the platform. And microservices and lock-in are trade-offs, not goals: split where it earns its keep, weigh Azure-native services against a realistic exit, and treat neither extreme as a virtue.

Before you finish reading this, go and open the policy compliance blade on your own production subscription and count how many assignments say Audit. That number is your real control environment, not the framework name at the top of the dashboard.

An architecture that serves the business is one where the controls are the code, the capabilities are durable, and the trade-offs were made on purpose.

Not inherited by accident from whoever built it first.