The Hands-On Architect

Enterprise technology carries a persistent myth: architecture and delivery are separate disciplines. You design at one level of abstraction, build at another, and hand off between different people at the right moment.

That myth has killed more Power Platform and M365 projects than any other single factor.

Where the complexity actually lives

When an architect hands a design to a developer, a document transfers. The reasoning behind it doesn’t. Why this table shape and not that one. Why the environment boundary got drawn here. Why this one approval flow is synchronous when everything around it is async. Why the sensitivity label sits at this level instead of one lower.

A document records conclusions. It can’t record the judgment that produced them.

And enterprise low-code work is dense with judgment. Power Platform sits where data modelling, process design, identity, security, and user experience all meet. A model-driven app on Dataverse forces schema-level decisions that cascade into everything downstream: form layouts, relationship behaviours, security role granularity, integration patterns. A developer who wasn’t in the room for those schema decisions will make different micro-decisions all through the build. A column added here. A relationship worked around there. A simpler form layout because the intended one fights the data. Each choice is locally reasonable. Together they drift the delivered system away from the intended architecture.

By the time the drift is visible, you’re in UAT, and rolling back means a structural rebuild. Organisations absorb the cost, blame the platform, and conclude Power Platform doesn’t scale.

The handoff is the failure

I’ve watched this play out at organisations of every size. The tell is always the same: a coherent design artefact, and a delivered system that’s subtly but pervasively different from it. Not wrong in one dramatic way. Different in a hundred small ways that compound.

The developer wasn’t negligent; they built what they understood from what they were given. The architect wasn’t negligent either; the design was sound and thoroughly documented. The failure is structural. The knowledge needed to build the system correctly was never fully transferable in the time and format available.

You can’t document your way out of this. The more complex the solution, the more judgment it requires, and judgment resists documentation. A thirty-page technical spec for a complex model-driven app still leaves hundreds of implicit decisions on the table, because the architect made them fluidly and never registered them as decisions at all.

What the hands-on operating model looks like

The fix isn’t eliminating architects, and it isn’t promoting developers into architecture roles. It’s one senior person holding both responsibilities across the engagement.

That’s the model I work in. I design the solution (environment strategy, data model, security architecture, ALM approach, integration patterns) and I build it. Not supervising a developer in parallel. Directly. The Power Fx formula I’m writing is constrained by the architecture I set ten minutes earlier. When a constraint turns out wrong, I adjust the architecture. When the build surfaces a consequence I hadn’t anticipated, it feeds the next design decision. The loop is tight because it runs inside one person’s working context.

When a team is involved, I set the delivery discipline and own the architectural decisions. Developers extend the solution within patterns I’ve established, documented with the precision that only comes from having built inside those patterns myself. A design-only architect can’t produce that kind of documentation, because they’ve never collided with the parts of the design that don’t survive contact with the platform.

Where this matters most

Not every engagement needs this. Simple automations, straightforward SharePoint sites, basic model-driven apps with standard requirements: a competent developer can build these from a spec. Handoff cost is manageable when complexity is low.

It stops being manageable when the work genuinely demands senior judgment at every layer at once. Picture a data model that has to support regulatory reporting, plus business-user editing, plus integration with an external system, plus a role-based visibility model that doesn’t map cleanly onto Dataverse security roles. On those engagements, the architect who doesn’t build will produce a design the developer who builds can’t fully realise.

Those also happen to be the engagements with the highest stakes and the highest failure rates. That’s not a coincidence.

The practical implication

If you’re evaluating a Microsoft cloud engagement and the proposed model is an architect producing designs for a separate developer team to build, ask one specific question: what’s the mechanism by which architectural judgment, not documented conclusions but the judgment itself, transfers across that handoff?

If the answer is “the specification” or “weekly architecture review calls,” the risk is real. The spec captures what was decided. The calls will catch some drift. Neither catches the cumulative weight of small decisions made without full architectural context.

The alternative: make sure the person who answers for the architecture is the person whose hands are in the build. For mid-to-large Microsoft cloud work, that’s not a premium. That’s the baseline for delivery that holds together.