Enterprise identity architecture
Entra ID as the organisational control plane, extended to workload identity, conditional access and lifecycle automation rather than used only for sign-in.
Microsoft platform consulting and architecture
Most organisations run more of the Microsoft platform than they have designed. Identity, productivity, business applications and data services arrive separately and end up load-bearing without anyone having decided how they fit together.
Overview
The Microsoft platform is unusual in that most enterprises adopt it incrementally and rarely as an architectural decision. Identity arrives with email, business applications arrive with a department, and the low-code platform arrives because someone needed a form.
Each step is reasonable. The cumulative result is an estate where identity is the control plane for everything, where business-critical processes run on tooling that was never reviewed, and where the boundary between a productivity tool and an application is unclear.
Our work here is usually about making that estate deliberate: designing the identity model properly, deciding what belongs in low-code versus custom development, and being explicit about which capability the organisation depends on. We hold no Microsoft partnership and resell no licences.
Enterprise use cases
Where we see this used to good effect, and what makes each case a fit.
Microsoft 365 as an application platform
Where business processes have grown into the productivity estate and need governance, because they are now load-bearing.
Dynamics as a business system
Assessed the same way as any other packaged platform: fit, total cost and the upgrade consequence of every customisation.
Power Platform governance
Low-code delivery that is genuinely productive, with a boundary defining when something has outgrown it.
SQL Server estates
Long-lived data platforms, their modernisation path, and the licensing consequences of where they run.
Hybrid directory and device estates
Organisations retaining on-premises Active Directory and device management alongside cloud identity, deliberately rather than temporarily.
Architecture
Identity is the architecture. In a Microsoft estate, Entra ID is the control plane for productivity, business applications, cloud infrastructure and increasingly third-party services, which makes tenant design, conditional access and privileged access the decisions with the widest reach.
The second decision is where the boundary sits between the productivity platform and applications. Business processes migrate into the productivity estate because it is the path of least resistance, and they become load-bearing without ever having been designed, reviewed or given an owner.
- Tenant, directory and conditional access designed rather than accumulated
- A stated boundary between productivity tooling and applications
- Privileged access separated from daily-use accounts
- Hybrid directory position chosen deliberately, not left as a migration remnant
Best practices
The practice that pays back most is treating identity lifecycle as automation rather than as a request queue. Joiners, movers and leavers handled manually mean entitlements accumulate, and effective access diverges from intended access continuously.
The second is inventorying what the organisation actually depends on inside the productivity estate. A spreadsheet or low-code application that a process cannot run without is a production system, and it should be named as one whatever it was built in.
- Joiner, mover and leaver automated, so entitlements are removed as well as granted
- Business-critical low-code and spreadsheet assets inventoried and owned
- Conditional access policies documented and tested, not merely enabled
- Licensing reviewed against actual use rather than assumed from headcount
Security
Compromise of a Microsoft estate is usually compromise of identity, which makes privileged access, legacy authentication protocols and consented third-party applications the areas that repay attention first.
Third-party application consent is the one most often overlooked. Users can grant applications access to organisational data, and an estate without a consent policy accumulates integrations nobody reviewed and nobody can enumerate.
- Privileged access time-bound and separated from daily-use identities
- Legacy authentication protocols disabled rather than merely discouraged
- Third-party application consent governed, with existing grants reviewed
- Data classification applied where sensitivity varies, not uniformly
Scalability
Scale in a Microsoft estate is more often organisational than technical. The platforms handle large user populations well; what does not scale is manual identity administration, ungoverned low-code sprawl and environments created without lifecycle.
Where technical limits do bind, they are usually service-specific throttling and API limits on the productivity platform, which surface as intermittent failure in integrations rather than as an obvious ceiling.
- Identity administration automated, because manual process is the real ceiling
- Low-code environments given lifecycle rather than created indefinitely
- Service throttling and API limits understood before integrations depend on them
- Licence position modelled against growth rather than discovered at renewal
Performance
Performance questions in this estate are usually about integration rather than about the platforms themselves. Applications that call productivity APIs synchronously in a user-facing path inherit that service's latency and throttling behaviour.
For SQL Server estates, the pattern is more conventional: query and index design, then hardware or service tier. Reversing that order is a common and expensive way to buy a temporary improvement.
- Productivity API calls kept out of synchronous user-facing paths
- Throttling handled with backoff and queueing rather than retried immediately
- SQL Server tuned by query and index design before tier or hardware
- Data locality checked where tenant and workload regions differ
Integration
The Microsoft estate integrates with itself readily, which is its principal advantage and the reason coupling accumulates without being decided. An application that reaches into the productivity platform for convenience acquires a dependency on a service with its own release cadence and limits.
For integration beyond the estate, the choice is between the platform's own integration services and general-purpose messaging. Both are viable; the difference is portability and where the operational burden sits.
- Coupling to productivity services treated as a decision with a switching cost
- Integration platform choice weighed on portability and operational burden
- Identity federation to third parties governed rather than granted per request
- Interface contracts specified even where both ends are Microsoft services
Operations
Operating this estate is dominated by change you do not control. Microsoft ships changes continuously, deprecates features on its own schedule and alters defaults, and an organisation without an owner for those notices is repeatedly surprised.
The second is licence and cost management, which behaves differently from infrastructure cost — it is committed, tied to headcount and reviewed annually, so an accurate view of actual use is worth having before the renewal conversation rather than during it.
- Change and deprecation notices given a named owner and a tracked backlog
- Licence use measured against entitlement well before renewal
- Tenant configuration held in version control where the platform allows it
- Recovery and retention for productivity data designed, not assumed included
Governance
Governance here is mostly about the low-code and productivity estate, because that is where ungoverned growth happens fastest. Prohibiting it does not work — people build what they need — so the workable approach is a supported path with a defined boundary.
That boundary should state when something has outgrown low-code and needs to become a supported application. Without it, an organisation discovers the answer when a critical process breaks and its author has left.
- A supported low-code path with environments, lifecycle and named owners
- A stated threshold at which an asset must become a supported application
- Data loss prevention policies applied to connectors rather than left default
- Critical low-code assets inventoried with an owner and a recovery position
Recommended industries
Sectors where this comes up most often, and the constraint that puts it there.
Industry
Education
Student information systems, hybrid delivery platforms and sharply seasonal load.
IndustryGovernment & Public Sector
Procurement constraints, data residency, accessibility obligations and long-lived legacy estates.
IndustryHealthcare
Interoperability between clinical systems, patient data privacy, and legacy platforms that cannot be taken offline.
IndustryBanking & Financial Services
Core system modernisation, real-time payment flows, and architecture that can evidence regulatory controls.
IndustryManufacturing
Operational technology meeting information technology, supply chain visibility, and ERP estates grown by accretion.
IndustryEnergy & Utilities
Grid and asset telemetry, regulatory reporting, and operational systems that cannot tolerate an outage window.
Related services
The engagements this work is usually delivered within.
Enterprise Architecture
Target-state design, modernisation roadmaps, integration and cloud architecture, and the governance that keeps decisions consistent after the consultants leave.
Cybersecurity
Security architecture, assessment and compliance advisory, designed in rather than reviewed afterwards.
ERP & Business Applications
ERP implementation advisory, integration into the wider estate, and business process automation.
Cloud Consulting
Migration strategy, landing-zone design, cost modelling and the architecture decisions that determine whether cloud spend buys capability.
Managed IT Services
Application support, infrastructure management and incident response under defined service levels.
Software Development
Custom application, web, mobile and API development, and modernisation of systems that are constraining the business.
Frequently asked questions
No. We hold no Microsoft partnership, resell nothing and take no commission. That means recommending you buy fewer licences, or use a competing product, costs us nothing — which is the only condition under which such advice is worth anything.
With identity, because in this estate identity is the architecture. Entra ID is the control plane for productivity, business applications, cloud infrastructure and increasingly third-party services, so it is the decision with the widest reach and the most consequential if it is wrong.
It is a problem when nobody has said so out loud. An asset a process cannot run without is a production system whatever it was built in, and it needs an owner, a recovery position and a place in the inventory. Prohibiting the practice does not work; naming what has become critical does.
When it has users beyond its author's team, when its failure interrupts a business process, or when its logic has grown past what one person can hold in their head. Defining that threshold in advance is considerably cheaper than discovering it when the author leaves.
Assessed the same way as any other packaged platform: fit against your differentiating processes, total cost over its life, and the upgrade consequence of every customisation. Being already in the Microsoft estate is an argument, but it is not the whole argument.
Third-party application consent. Users can grant applications access to organisational data, and an estate without a consent policy accumulates integrations nobody reviewed and nobody can enumerate. Legacy authentication protocols left enabled is a close second.
Frequently yes, and for years. What matters is that it is a deliberate position rather than a migration remnant nobody finished. A hybrid directory chosen knowingly is well supported; one that exists because a project stalled tends to carry the disadvantages of both models.
By automating the identity lifecycle rather than handling it as requests. Manual joiner, mover and leaver processes grant reliably and remove unreliably, so effective access diverges from intended access continuously and nobody can state by how much.
By giving change and deprecation notices a named owner and a tracked backlog. They arrive on Microsoft's schedule rather than yours, and the organisations that are repeatedly surprised are the ones where nobody is accountable for reading them.
Worth checking rather than assuming. Retention within the platform is not the same as backup, and the differences matter most in exactly the scenarios you would want a backup for. It is a common gap and a cheap one to close once identified.
We can assess use against entitlement and identify where you are paying for capability nobody uses, which is common. We do not sell licences and have no interest in the outcome, but we would also point out that a licensing reseller will model the commercial detail more thoroughly than we will.
Next step
Discuss a Microsoft platform estate
A free first consultation covering your identity position, what your organisation actually depends on inside the productivity estate, and whether it is designed or accumulated.
No cost, no obligation. Pricing is transparent and includes GST.