There is no single design pattern that produces a good Power Platform solution. Every organisation is different, every programme has its own constraints, and anyone selling you a one-size template is selling you a future rebuild. What does hold true across all of them is a set of principles — applied consistently — that separate an architecture which survives production from one that quietly falls apart six months after go-live.

I set these out as nine pillars in the opening chapter of my book. They are not a checklist you complete once; they are nine lenses you keep looking through, on every decision, for the life of the programme.

The nine pillars

• Security. Data is the asset you are really being trusted with. Authentication strategy, network exposure, secrets and certificates, perimeter controls — these are designed in from the first diagram, not bolted on before go-live.
• Makers. Power Platform's strength is that people beyond the core team can extend it. A good architecture acknowledges that and puts guardrails around it, so makers add productivity instead of risk.
• Compliance. Privacy and regulatory requirements vary by industry, geography and data type. Data retention, access channels and certifications belong in the design, not in a panic near launch.
• Maintainability. Configure first, customise second, write custom code last — and only when the supported options are genuinely exhausted. The solution has to be supportable by the people who inherit it.
• Availability. Uptime and recoverability are requirements like any other. That means understanding each component's resilience features and designing integrations with retry strategies and fallbacks that survive transient faults.
• Performance and scalability. Capacity planning for Dataverse, integration response times, automation throughput, portal experience — and headroom to grow. Performance is designed, not discovered in load testing.
• Monitoring and operation efficiency. You cannot operate what you cannot see. A monitoring architecture lets you catch faults before users do, and gives operators the visibility to keep the system healthy.
• Cloud enablement. Letting Microsoft carry the platform underneath you is the point — it frees the architecture to focus on the solution rather than the plumbing. Designing as though it were on-premises throws that advantage away.
• Cost-benefit balance. Every one of the pillars above has a cost — in licensing, in build time, in operational overhead. The architect's job is to weigh each one honestly against the value it brings, and have the constructive conversation with stakeholders about where the line sits.

Why nine, and why together

The pillars are most useful precisely where they pull against each other. Tighter security can cost performance. Empowering makers can complicate maintainability. Higher availability costs money. The work of solution architecture is not maximising every pillar — it is the deliberate, documented trade-off between them, made with the organisation's priorities in view.

That is also why the last pillar — cost-benefit balance — is the one that holds the other eight in tension. It is the difference between an architecture that is technically impressive and one that is the right answer for this organisation, with this budget and these constraints.

Using the pillars as a review tool

The most practical use of the nine pillars is as a standing review. When a design decision comes up, run it past all nine: what does this choice do to security, to maintainability, to cost? If a programme is already in flight and feeling shaky, the pillars make a fast diagnostic — find the two or three that have quietly been ignored, and you have usually found the source of the trouble.

The nine pillars are the framework I open my book with — the Microsoft Power Platform Solutions Architect's Handbook (Packt, 2nd edition) — and the lens I bring to every architecture review. If you would like that lens applied to a programme of your own, that is the kind of work I do.