Azure Architecture for Microsoft-Centric Enterprises

Azure Application Architecture for Microsoft-Centric Enterprises: How Do You Decide the Shape Before You Build?

By Michael Branson | August 24, 2026

Quick answer. Azure application architecture for Microsoft-centric enterprises settles four decisions before code: identity, hosting, data and integration boundaries, and the operating model that runs the result. A named question decides each one, and writing the answers down is what stops a build drifting into a snowflake.

The request that starts this work rarely arrives in architectural language. A director says the team needs a real application to replace the thing that grew out of a spreadsheet, that it has to sign people in the way everything else does, that finance wants to know what it costs to run, and that the two people who will support it already support nine other systems. Underneath those four sentences sit four architecture decisions, and the order they are answered in decides how much of the design survives contact with the estate. An organization already standing on Microsoft identity, data and integration is not choosing from a blank catalogue.

What “Microsoft-Centric” Actually Changes About the Decision

An enterprise running on Entra ID, Microsoft 365, SQL Server and a Power Platform tenant has already settled four constraints that a greenfield architecture diagram pretends are open.

Identity is settled. The directory exists, conditional access policies exist, and employees already have accounts. External, merged-in and shared-device populations are the exceptions to check. An application that invents its own user store is not a simpler design; it is a second directory to keep in step with the first, and a second offboarding process nobody runs.

The data gravity is known. The reference data lives in SQL Server, in Dataverse, or in a line-of-business system with a supported interface. Where the new application’s data sits relative to those stores decides more about latency, reporting and migration cost than the hosting choice does.

The integration surface is inherited. Microsoft 365, Dynamics, SharePoint, and whatever ERP the finance team runs each impose a connection pattern. The application does not get to define these; it gets to decide which of them it depends on synchronously and which it tolerates being late.

The support model is fixed. The team that will hold the pager already runs the estate, with the skills it has. An architecture requiring a skill nobody on that team holds is a decision to hire, whether or not anybody wrote it down.

Microsoft’s own framing supports reading the constraints before the components. The Microsoft Azure Well-Architected Framework pillars drive architectural excellence at the fundamental level of a workload, and the framework pairs each of its five pillars, Reliability, Security, Cost Optimization, Operational Excellence and Performance Efficiency, with a workload concern and with its own tradeoffs page. Striking a balance between them is the framework’s own instruction, and a design that claims to maximize all five has not written down what it gave up.

Identity Is the First Architectural Decision, Not the Last

Identity gets treated as a configuration task late in a build, and that sequencing is what sends enterprise Azure builds back for rework. Identity belongs first: the hosting rung has to carry the application’s identity, and data access and integrations authorize against it.

Two separate questions hide inside the word identity. The first is how people sign in. In a Microsoft-centric estate that answer is Entra ID, and the real design work is what the application does with the token afterwards: which claims it trusts, whether authorization lives in group membership, in application roles, or in a table the business owns. Group-based authorization puts control in the directory team’s hands. Table-based authorization gives the business owner control, and gives you an access review nobody runs unless a person is accountable for it. Pick one deliberately, then write down who administers it.

The second question is how the application authenticates to everything else, and this one has a defensible default. Microsoft’s documentation on managed identities for Azure resources opens on the problem directly: a common challenge for developers is the management of secrets, credentials, certificates and keys used to secure communication between services, and manual handling of secrets and certificates are a known source of security issues and outages. Managed identities eliminate the need for developers to manage these credentials, in the two forms Microsoft names system-assigned and user-assigned. A design that still moves a secret through a deployment pipeline to reach an Entra-authenticated resource has kept the credential handling the platform already eliminates, and that choice needs a reason in writing.

The limit on that default: managed identities authenticate to any resource that supports Microsoft Entra authentication. A system with its own credential model sits outside them, and that boundary is where a secret store and a named rotation owner earn their place.

If identity is configured by whoever gets to it last, the architecture is being decided by accident. The i3solutions Enterprise Entra ID Configuration & Integration Services practice is where that work sits when the directory needs attention first.

The Hosting Decision Ladder, and the Question That Decides Each Rung

Hosting is the decision buyers ask about first and the one that matters second. Each rung buys capability and charges operational attention for it.

Microsoft’s guidance frames the choice as a flowchart rather than a ranking. Choose an Azure compute service states that the term compute refers to the hosting model for the resources that your application runs on, and directs the reader to use its flowchart to select a candidate compute service, branching first on whether a workload is being migrated or something new is being built. The build-new branch evaluates the need for full control, high-performance computing, event-driven workloads, managed web hosting, and orchestration requirements before it names Virtual Machines, Azure Batch, Azure Functions, App Service, Azure Container Instances, Azure Red Hat OpenShift, Azure Kubernetes Service (AKS), or Azure Container Apps.

Four of those services form the rungs for an enterprise line-of-business application. The table names the question that settles each.

Read the ladder downward, once per deployable component, and stop at the first rung that answers yes, unless a rung further down carries a requirement the one above it cannot express: that requirement outranks the stopping rule. The expensive mistake is choosing AKS for a requirement nobody wrote down, then discovering that cluster upgrades belong to a two-person team already carrying an estate. The counter-case is real: an application with a genuine networking or operator requirement, or a portability commitment somebody signed, belongs on AKS, and putting it on App Service to look simple is the same error reversed.

The rung also decides who you have to hire, so the support team belongs in the room while the rung is decided. Where the environment underneath the application needs building rather than choosing, that scope sits with Azure Development Services for Regulated Enterprise Workloads.

If the hosting rung is the argument in your organization right now, it is cheaper to have with an architect who will say App Service out loud when App Service is the answer. Talk to a senior architect. The conversation is about which rung your application belongs on, and the answer is sometimes the least fashionable one.

Data and Integration Boundaries: Microsoft 365, Dataverse and Line-of-Business Systems

The data tier decision in an estate that already runs on Microsoft is rarely a database bake-off. It is a boundary question: what does the application own, what does it borrow, what does it merely display.

What it owns goes in a store the application controls, which for enterprise application work on Azure commonly means Azure SQL, on the strength of the team’s existing SQL skills rather than any abstract superiority. Ownership means the application’s schema, its migrations, and its backup and retention obligations.

What it borrows lives somewhere else and is read through a defined interface. Dataverse is the frequent case here, and the boundary is worth drawing carefully: an application that treats Dataverse as its own transactional database has taken a dependency whose limits and licensing another team owns, without having chosen either. Reading across a service boundary is a design; writing in a tight loop from a custom application is a decision nobody made.

What it merely displays should not be copied at all. A copy is a synchronization problem with a schedule attached, and it needs an owner, a freshness expectation, and a plan for the day it drifts. The Microsoft 365 boundary is the sharpest version. Files, sites and messages already have a governance model, a retention model and a compliance surface. An application that duplicates that content into a store without those controls has moved it outside that governance, and the copy becomes its own compliance obligation.

The integration pattern behind those boundaries is a separate body of work with its own reference designs. Where the question widens to how the estate’s integrations are designed and governed as a whole, Microsoft Integration Architecture for Large Enterprises is the reference guide that covers it. What belongs here is the application-level version: for each dependency, name the direction, the failure behaviour, and the acceptable staleness. A dependency without a documented failure behaviour is one the application will inherit an outage from.

The Operating Model the Architecture Has to Assume

An architecture is a commitment about who operates the result. Four things belong in the design because they are expensive to add later.

Environments. How many, who deploys to them, and what has to be true to promote. Two environments and an honest promotion rule beat four nobody trusts. This is architecture rather than process because environment count drives subscription layout, network design and cost.

Landing zones. Microsoft defines the term precisely. What is an Azure landing zone? defines the term as “a proven and flexible architecture for governing, securing, and scaling a multi-subscription Azure environment”, which is Microsoft’s claim for its own reference architecture rather than a guarantee about any given tenant’s implementation of it. Microsoft names two components: the platform landing zone, “the centralized foundation that establishes governance, security, and shared resources for all your Azure workloads”, and application, or workload, landing zones, “the environments where workload teams deploy and operate workload resources within the guardrails of the platform landing zone”. That split tells an application team what it controls and what it inherits. Where the platform component already exists in your tenant, the guardrails are given. Where none exists, platform foundations have to be built before the application lands, and who funds that work belongs on the plan, not in a surprise. Its build-out cost has its own published numbers, covered at How Much Does an Azure Landing Zone Cost to Deploy? and not restated here.

Observability. The useful test is not how many dashboards exist. It is whether the on-call engineer at two in the morning learns three things quickly: that something is wrong, which dependency is wrong, and whether users are affected. That implies telemetry with a correlation identifier that survives across service boundaries, dependency-level tracing so a slow downstream call is told apart from slow code, structured logs with a retention period somebody chose on purpose, and alerts on user-visible symptoms rather than resource metrics alone. An alert on processor utilization tells the engineer that a machine is busy. An alert on failed sign-ins tells them a person cannot work. What telemetry a dependency outside the application emits is a question for its owner.

Cost ownership. Every resource carries a tag naming the owning application and the paying cost centre, applied by the deployment rather than a quarterly cleanup, because untagged spend becomes a shared mystery nobody is accountable for reducing.

What Will This Cost to Run, and Who Owns the Number

Predictable Azure cost is an architecture property before it is a finance exercise, and three decisions carry the bulk of it.

The hosting rung sets the floor. A managed platform tier bills on a shape the team can reason about. A cluster bills for nodes whether or not the application is busy, and adds the salaried cost of the people who keep it current, which never appears on the invoice.

The data tier sets the slope. Storage grows, and the growth rate is a design consequence of the retention decision rather than an accident. Retaining everything forever because deletion was a conversation nobody wanted is a permanent purchase.

The chattiness sets the surprise. Cross-region traffic, per-transaction integration services, and log ingestion at volume are the three lines that arrive larger than expected, each driven by application behaviour rather than a provisioned size. Log volume is worth deciding at design time: it is straightforward to reduce by choosing what to record, and awkward to reduce afterwards.

The discipline that makes the number hold is unglamorous. Estimate before building on published rates for the shape you chose; discounts and reservations move that baseline afterwards. Tag at deployment. Put one named person in front of a monthly review with authority to act on it. A dashboard does not switch off an idle environment on its own.

If running cost is the part finance is pushing back on, that is a conversation worth having before the build rather than after the first month of billing. Talk to a senior architect. That conversation covers which parts of your design are driving the number.

Where the Boundary With Power Platform Sits

Not every application on this ladder should be custom code, and an architecture page that pretends otherwise is selling rather than advising.

The honest test is what the application has to do that a low-code platform does not do well: a complex or high-volume transactional model, a user population whose licensing arithmetic breaks, an interface the platform’s connectors do not reach, performance behaviour that has to be tuned rather than accepted, or a lifecycle that has to sit inside the same release process as the rest of the estate. Where none of those apply, a Power Platform build is the shorter road to production. Where any of them applies, that trigger is the case for custom.

Between the two lies a hybrid solution, where a Power Platform front end sits over custom Azure services and APIs. It is a legitimate architecture with its own boundary rules about which side owns data, which side owns business logic, and how the two are released together. Those rules belong to the guide titled “Hybrid Power Apps and Custom Development”, drafted here and not yet published, so it is named rather than linked.

What an Architecture Decision Record Should Contain

The artifact that keeps all of this from evaporating is a short record per decision, written when the decision is made rather than reconstructed later. Six fields carry the weight.

The decision, stated in one sentence, in the active voice, naming what was chosen. The context, the constraints that were real at the time: the tenant, the team’s skills, the deadline, the budget. The alternatives considered, each with the reason it lost, because the alternative nobody wrote down is re-proposed later by somebody new. The consequences, including the ones the organization accepts rather than avoids, which is where the Well-Architected tradeoff belongs in writing. The owner, a named person accountable for revisiting the decision. The revisit trigger, a condition, not a date: a user count, a transaction volume, or a licensing change.

A record set covering identity, hosting, data ownership, the integration boundaries and the operating model runs to a handful of pages. It is the difference between an architecture a new engineer can join and a system whose shape has to be inferred from its code. Standard patterns rather than snowflakes is what happens when the reasoning is written down and the exceptions have to justify themselves.

Where i3solutions Fits on Azure Application Architecture

i3solutions has designed and built line-of-business applications on the Microsoft platform as a Microsoft partner since 1997. Delivery is senior and US-based.

The limit on this page’s claims is worth stating plainly. What the Azure platform does is cited to Microsoft’s documentation above; what a senior architect adds is judgment about which constraint in your estate is binding, plus the willingness to recommend the least impressive option when it is correct. No architecture practice, this one included, can name the right hosting rung without reading your identity model, your data gravity, and the team that will hold the pager. Reading all three first does not change the order the decisions are made in.

When This Is Not the Work You Need

Some readers should route elsewhere, and it is cheaper to say so here.

If the question is whether to modernize the application at all, and in which direction, that decision comes before this page and belongs to the guide titled “The Five-R Modernization Decision”, drafted in this cluster but not live yet. If the application already exists and nobody can say what it does, architecture is premature: the discovery work covered by the guide titled “Enterprise Application Discovery Before a Rebuild”, likewise drafted but not live, comes first. If what you have is a working prototype, the guide titled “Prototype to Production”, a third cluster page awaiting publication, owns that question. And if integrations across the estate are designed case by case with no reference pattern, that is integration architecture at estate altitude.

What is left is the case this page was written for: one application that matters, a Microsoft estate that already sets the binding constraints, and a decision about shape that somebody has to make defensibly. Identity first, then the hosting rung, then the boundaries around data and integration, then the operating model the result assumes. Bring your tenant’s current state and the names of the people who will support it. Talk to a senior architect. Which decisions are already made for you and which are genuinely open is the first thing to settle, and the Custom Application Development Services for Enterprise Performance practice is where the build sits.

Frequently Asked Questions

What Azure architecture fits a Microsoft-centric enterprise application?

The one that reads the constraints the estate already sets before it opens a service catalogue. Four decisions carry the design. Identity comes first, because Entra ID already holds the employee accounts and the application’s authorization model has to be administered by a named person. Hosting comes next, chosen by working down four rungs and stopping at the first that answers the requirement. Boundaries for data and integration come third, deciding what the application owns, borrows, and merely displays. The operating model comes fourth, covering environments, landing-zone guardrails, observability and cost ownership. Recording each decision with its alternatives is what keeps the result a standard pattern rather than a snowflake.

App Service, containers or Functions: how do we choose?

Work down four rungs and stop at the first that answers yes, unless a rung further down carries a requirement the one above it cannot express. App Service fits a web application or API that ships as one deployable unit with no need for custom orchestration. Azure Functions fits event-driven or scheduled work that is short-lived and idle between runs, at the price, on the serverless plans, of cold starts, execution limits and idempotency becoming your problem. Azure Container Apps fits several containerized services that scale independently without cluster-level control. Azure Kubernetes Service fits a concrete networking, operator or portability requirement the managed options cannot express, and it charges cluster management, upgrades and security to whoever runs the cluster.

How do we keep Azure application costs predictable?

Three architecture decisions carry the bulk of the number, and one operating habit protects it. The hosting rung sets the floor, because a cluster bills for its nodes whether or not the application is busy. The data tier sets the slope, since storage growth follows the retention decision. Chattiness sets the surprises, and the three lines that arrive larger than expected are traffic crossing regions, integration services billed per transaction, and log ingestion at volume. The habit is ownership. Estimate on published rates before building, treating that as a baseline your discounts and reservations then move, tag every resource at deployment with its application and cost centre, and give one named person a monthly review with authority to act.

What observability should an enterprise Azure app have?

Enough that whoever is paged overnight learns three things fast: that something is wrong, which dependency is wrong, and whether users are affected. In practice that means telemetry carrying one correlation identifier the whole way through a request, tracing at dependency level so a slow downstream call is told apart from slow code, structured logs whose retention period somebody chose on purpose, and alerting on symptoms a user would notice, such as failed sign-ins or a rising queue, rather than on resource metrics alone. A processor-utilization alert says a machine is busy. A failed-sign-in alert says a person cannot work.

Why is identity the first architectural decision?

Because data access and the integrations authorize against the application’s identity, and hosting has to support it, retrofitting identity late means rework in a build already underway. Two questions sit inside the word identity. How people sign in, which in a Microsoft estate is Entra ID, leaving the real work of deciding whether authorization lives in directory groups, in application roles, or in a business-owned table, and naming who administers that. And how the application authenticates to everything else, where the documented mechanism is managed identities, which eliminate the need to manage credentials by hand, the practice Microsoft names as a known source of security issues and outages.

Should a custom Azure application store its data in Dataverse?

That depends on whether the application owns that data or borrows it. Dataverse is a strong system of record for Power Platform solutions and for data the business already governs there, and reading from it across a defined service boundary is a sound design. Treating it as the transactional database of a custom application is different: the application has taken a dependency whose limits and licensing another team owns, and chose neither. The general rule is to own what you are accountable for in a store you control, read what belongs elsewhere through an interface, and copy nothing you only display.

When should this be a Power Platform build instead of custom Azure code?

When none of the custom triggers apply. Those triggers are a complex or high-volume transactional model, a user population whose licensing arithmetic breaks under per-user platform costs, an interface no connector reaches, performance behaviour that has to be tuned rather than accepted, and a lifecycle that must sit inside the same release process as the rest of the estate. Where none apply, a low-code solution is the shorter road to production and the cheaper one to change. Where any one of them applies, that trigger is what makes the case for custom code. Between the two, a low-code front end over custom Azure services is a hybrid architecture with its own boundary rules.

Related Reading

• Enterprise Cloud-Native Application Platforms Across Microsoft Environments, the portfolio-level view when the question spans an application estate rather than one build
• Modernize Legacy Systems without Disrupting the Enterprise, how a modernization program is sequenced once the architecture decisions are made
• Event-Driven Integration on Azure for Regulated Enterprises, the pattern detail behind an asynchronous dependency boundary

About the Author

Michael Branson co-founded i3solutions and brings executive, operational, and technical perspective to organizations running complex, secure, and mission-critical Microsoft estates. He works with enterprise teams on the governance models that keep platform investments auditable and alive.