Architecture Field Notes · Platform strategy
The Problem Is Rarely the Technology: Restoring Purpose to Enterprise Platforms
A strategic platform becomes an architecture problem when expanding the platform replaces clarity about the outcomes, capabilities and boundaries it was meant to support.
Pattern note: This is a hypothetical architecture scenario. It describes a recurring enterprise pattern, not a particular organisation, assessment or implementation.
Purpose before platform
The problem is rarely the technology itself. Problems often emerge because an organisation has never established—or has gradually lost—clarity about what a strategic platform is intended to do.
A platform selected to modernise core enterprise services can slowly become the assumed destination for unrelated capabilities. Consolidation then becomes an objective in its own right rather than one possible means of achieving organisational outcomes.
A strategic platform needs a clear purpose. Its strategic status does not make it the strategy.
How platform purpose is lost
ERP overreach is rarely caused by one dramatic decision. It develops through a series of individually plausible choices:
- the organisation already owns the platform;
- the platform can technically support another workflow;
- reducing application count appears inherently desirable;
- integration is treated as complexity while customisation is not;
- standardisation is pursued without distinguishing commodity and specialist capabilities.
The result can be a monolithic mindset: if consolidating some capabilities reduces complexity, consolidating every capability must reduce it further. That conclusion does not necessarily follow.
Platform boundaries are architecture decisions
A strategic platform requires an explicit statement of purpose, capability ownership and responsibility boundaries. Those boundaries should explain:
- which business capabilities the platform owns;
- which information it is authoritative for;
- which controls and workflows should be standardised;
- where specialist capability is justified;
- how identity, integration, data and lifecycle responsibilities are governed.
Without this clarity, platform decisions tend to be made feature by feature. Local feasibility replaces enterprise reasoning.
A single source does not require a single system
Trusted information requires clear authority, reliable integration and accountable governance. It does not require every process and data object to live in one application.
Different systems may legitimately be authoritative for different attributes, lifecycle stages or specialist records. The architecture task is to make authority and movement explicit—not to force all information into one platform for the appearance of simplicity.
A hypothetical research-intensive organisation
Consider a research-intensive organisation that has adopted a major cloud ERP/HCM platform through an enterprise-services transformation. The strategic ERP provides core people, finance and purchasing services. The wider intent is to simplify administration, improve access to trusted information and reduce the administrative burden on specialist staff so they can concentrate on their primary work.
That purpose supports substantial consolidation. Standardising institutional capabilities such as workforce administration, accounting, purchasing controls, organisational structures and common approvals can remove avoidable variation.
But a research institution may also require specialist capabilities for grant development, ethics workflows, research information, laboratory activity, scientific data, publications, collaborations or research milestones. Whether these belong in the ERP cannot be answered by platform availability alone.
“Can the ERP do it?” is the wrong first question
Major enterprise platforms are broad. Many requirements can be implemented in them. Technical feasibility is therefore a weak boundary test.
More useful questions are:
- What organisational outcome are we trying to achieve?
- What capability is required?
- Is that capability naturally owned by the strategic ERP?
- Would placing it there simplify the complete operating environment?
- Would a specialist platform provide materially stronger domain support?
- Does the user need to interact with the underlying system of record?
- Which platform should be authoritative for each information object?
- What new integration, security, data and lifecycle complexity would each option introduce?
Seek the minimum necessary complexity
Architecture should seek the minimum necessary complexity required to achieve the desired outcomes—not the minimum possible number of applications.
A lower application count may still produce greater total complexity if it requires extensive extension, awkward workflows, duplicated controls, manual workarounds or specialist processes forced into unsuitable structures.
Conversely, adding a specialist platform is not automatically justified. It must earn its place by providing sufficient capability or outcome value to justify the platform, integration, identity, security, data, support and lifecycle obligations it creates.
Composable, but governed
The alternative to ERP maximalism is not uncontrolled “best of breed”. An unmanaged collection of specialist products can be as difficult to operate as an overextended ERP.
A governed composable model assigns clear roles:
- Strategic enterprise platforms own appropriate commodity capabilities and institutional controls.
- Purpose-built domain platforms own specialist capabilities where domain complexity justifies the additional footprint.
- Experience and orchestration provide coherent services without requiring users to understand every underlying system.
- Integration and identity architecture maintain controlled boundaries and lifecycle behaviour.
- Data governance establishes authority and consistent views without requiring all data to reside together.
Rationalisation should be outcome-led
Application retirement is a consequence of better capability and platform decisions, not an outcome in itself.
A wider mandate to simplify the application estate is valuable when it removes duplication, unsupported technology, unnecessary hand-offs or avoidable operational cost. It becomes counterproductive when application count is used as a proxy for architecture quality.
The defensible position is neither “put everything in the ERP” nor “choose a specialist product for every need”. It is to consolidate where consolidation reduces unnecessary complexity while preserving the capabilities required to achieve organisational outcomes.
Architecture guardrails for strategic platforms
Useful governance makes each proposed platform extension answer a consistent set of questions:
- How does the capability support the platform’s stated purpose?
- Who owns the capability and its information?
- What alternatives were considered?
- What complexity is removed, retained or introduced?
- What customisation and upgrade consequences arise?
- How will the decision affect users, controls and operating responsibilities?
- What evidence would cause the boundary decision to be revisited?
Final thought
Consolidation can be valuable. It can strengthen standardisation, controls and information consistency while removing unnecessary technology.
It becomes harmful when consolidation itself becomes the objective.
Platform strategy should begin with purpose, capability and outcomes. The platform follows from those decisions—not the other way around.