M365 Solution Architect: What the Role Does

The diagram factory problem

"Can you draw us an architecture?"

That is the moment I know an engagement has gone wrong. Not "Can you help us design a solution?" or "Can you figure out how we should approach this?" Just draw us an architecture. As if the value of a Microsoft 365 Solution Architect (SA) is measured in Visio files per sprint. The role should work differently. M365 is broad, deeply interconnected and constantly changing, so designing for it cannot end when the HLD is signed off: it has to run as an ongoing discipline spanning governance, standards, delivery and operational oversight.

But that is not what most organisations buy. They buy a documentation function. You get brought in, you attend workshops, you ask questions, you disappear for two weeks, and you return with a beautifully formatted High-Level Design that covers network topology, identity flows, data residency, and integration patterns. Everyone nods, the document gets filed in SharePoint, and nobody reads it again.

Worse, the HLD is often the only design artefact produced. Engineers must interpret the architect's intent themselves and create their own Low-Level Designs, filling in the gaps with assumptions. By the time the LLD reaches implementation, the original design intent has drifted.

Six months later, when the implementation looks nothing like the design, people wonder what went wrong. What went wrong is that the organisation paid for a diagram and got exactly that.

---

The four things organisations think they are paying for

When an organisation hires or contracts an M365 Solution Architect, they typically expect some combination of the following:

• High-Level Designs: architecture diagrams, component descriptions, integration maps. These are necessary, but they only capture the outcome of that thinking.
• Technical authority: someone who can answer "should we use this?" questions definitively. This is closer to the mark, but it is reactive. A good SA works out which questions matter before they land on their desk.
• Vendor translation: someone who can read Microsoft's documentation and roadmap announcements, then explain what they actually mean for the organisation. This is genuinely valuable, but it is a fraction of the role.
• Risk mitigation: a senior technical voice in the room when decisions are being made. Important, but it keeps the SA advisory, when the job needs someone accountable for the outcome.

None of these are wrong, exactly. They are all part of the job, but together they describe a consultant who produces artefacts. The architect owns outcomes.

---

What the M365 solution architect role should cover

1. Own the standards

Someone has to own the standards. Not "contribute to" or "advise on" or "review when asked." Own them. Define them, maintain them, enforce them, and update them when the platform changes.

In an M365 context, this means owning the answers to questions like:

• What does a compliant device look like? What are the baseline configuration profiles, compliance policies, and security baselines that every device must meet?
• What does a well-governed Entra ID tenant look like? Naming conventions, group lifecycle policies, app registration standards, Conditional Access architecture.
• What does a properly managed application portfolio look like? Packaging standards, deployment rings, update cadence, end-of-life policies.

Standardisation gets treated as routine IT operations work, but it takes architectural thinking: understanding the trade-offs, anticipating the edge cases, and designing standards that are rigorous enough to be meaningful but flexible enough to hold up once they meet a live tenant. I wrote in detail about why standardisation is the foundation of a modern Windows estate and why it demands architectural ownership rather than operational convenience.

If the SA is not owning standards, one of two things happens. Either nobody owns them and you get the tenant mess I described in Why Your M365 Tenant Is a Mess. Or someone in operations owns them, applies them diligently, but lacks the architectural context to evolve them as the platform changes.

2. Design the configuration pipeline

The SA role intersects with DevOps here, and most organisations have not figured out this intersection.

In Configuration as Code for Endpoint Management, I argued that treating your Intune configuration as code, versioned in Git, deployed through pipelines, is the only sustainable approach at scale. Someone has to design that pipeline: what goes in, what the review process looks like, how drift detection works, and how exceptions are handled. That is the SA's job.

The SA does not need to write every line of DSC or build every pipeline from scratch; they own the architecture of the configuration management system:

This requires understanding the platform deeply enough to know which configurations are safe to auto-remediate and which could cause an outage if applied blindly. It requires understanding the organisation well enough to design a process that people will actually follow.

3. Own the security architecture

Triaging alerts and investigating incidents is the SOC's job, not the SA's. The SA is responsible for designing the security posture of the M365 estate, and that goes well beyond "enable MFA."

In practice, this means owning:

• The Conditional Access architecture: the overall design behind individual policies. How many policy sets does the estate need, how do they interact, and are the exclusions justified? I wrote about the practical patterns in Conditional Access Policies That Actually Work. Someone has to maintain the architectural coherence of those policies as new requirements emerge, especially as capabilities like Global Secure Access change the network perimeter.
• The security baseline strategy: Microsoft's baselines, CIS benchmarks, or custom profiles? The answer is rarely "just one of those." It is usually a considered blend, and the decision framework matters. The SA defines the strategy; the operations team implements and monitors it.
• Identity architecture: Entra ID is the control plane for everything in M365. Authentication methods, device trust models, application consent frameworks, B2B access policies, privileged identity management. Each of these is an architectural decision with security implications that compound over time. Getting authentication methods wrong, for example, means retrofitting FIDO2 security keys or device-bound passkeys across an estate that has already embedded SMS-based MFA into its user culture.
• Data protection posture: Microsoft Purview sensitivity labels, DLP policies, retention policies, and (for regulated environments with M365 E5 or the E5 Compliance add-on) Information Barriers. These are business decisions with technical implementations. The SA bridges that gap, translating regulatory and business requirements into platform configuration.

4. Shape licensing strategy

This might seem like an odd responsibility for a technical role, but licensing in M365 is an architectural decision. The licence tier determines what features are available, which in turn constrains what you can design.

Should you go E3 with targeted add-ons or E5 across the board? I explored this in E3 vs E5: The Decision Framework, and the M365 Licensing Audit post covers how to assess what you are actually using. The decision has architectural consequences that ripple through everything else. Your security posture, your compliance capabilities, your automation options, and your cost structure all depend on this choice.

The SA maps business requirements to licence capabilities and identifies the most cost-effective path to the desired outcome. Procurement negotiates price and the account manager sells the most expensive option, but only the architect understands which features are genuinely needed and which are nice-to-have.

5. Stay through delivery

Many organisations treat the SA as a pre-sales or design function: they do their work before implementation starts, hand over the HLD, and move on to the next project. This is a mistake.

An architect who cannot produce an LLD is missing part of the job's knowledge. The organisations that avoid the HLD-to-LLD drift are the ones where the architect can produce both levels of design. That depth of understanding is what bridges strategy and implementation. That does not mean they must produce every LLD themselves. The goal is to demonstrate the depth once, then guide engineers through the process: show them how to translate high-level intent into implementation detail the first time, provide structured feedback the second and third time, and step back once the team has internalised the approach. Half of the SA role is teaching, and LLD creation is one of the clearest opportunities to transfer knowledge rather than hoard it.

Once implementation starts, designs change: the team has misunderstood some requirements, technical constraints emerge that were not apparent during design, and the project team makes pragmatic compromises that individually seem reasonable but collectively erode the design intent. Without the SA present during delivery, there is nobody with the authority and context to say "that compromise breaks the architecture."

The SA stays involved throughout delivery as the architectural conscience of the project, without becoming a full-time implementer:

• Design authority reviews: regular checkpoints where implementation progress is checked against the design. The question is not whether the team is building what was specified, but whether that specification is still the right thing to build.
• Trade-off decisions: when the team hits a constraint (timeline, budget, technical limitation), the SA decides how to adapt the design without compromising the core principles. That judgement comes from experience; no document can substitute for it.
• Integration assurance: M365 is a platform of interconnected services, and the integration points are where things go wrong. Workloads like Azure Virtual Desktop introduce integration points that are easy to underestimate. Exchange Online and Entra ID interact in ways that are not obvious. Intune policies and Conditional Access policies can create circular dependencies. M365 group-connected SharePoint sites derive their default membership from the associated group, so changes to group ownership silently propagate to site permissions (though SharePoint-level permissions can exist independently of the group). The SA spots these coupling risks before they become production incidents.

6. Maintain architectural governance

The SA's concrete ongoing activities:

• Keep design documentation current as the estate changes
• Monitor the Microsoft roadmap for changes that affect the architecture
• Run a regular cadence of architectural review (monthly or quarterly)
• Ensure operational decisions remain aligned with the architectural vision

Without this, even a well-designed estate degrades. Configuration profiles pile up unrationalised, Conditional Access policies get added for new requirements but never consolidated, and teams adopt new workloads without assessing the impact on existing architecture. The SA provides the continuity that prevents this drift.

---

The anti-patterns

Here are the failure modes I see most frequently.

The ivory tower architect

This SA produces beautifully detailed designs that are technically excellent and practically impossible. They design for the ideal state without understanding the constraints of the real one. Their HLDs assume unlimited budget, a perfectly skilled implementation team, and an organisation that will follow every recommendation without question.

The result: designs that gather dust, an implementation team that ignores the architecture and builds what they can with the time and skills they have, and an SA who complains that "they didn't follow the design" without asking why.

Stay connected to delivery. If you cannot explain how your design gets implemented by the team you actually have, with the budget you actually have, in the timeline you actually have, your design is fiction.

The checkbox architect

The opposite problem. This SA treats architecture as a compliance exercise. They adopt Microsoft's reference architectures wholesale, enable every recommended feature, and apply every security baseline without evaluating whether it makes sense for their organisation.

The result: an estate that looks good on paper but does not serve the business. The checkbox architect enables features that nobody uses. Security controls block legitimate workflows and get circumvented via shadow IT. The architecture is technically compliant but operationally hostile.

Treat architecture as a set of trade-offs. Every design decision should answer: "What problem does this solve for this organisation?" If the answer is "Microsoft recommends it," that is not good enough.

The absent architect

This SA delivers strong work at the design stage and then disappears: they hand over the HLD, wish the project team luck, and move to the next engagement. By the time the implementation is complete, the delivered solution bears little resemblance to the design.

Stay present through delivery, at the key decision points. If you are not available when the trade-off decisions are being made, you have no right to complain about the outcome.

The lone wolf architect

Isolation is the pattern here: this SA produces designs without involving the people who will implement, operate, or use the solution. They run interviews instead of workshops, and present instead of co-creating.

Structured dialogue between the architect, the implementation team, the operations team, and the business stakeholders produces the best designs. The SA's role is to hold that dialogue and synthesise the output into a coherent design.

---

How to shift the role from reactive to accountable

If you are an SA reading this and recognising some of these patterns, here is how to shift the role in a more productive direction.

Own a backlog, not a document

Replace the static HLD with a living architecture backlog. This is a prioritised list of architectural decisions, standards to be defined, configurations to be implemented, and governance processes to be established. It lives in your project management tool alongside the delivery backlog, and it gets refined continuously.

The HLD still exists, but the backlog now generates it, reversing the old order. When someone asks "what's the architecture?" you point them to the current state of the backlog.

In a recent 15,000-seat deployment, the architecture backlog held roughly 40 items across identity, endpoints, and data protection. Each item was a decision waiting to be made. "Define authentication method hierarchy" was an item. "Enable FIDO2 in Entra ID" was a task, and stayed off the backlog.

Establish a design authority

Even in small organisations, architectural decisions should go through a lightweight review process. This means a regular forum (weekly or fortnightly) where proposed changes to the M365 estate are reviewed for architectural impact, not a bureaucratic change advisory board.

The SA chairs this forum. The attendees include operational leads, security, and whoever is proposing the change. The output is a decision: approved, approved with conditions, or deferred for further analysis. Decisions are logged and linked to the architecture backlog.

Automate your governance

Manual governance does not scale. If your governance process depends on someone remembering to check something, it will fail.

Use the tools available in the platform:

• Access reviews in Entra ID Governance (requires Entra ID P2) for periodic validation of group membership and application access
• Microsoft365DSC for configuration drift detection and automated remediation
• Graph API for automated reporting on tenant health metrics (I covered the specific endpoints in the tenant health post and the Graph API for Architects post)
• Entra ID Workbooks (Monitoring section in the Entra admin centre) for sign-in analytics and access review dashboards, extended by Azure Monitor and Sentinel workbooks where a Log Analytics workspace is connected, surfacing configuration drift and anomalous access patterns

The SA designs these automated governance mechanisms. The operations team runs them.

Bridge security and usability

Security teams want to lock everything down. Business teams want everything to work frictionlessly. The SA sits in the middle, designing controls that are effective without being hostile.

A Conditional Access policy that blocks all unmanaged devices is secure. It also prevents contractors, BYOD users, and anyone working from a personal device from accessing anything. The right answer is usually more nuanced: managed devices get full access, unmanaged devices get browser-only access with session controls, and truly sensitive resources require a managed device regardless.

These are the trade-offs that define the SA role. They require understanding both the security risk and the business impact, then designing a control that addresses one without creating an unacceptable burden on the other.

---

The invisible architect

The measure of a good M365 Solution Architect is the capability they build in the teams around them:

• Explain your reasoning. Say why you made a design decision, and why a proposed change does or does not fit the architecture when you review it. Over time, the team internalises the principles and makes fewer decisions that need correction.
• Build decision frameworks. Instead of answering every "should we use X?" question yourself, create a framework the team can apply on its own. The E3 vs E5 decision framework is an example: it gives you a structured way to find the answer.
• Guardrails guide decisions in the right direction without becoming a bottleneck: standards, pipelines, and governance mechanisms that channel choices rather than block them. An automated compliance policy that flags non-standard application packages before deployment is a guardrail. A mandatory review meeting for every change is a gate.

When this works, the SA role becomes invisible. The estate is well-governed, the security posture is strong, the configurations are consistent, and the team absorbs new requirements without the architecture degrading. Nobody points to the SA and says "they did that" because the systems and processes do it.

When it fails, the SA role is very visible. The HLD sits unread in SharePoint. The implementation diverges from the design. The estate drifts into the tenant drift problem. And someone asks: "What exactly does our architect do?"

The answer should be: everything that prevents you from having to ask that question.

If you want to see what standards ownership looks like in practice, start with Configuration as Code for Endpoint Management or Why Your M365 Tenant Is a Mess.