Technology vendors are supposed to advocate for their products. Their demonstrations naturally frame the business problem around capabilities the platform can solve. The risk begins when the organisation adopts that framing as its architecture.
Vendor-led architecture happens when product boundaries, data models, workflow assumptions and commercial incentives become the default design of the business without an independent decision about what the business actually needs.
Buy products to serve the architecture. Do not let the purchasing process invent the architecture for you.
Start with capabilities, not features
Before evaluating platforms, describe the capabilities the organisation needs: customer identity, work routing, financial control, case management, reporting, automation, integration, document handling, access control or whatever the operating model actually requires.
This creates a stable comparison surface. A vendor may deliver several capabilities well, but the organisation can still see where the product ends and where another component, integration or operating control is necessary.
Make data ownership explicit
A suite becomes difficult to leave when nobody can distinguish the business's data model from the vendor's data model. Define which information is authoritative, how it can be exported, which identifiers need to survive a platform change and what other systems depend on it.
That is why system-of-record decisions should be architectural decisions rather than accidental consequences of whichever application was implemented first.
Test interoperability before commitment
Open standards exist partly to improve interoperability and reduce dependence on a specific supplier or technology. GOV.UK's Open Standards Principles explicitly identify avoiding vendor lock-in, improving interoperability and supporting data sharing as benefits of standards-based design.
A commercial business does not need to adopt government technology policy wholesale to use the principle. Ask whether the platform supports documented APIs, standard data formats, practical export, stable authentication methods, event mechanisms and integration patterns that do not require proprietary workarounds for every connection.
Price the exit, not only the entry
Software acquisition usually focuses on licence cost, implementation and immediate return. Architecture should also consider the cost of change. How difficult would it be to move data, replace integrations, retrain users, reproduce workflow logic and preserve reporting if the vendor changed pricing, product direction or service quality?
Exit cost does not mean every platform should be easy to replace overnight. Deeply embedded systems naturally create switching costs. The objective is to understand those costs deliberately instead of discovering them during a crisis.
Separate useful consolidation from dependency
There are legitimate advantages to buying multiple capabilities from one vendor: simpler identity, fewer integrations, common administration and potentially lower operating complexity. Avoiding vendor-led architecture does not mean assembling the maximum number of suppliers.
The question is whether consolidation is an intentional architecture choice. If one suite genuinely serves the operating model better, use it. Preserve clear data ownership, interface boundaries and exit knowledge so the decision remains reversible enough for the business's risk tolerance.
A practical buying discipline
- Define business capabilities and workflows before the shortlist.
- Identify authoritative data and required portability.
- Map integrations and dependencies before implementation.
- Evaluate APIs, standards and export capability alongside user features.
- Model lifecycle and exit cost, not only licence price.
- Record where the organisation is accepting deliberate vendor dependency.
- Keep architecture documentation independent of vendor sales material.
- Review whether the platform still earns its architectural position over time.
What better looks like
A strong technology architecture can use proprietary platforms without being intellectually owned by them. The business understands its capabilities, its data, its dependencies and its reasons for choosing each platform. Vendors remain important partners, but the organisation retains the ability to reason about its operating system independently.