Service

Solution architecture and assurance

The right platform decision, with the year-three consequences visible in year one, and an independent read before the decision becomes irreversible.

Solution and platform architecture

Twenty-five years on the Microsoft platform are what this rests on.

Dataverse works well as a data layer up to a point, and knowing where that point is saves a lot of money. Finance and Operations and Customer Engagement are separate platforms with different data models and different ways of being extended, and used deliberately together they complement each other; the trouble starts when the boundary between them is drawn by accident rather than by process and data ownership. Choosing between model-driven and canvas apps is a process question, not a matter of taste. Power Pages belongs where the users sit outside the organisation.

Then there are the questions a sales meeting is simply not the venue for: licensing, ALM, environment strategy and how much customisation has accumulated. That last one decides whether an upgrade is routine or something the team dreads.

Adding a second platform to an estate is a process decision before it is a licensing one. Which domain owns which master data, where process authority sits at each boundary crossing, and what purpose Dataverse serves in your architecture.

This work serves no vendor. Where another platform, a custom build, or doing nothing is the better answer, I say so and show the reasoning. When the answer is Microsoft, it is a specific and well-founded answer, not a default.

Vendor and ISV dependency

Your roadmap has a co-author. An industry solution from an ISV buys you a lot: domain depth you would otherwise build yourself, a shared upgrade path, and a vendor with a stake in your sector. It also creates a chain: Microsoft, then the ISV, then your own extensions. The chain moves at the speed of its slowest link. That is a fair trade, but it is a trade, and most organisations price only the first half of it.

I have sat on the vendor side of this relationship, responsible for a roadmap several customers were waiting on. The pattern from that seat was consistent. The customers who got the most out of it arrived with a clear process description and could say which parts of it genuinely set them apart. They were not asking for everything. They were asking for the right things, in a form the vendor could act on.

This section is written from the buyer's chair. If you sit on the other side of the table the same things apply in reverse: the same process segmentation, the same clarity about what differentiates, the same traceability from capability to roadmap. I work with both, though never with both on the same matter.

Review, procurement and tender support

Organisations commit to designs that only the people proposing them have reviewed. That happens often enough that I treat the independent read as one of the most valuable things an outside architect does: checking a proposed architecture against the stated business requirements, finding where the risk actually sits, and putting it in terms a steering committee can act on.

For public bodies the work usually starts earlier, in the procurement itself. A requirement specification written around the current system, or in one vendor's vocabulary, decides the outcome in advance and gets blamed for it later. I work with you to write specifications that describe business capability and outcome, define the architectural constraints that actually matter, and set evaluation criteria that can tell proposals apart on substance.

What you get

• Solution architecture traceable back to capability and process, not assembled from feature lists
• Build, buy, configure and extend analysis with total cost of ownership over a realistic horizon
• Platform fit assessment, with licensing implications and scaling constraints
• A map of who you depend on: Microsoft, the ISV, your own extensions, and how fast each one moves
• Architecture review with findings prioritised by risk and clear remediation options
• Requirement specifications for tender that describe what the organisation must be able to do, not what it already runs

Scope

Get in touch when

• A platform decision is imminent and the analysis so far has come from the bidders
• A Dynamics 365 or Power Platform implementation is not delivering what was promised
• Customisation has accumulated to the point where upgrades are feared
• You depend on an ISV solution and cannot see far enough into its roadmap to plan
• A major procurement is being prepared and you want it to be genuinely competitive
• A programme is slipping and the technical explanations have stopped being convincing

Related

A solution architecture should trace back to capabilities and processes. Without that, you are just choosing product features, which is what Enterprise architecture and process is there to prevent.

Platform boundaries follow process authority and master data ownership rather than licensing or technology. The data half of that decision belongs in Data and information architecture.

Does this sound familiar?

Tell us briefly where you are. The first conversation costs nothing and usually leaves the question clearer than it was, whether or not this results in a project.