M365 Solution Architect: What the Role Actually Covers

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 is measured in Visio files per sprint. The role should be fundamentally different. M365 is broad, deeply interconnected, and changes constantly. Designing for it is not a discrete activity that ends when the HLD is signed off. It is an ongoing discipline that spans 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. Nobody reads it again.

Worse, the HLD is often the only design artefact produced. Engineers are left to interpret the architect's intent 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 are an output of the thinking, not the thinking itself.

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 should be shaping the questions, not answering whatever lands 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 positions the SA as advisory rather than accountable.

None of these are wrong, exactly. They are all part of the job. But they describe a consultant who produces artefacts, not an architect who 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 is not an IT operations task. It requires architectural thinking: understanding the trade-offs, anticipating the edge cases, and designing standards that are rigorous enough to be meaningful but flexible enough to survive contact with reality. 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. But 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

The SA is not the SOC. They are not triaging alerts or investigating incidents. But they are 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. Not individual policies, but the overall design. How many policy sets? How do they interact? Where are the exclusions, and are they 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. Getting them wrong early creates technical debt that is extraordinarily expensive to unwind.

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 not IT decisions; they 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. The account manager sells the most expensive option. The architect understands which features are genuinely needed versus 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 an architect with missing knowledge. The organisations that avoid the HLD-to-LLD drift are the ones where the architect can produce both levels of design, demonstrating the depth of understanding needed to bridge 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.

Designs do not survive contact with implementation unchanged. Requirements were misunderstood. Technical constraints emerge that were not apparent during design. 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 should be involved throughout delivery, not as a full-time implementer, but as the architectural conscience of the project:

Design authority reviews. Regular checkpoints where implementation progress is assessed against the design. Not "are we building what was specified?" but "is what was specified 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. This requires judgement that comes from experience, not from reading the documentation.

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 surface that is easily underestimated. 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:

• Maintain design documentation as a living artefact, not a one-time deliverable
• 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 accumulate without being rationalised. Conditional Access policies are added to address new requirements but never consolidated. New workloads are adopted without assessing their impact on existing architecture. The SA provides the continuity that prevents this drift.

---

The Anti-Patterns

Having described what the role should look like, 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.

The fix: Architects must 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. Features are enabled that nobody uses. Security controls block legitimate workflows and get circumvented via shadow IT. The architecture is technically compliant but operationally hostile.

The fix: Architecture is about 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 does good work during the design phase and then vanishes. 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.

The fix: Architects must be present through delivery. Not full-time, but at 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

This SA works in isolation, producing designs without involving the people who will implement, operate, or use the solution. They do not facilitate workshops; they conduct interviews. They do not co-create; they present.

The fix: Architecture is a collaborative discipline. The best designs emerge from structured dialogue between the architect, the implementation team, the operations team, and the business stakeholders. The SA's role is to facilitate that dialogue and synthesise the output into a coherent design, not to disappear into a room and emerge with the answer.

---

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 it is generated from the backlog, not the other way around. 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 to be made, not a task to be completed. "Define authentication method hierarchy" was an item. "Enable FIDO2 in Entra ID" was not.

Establish a Design Authority

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

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 not the quality of their designs. It is the capability they build in the teams around them:

• Teaching, not telling. When you make a design decision, explain the reasoning. When you review a proposed change, explain why it does or does not align with the architecture. Over time, the team internalises the principles and makes fewer decisions that need correction.
• Creating frameworks, not answers. Instead of answering every "should we use X?" question individually, create decision frameworks that the team can apply independently. The E3 vs E5 decision framework is an example: it does not give you the answer, but it gives you a structured way to find it.
• Building guardrails, not gates. The goal is not to be a bottleneck. It is to create standards, pipelines, and governance mechanisms that guide decisions in the right direction. 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.