Why Platform Engineering Became a Core Enterprise Architecture Discipline
Companion to LinkedIn Post 3 — “Platform Engineering as Enterprise Architecture”
In the last post in this series, I argued that the transition state is where modernization succeeds or fails. An intermediate state has to be more than a milestone. It has to be coherent enough for the business to operate, govern, and improve without depending on heroic effort.
That raises the next question: what makes those transition states repeatable?
The answer is increasingly the platform.
Platform engineering is often described as a way to improve developer experience. That is true, but incomplete. From an Enterprise Architecture perspective, the platform is where business strategy, technology standards, governance, and delivery meet. It turns architectural intent into reusable capabilities that teams can actually consume.
That makes platform engineering more than a tooling practice. It is a core Enterprise Architecture discipline.
It is also where an architect’s own relevance is now decided. When architecture lives only in documents, delivery teams route around it. The standards that shape how systems actually get built are the ones expressed in the path a team takes to production — not the ones filed in a repository. An architect who does not shape the platform is, increasingly, not shaping delivery at all.
Autonomy works — until the enterprise needs to behave like an enterprise
Giving business units autonomy can be the right decision. The people closest to a market, customer, or product should be able to respond without central approval for every technical choice. Local autonomy can improve speed, accountability, and experimentation.
But autonomy without a shared foundation has a predictable cost.
One business unit chooses one cloud and identity pattern. Another selects a different integration platform. A regional team builds its own deployment process to meet an immediate deadline. Each decision is locally rational.
For a while, it works.
Then the organization needs those systems to behave as one enterprise.
A customer expects consistency across regions. Leadership wants a consolidated view of operations. A new product depends on data held across business units. A regulation must be implemented everywhere. A merger exposes incompatible identity, security, and integration models. The speed gained through local optimization becomes the cost of enterprise change.
I’ve watched this pattern play out more than once. Business units and regions are given broad freedom to choose the technology and operating models that suit them. For years it looks like a strength. The bill comes later: duplicated capabilities, fragmented data, inconsistent processes, and systems that are painful to integrate when the business needs a unified response.
The lesson is not that autonomy was a mistake. The lesson is that autonomy was never given an architectural boundary.
The organization optimized each part and eventually discovered that nobody had optimized the whole.
The platform is an architectural boundary for autonomy
The usual response to fragmentation is centralization: mandate a single tool, create an approval board, and require every team to conform. That can reduce variation. It can also reduce delivery to the speed of the central team.
Platform engineering offers a better boundary. It does not eliminate autonomy. It defines where autonomy creates value and where reuse creates more.
Teams should remain free to shape product behavior, customer experience, domain logic, and experiments. They should not have to independently solve identity, connectivity, deployment, observability, policy, secrets, resilience, and cost allocation every time they build something.
Those are shared enterprise capabilities. Rebuilding them inside every business unit is not autonomy. It is duplication.
A platform converts those capabilities into paved roads: supported, reusable paths teams can adopt without mastering every layer beneath them. They succeed when they are the fastest credible route from an idea to a secure, operable product.
That is the Enterprise Architecture role in platform engineering: deciding which capabilities should be shared, which decisions should remain local, and how the two evolve together as the business changes.
The key principle is not that every business unit must use the same technology. It is that independently built capabilities must participate in the enterprise through known contracts.
Those contracts define how systems establish identity, exchange data, expose APIs and events, produce telemetry, inherit security controls, and report cost. One team may build on a managed cloud service while another uses a container platform. That variation can be healthy if both can be discovered, secured, operated, and integrated through the same enterprise expectations.
Without those contracts, autonomy becomes isolation. With them, teams can choose locally without making every future enterprise initiative pay an integration tax.
Start with business value, not a platform shopping list
Many platform initiatives begin with technology. A team selects Kubernetes, a GitOps tool, an internal developer portal, an observability stack, and a policy engine. Then it calls the collection a platform.
That may be useful infrastructure. It is not yet a platform strategy.
From an EA perspective, the starting point is the business constraint the platform should remove.
- Are product teams taking too long to reach production?
- Are common controls implemented differently across business units?
- Is every new region or product launch treated as a custom integration program?
- Is duplicated tooling increasing cost faster than business capability?
- Does entering a new market require rebuilding identity, data, security, and deployment foundations?
These questions change the investment conversation. Instead of asking whether the organization needs a developer portal or another orchestration layer, the architect can ask which reusable capability would remove the most expensive source of delay, risk, or duplication.
That connection to business value matters because a platform is a product with enterprise customers. If it does not solve a problem teams recognize, adoption will depend on mandates. And a platform that requires permanent enforcement to create demand is usually solving the central team’s problem, not the user’s.
ROI comes from reuse — but only when reuse is real
The economic case is straightforward in theory: build a capability once, improve it centrally, and reuse it across products and business units. Its cost is shared while improvements benefit the estate.
In practice, reuse is often claimed too early.
A reference architecture in a repository is not reuse. Neither is a template modified beyond recognition or a central service with twelve team-specific forks. Those may accelerate the first implementation, but they do not create compounding returns.
The test for real reuse is simple, and worth stating plainly:
When the platform team improves a capability, do the teams already using it get the improvement without rebuilding anything?
If yes, reuse compounds. If every consumer must re-adopt, re-integrate, or manually retest the change, the enterprise pays for it many times instead of once.
Real reuse means consuming a maintained capability through a clear contract. Security fixes, policy changes, observability improvements, and deployment patterns can then propagate through the shared foundation.
That is where platform ROI begins to compound.
Picture two product teams funded on the same Monday. The first has no paved road. Before writing differentiating code, it must assemble an environment, identity, connectivity, deployment, observability, secrets, and security controls. The work is invisible to the customer, and every team that follows repeats it slightly differently.
The second team consumes a paved road. Those capabilities arrive through a repeatable path and already satisfy policy. It spends its first week on the product the business funded.
The gap between those Mondays is the platform’s value. It compounds when a security fix, recovery improvement, or new policy reaches every team on the same road. That is the difference between a platform and a pile of tools: whether the next team’s Monday is easier because the last team’s happened.
The return appears in several forms:
- Faster time to value. Teams spend less time assembling foundations and more time delivering business capability.
- Lower marginal delivery cost. The tenth product using a paved road should cost less to enable than the first.
- Reduced operational variation. Common telemetry, recovery patterns, and controls make the estate easier to support.
- Lower risk. Security and compliance requirements can be implemented once and inherited by many teams.
- Faster enterprise change. A new policy or capability can move through the platform instead of becoming dozens of separate transformation projects.
- Better use of scarce talent. Specialists improve shared capabilities instead of repeatedly solving the same problem inside isolated teams.
Fragmented technology also fragments talent. Every unique stack requires people who know its tools, failure modes, and history. The organization accumulates not just systems, but dependencies on small groups who can keep them alive.
A platform reduces that concentration risk by creating common operating patterns and a broader base of transferable skills.
Measure the platform by outcomes, not activity
Platform teams can publish templates, add integrations, and release features while delivery teams continue building around them. Measurement has to connect that activity to outcomes.
Useful measures include:
- Time from product approval to a safe production deployment
- Adoption and repeat usage of shared capabilities
- Percentage of controls inherited from the platform rather than implemented by each team
- Reduction in duplicated tools and unsupported patterns
- Change failure rate, recovery time, and operational support effort
- Cost per workload or product as adoption scales
- Time required to introduce a new region, policy, or enterprise capability
No single metric proves ROI. Together, they reveal whether the platform reduces the cost of change. It should not merely make today’s architecture cheaper to operate; it should make tomorrow’s business decision cheaper to implement.
Treat data and security as shared enterprise capabilities
Infrastructure standardization alone does not create an integrated enterprise. Deployment pipelines and landing zones can converge while data remains fragmented and security controls are reimplemented by every team.
Data is especially vulnerable to local optimization. Each business unit creates the customer, product, or operational model it needs. The cost appears later, when the business needs a unified customer experience, consolidated reporting, or a new product that depends on information held across several domains.
Treating data as an enterprise asset does not mean putting it all in one database or assigning ownership to a central team. Domains should remain accountable for its meaning and quality. The platform should provide the contracts that make it usable beyond its point of origin:
- Defined ownership and stewardship
- Discoverable data products and interfaces
- Shared business definitions where consistency matters
- Data contracts, quality expectations, and lineage
- Governed access and classification
- Reusable integration and event patterns
Domains retain responsibility for the data they understand. The enterprise establishes how it can be trusted, protected, discovered, and exchanged.
Security requires a stronger shared foundation. Identity, secrets, policy enforcement, vulnerability controls, audit evidence, and baseline monitoring should be centralized or shared capabilities that products inherit by default.
Centralized security does not mean a central team owns every risk decision or workload. Product teams still own their applications, data, dependencies, and business processes; the platform owns the shared controls. EA makes that division explicit so gaps do not hide between boundaries.
The result should be a clear responsibility model: which controls the platform provides, which a product inherits, which obligations remain with the product team, and how evidence is produced. Security then becomes part of the delivery path rather than a review added at the end.
Data and security belong together in the platform strategy because both have enterprise-wide consequences. A local technology choice may be reversible. A fragmented identity model, uncontrolled data copy, or inconsistent interpretation of sensitive information can become structural debt that takes years to unwind.
Design for expansion — and for combination
Enterprise Architects are expected to think ahead. That does not mean predicting every product, market, regulation, acquisition, or technology the business will encounter. Building for every imagined future usually produces a slow abstraction that serves nobody particularly well. The better goal is evolvability.
A platform should establish stable contracts while allowing implementations to change. Identity needs a consumable model, environments a repeatable provisioning path, applications consistent telemetry, policy automated enforcement, and integration defined interfaces rather than institutional memory.
Those contracts create options.
The platform can extend landing-zone patterns into a new region, evolve shared controls with regulation, or introduce a new runtime behind consistent expectations for identity, security, data, deployment, and observability.
But expansion is only one test of the architecture. An even harder one is combination: what happens when two organizations have to operate as one?
Mergers expose architectural fragmentation faster than almost anything else. Each organization arrives with its own identity, data models, security controls, integration patterns, cloud environments, processes, and systems of record. Choices that were reasonable independently become overlapping answers to the same enterprise questions.
The hardest version of this I’ve encountered is in banking and financial services, where institutions grow through mergers while carrying decades of regulated systems, regional models, product-specific data, and tightly coupled processes. The legal transaction can close long before the technology, data, and operating models are integrated. The combined organization may behave like separate enterprises behind a shared brand for years.
The instinct is to select one stack and migrate everything else to it. That may be the right long-term direction, but it is not a transition architecture. Forced consolidation too early can create operational risk and consume years of investment before customers or employees see value.
A platform provides a more practical integration layer. The acquired organization can conform to known contracts for identity federation, data exchange, security evidence, APIs, events, observability, and cost accountability before replacing every system. The technologies may remain different for a time, but the capabilities can begin operating together.
That distinction matters. Technical uniformity is not the first objective of a merger. Business integration is.
The platform can support deliberate transition states:
- Establish trusted identity across both organizations before directories are consolidated
- Expose critical data through governed contracts before systems of record are replaced
- Apply shared security policies and evidence requirements across different technology stacks
- Connect customer and operational journeys through stable APIs and events
- Create common telemetry so the combined estate can be operated and governed as a whole
- Retire overlapping capabilities incrementally as the target portfolio becomes clear
Each step should unlock merger value or reduce risk: enable a combined customer experience, consolidate a duplicated function, improve regulatory visibility, or retire an expensive integration. The platform then becomes part of the merger’s value-realization strategy rather than another technology workstream.
This is how platform engineering supports both expansion and combination: not by standardizing every technology decision forever, but by preserving the enterprise’s ability to grow, merge, and integrate without starting over.
Standardize the undifferentiated; enable the differentiated
The hardest platform decision is what to standardize. Too little and the platform becomes a catalog of suggestions. Too much and it becomes a constraint teams work around.
The right boundary follows business differentiation.
If a capability creates unique customer or market value, the business unit should have room to shape it. If every team needs it but no customer rewards twenty implementations, it is a platform candidate.
Two questions help make that call:
Does a customer reward us for doing this differently? And would a second team, solving it independently, arrive at a meaningfully different answer?
If the answer to both is no, the variation is cost without return and the capability is a strong platform candidate. If either answer is yes, the business unit probably needs room to shape it. The platform’s job is then to enable participation, not dictate implementation.
Identity, pipelines, secrets, observability, provisioning, policy, cost tagging, and recovery patterns rarely differentiate a business unit. How it uses them to serve a customer often does.
The goal is not uniformity. It is intentional variation. Every standard needs an economic or risk rationale; every exception needs an owner, a cost, and a point at which it is reviewed or retired.
Platform engineering makes governance executable
In traditional architecture governance, standards are written down and teams are asked to comply. Review boards inspect designs, identify exceptions, and hope implementation continues to resemble what was approved.
The platform changes that model.
Landing zones can embed network and identity decisions. Pipelines can enforce required checks. Infrastructure modules can provide approved configurations. Observability can be enabled by default. Policy as code can prevent known failure patterns. Cost allocation can be part of provisioning rather than a later reconciliation exercise.
This is governance expressed as a capability rather than a document.
It is also the connection back to transition architecture. Each transition state needs standards, controls, and an operating model that work now — not only when the target state is complete. A platform gives the enterprise a mechanism for introducing those capabilities incrementally, proving them with real teams, and expanding them as each new state inherits what the previous one learned.
The platform becomes the memory of the transformation.
Patterns that work become reusable. Controls that fail can be corrected once. Temporary decisions can be identified instead of quietly becoming permanent. Each team no longer has to rediscover the architecture from the beginning.
The operating model is part of the architecture
A platform does not create value because it exists. It creates value because teams trust it enough to build on it.
That requires an operating model.
The platform needs product ownership, a roadmap, support expectations, funding, security partnership, and consumer feedback. It needs to distinguish strategic capabilities from temporary bridges and retirement candidates. It also needs a way to say no — not to protect a preferred tool, but to protect enterprise coherence and economics.
Funding matters here. If every shared capability must be justified and funded separately by the next business unit that needs it, the platform will always lag behind demand. If the platform is funded as an unlimited central program with no accountability for adoption or outcomes, it can become its own expensive silo.
The investment model should reflect shared value: stable funding for foundational capabilities, transparent consumption and cost data, and continued investment tied to measurable outcomes. Funding shapes behavior. The organization will not get reuse if its financial model rewards every business unit for building independently and treats shared capability as somebody else’s overhead.
The takeaway
Platform engineering is where Enterprise Architecture stops describing standards and starts making them consumable.
Done well, the platform gives business units autonomy where autonomy creates value and a shared foundation where duplication creates cost. It gives independently built capabilities known contracts through which they can participate in the enterprise. It turns governance into paved roads, data and security into shared capabilities, transition decisions into reusable patterns, and technology investment into options the business can exercise later.
The objective is not one stack, one team, or one way to build everything. It is an enterprise that can move as a whole without forcing every part to move in exactly the same way.
So the question I would ask before approving the next platform investment is not simply, “What technology will this standardize?”
It is:
What business capability will this make easier to deliver repeatedly, what cost or risk will it remove, and how will it expand the options available to the business next?
If the platform cannot answer that, it may still be useful infrastructure.
But it is not yet an Enterprise Architecture strategy.
Next in the series: TOGAF in a Cloud-Native World — how the framework evolves when architecture is delivered through platforms, products, and continuously changing systems.