Platform strategy and interoperability

A platform strategy shapes how much reuse the enterprise can achieve, how expensive support becomes, how consistent integration can be, and how easily teams can change together over time. That makes it an enterprise-architecture concern, not only a technology-lead concern.

The architecture question is not simply which platform is best in isolation. It is how much coherence the enterprise needs and where it can tolerate deliberate difference. That question cannot be answered by a single team looking at a single project. It requires the cross-enterprise view that Phase D is supposed to provide.

When platform strategy is absent, local teams make reasonable local choices that create unreasonable enterprise outcomes. Integration becomes expensive. Support costs multiply. Governance loses its grip on the technology estate because there is no shared baseline to govern against. Skills fragment across too many platforms for any single person to maintain expertise.

When platform strategy is too rigid, the opposite problem emerges. Teams that cannot use the mandated platform build shadow solutions that the enterprise cannot see or govern. Delivery slows because every request must be forced through a platform that does not fit the local problem. Innovation dies because the standardisation process cannot keep pace with genuine new needs.

C220 Part 3 of the TOGAF Standard defines a framework for interoperability requirements that is directly relevant to platform strategy. The framework identifies four categories of interoperability, each describing a different level at which systems need to work together. Understanding all four categories is essential because platform decisions affect every level.

Category 1: Operational interoperability

The ability to run and manage systems together. This covers shared monitoring, alerting, log aggregation, and incident response across platforms. If two platforms cannot be observed using the same tooling, operational interoperability is weak. In London, operational interoperability means the OT monitoring team and the enterprise IT operations team can see each other's systems well enough to coordinate during an incident, even if the platforms are physically separated.

Category 2: Information interoperability

The ability to exchange meaningful data across system boundaries. This covers data formats, metadata standards, transformation rules, and semantic agreement. Two systems that can exchange bytes but interpret them differently have syntactic connectivity without information interoperability. In London, information interoperability means the Common Information Model is used consistently enough that data flowing from SCADA to the analytical store to the LTDS publication pipeline does not require bespoke transformation at each boundary.

Category 3: Technical interoperability

The ability to connect systems physically and logically. This covers network protocols, API standards, message formats, and transport mechanisms. Technical interoperability is the most visible category but often the least important when it exists without the others. In London, technical interoperability means the OT network, enterprise IT network, and telecom links can exchange traffic securely, but the security controls and trust boundaries between them are explicit rather than assumed.

Category 4: Business interoperability

The ability to align business processes across organisational or domain boundaries. This is the highest level and the hardest to achieve. It requires not just technical and information interoperability but also shared understanding of business rules, service levels, and accountability. In London, business interoperability means the connections process, the planning function, the publication team, and the regulatory reporting function can all work from a consistent view of network capacity and customer commitment, even though they use different systems.

Platform strategy often swings between two positions, both harmful. Understanding why both fail helps the enterprise find the more honest middle ground.

Rigid standardisation

Everything is forced onto one pattern whether or not the local problem genuinely fits. This can create slow delivery, quiet workaround behaviour, and a growing gap between the official architecture and the real estate. Teams that cannot use the mandated platform often build shadow solutions that the enterprise cannot see or govern.

The architecture cost of rigid standardisation is invisible until you look for it. The official diagram shows one clean platform. The real estate has three additional platforms that nobody documented because the team knew the standard would not be approved. The governance structure thinks it is governing one estate. It is actually governing half of one, while the other half grows in the dark.

In London, rigid standardisation would mean forcing OT systems, enterprise IT, and the publication pipeline onto the same platform. That sounds efficient until you remember that the OT/IT separation principle exists precisely because operational technology has different resilience, security, and recovery requirements from enterprise IT. Forcing them together violates the architecture principle that was established for good structural reasons.

Uncontrolled freedom

Every team optimises locally, which can destroy interoperability, inflate support cost, and make governance nearly impossible. The enterprise ends up with an estate that works locally but fails at any cross-boundary task.

The opening story of this module is a perfect example. Seven messaging platforms across four business units. Each one worked locally. None of them could participate in cross-unit data exchange without bespoke integration. The cost of freedom was paid in integration complexity, not in platform procurement.

In London, uncontrolled freedom would mean each operational domain choosing its own telemetry, data storage, and publication tools without regard for cross-domain data exchange. The result would be six months of integration work every time a cross-domain business question needed an answer.

Controlled variance is not a compromise. It is a deliberate architecture position that requires more discipline than either extreme. The enterprise defines strong defaults, permits explicit exceptions, and enforces interoperability rules that apply to both.

Strong defaults with clear rationale. The enterprise defines a standard platform set and explains why those defaults exist. The rationale should reference business, information, and resilience needs, not just cost or familiarity. When the rationale is clear, teams understand the default and are more likely to follow it willingly rather than under compulsion.

Explicit exception process. Exceptions are permitted, but they must be stated, justified, and governed. Each exception should explain why the standard set does not fit, what interoperability obligations the exception must meet, and how the exception will be supported and governed over time. The Architecture Board should be able to review the exception register and understand why the enterprise has both a standard and a deliberate variant.

Interoperability rules that apply to everything. These rules define what the enterprise requires in terms of data exchange formats, interface contracts, security posture, observability, and lifecycle management. They apply to both standard and exception platforms. They are the glue that prevents controlled variance from drifting into uncontrolled freedom.

Periodic review and consolidation. The exception register should be reviewed at each architecture cycle. Some exceptions become new standards when the original rationale no longer holds. Some exceptions are consolidated back into the standard when the standard evolves. Without periodic review, controlled variance accumulates exceptions that nobody removes.

The TOGAF Series Guide G217 addresses how architecture practice works in digital enterprises where multiple teams deliver at different speeds with different technology stacks. Three patterns from G217 are directly relevant to platform strategy.

Pattern 1: Platform as a shared capability. The enterprise treats its core platforms not as products but as capabilities that teams consume through well-defined interfaces. This decouples platform evolution from application delivery. Teams build on the platform without needing to understand its internals. The platform team evolves the internals without breaking the interface contract.

Pattern 2: Multi-speed architecture. Different parts of the enterprise genuinely change at different speeds. Customer-facing digital services may need weekly releases. Operational technology may change annually. The platform strategy must support this reality rather than pretend that one delivery cadence fits all. In London, the publication pipeline may need quarterly regulatory updates while the SCADA platform changes once every three to five years.

Pattern 3: Guardrail governance. Instead of approving every technology choice centrally, the enterprise publishes guardrails (principles, interoperability rules, security baselines) and lets teams choose within those boundaries. Governance effort shifts from approval bottleneck to guardrail definition and compliance monitoring. The Architecture Board reviews guardrail effectiveness rather than individual technology selections.

These patterns reinforce controlled variance. They acknowledge that uniformity is neither achievable nor desirable in most enterprises, but they insist on coherence at the points where coherence creates enterprise value: integration, observability, security, and governance.

When the enterprise is evaluating platform choices, the comparison should cover more than feature lists and analyst scores. The following criteria are drawn from the interoperability framework and the controlled-variance principle.

Enterprise service support. How well does the option support shared services, common capabilities, and integration patterns that the enterprise depends on? A platform that is excellent in isolation but cannot participate in shared data exchange is a poor enterprise choice.

Interoperability across all four categories. Does the option strengthen or weaken operational, information, technical, and business interoperability? A platform with excellent technical connectivity but no operational observability support creates a false sense of integration.

Operational burden. How much support overhead, skills concentration, and lifecycle risk does the option introduce? A platform that requires specialist skills the enterprise does not have is a strategic liability, not just a training gap. The question is whether the enterprise can sustain the operational model the platform requires.

Governance fit. Can the platform choice be governed within the existing architecture capability? Can the Architecture Board review it, challenge it, and track its lifecycle? A platform that requires its own governance process outside the enterprise architecture framework fragments the governance picture.

Change rate and evolution path. Does the option support the change speed the enterprise needs? How does the vendor or community evolve the platform, and does that evolution path align with the enterprise's own roadmap? A platform with a two-year deprecation cycle may not suit an enterprise that plans five-year infrastructure investments.

Exit cost and lock-in exposure. What would it cost to move away from this platform if the enterprise's needs or the vendor's direction changed? A platform with low entry cost but high exit cost is a strategic risk that the Architecture Board should assess explicitly.

Interoperability is not a vague aspiration. It is a measurable property that the enterprise can test, enforce, and govern. Platform strategy should either improve interoperability or at least avoid weakening it.

The practical tests are straightforward. Can a new system exchange data with existing systems without bespoke transformation? Can operations teams monitor and support the new platform using existing tools and processes? Can governance review the platform choice without needing a separate specialist assessment?

When interoperability is invisible in the platform strategy, the enterprise discovers the cost later. Integration projects take longer. Data quality degrades at boundaries. Support teams cannot cross-skill. Governance loses confidence in the technology estate because it can no longer see the whole picture.

The TOGAF interoperability requirements framework from C220 Part 3 provides a structured way to keep interoperability visible. For each major platform boundary, the architecture should state which of the four interoperability categories apply, what level of interoperability is required, and what evidence will demonstrate that the requirement is met. That turns interoperability from a vague aspiration into a governable requirement.

In London Grid Distribution, platform strategy affects publication capability, operational support, planning reuse, resilience evidence, and how easily the enterprise can absorb new regulatory and transformation demands.

The London case is also useful because it shows why one platform answer is rarely enough. The enterprise needs coherence, but it also needs a realistic exception model for operational and specialist domains.

The OT platform domain. SCADA, distribution management, protection relay management, and substation automation have specific resilience, security, and lifecycle requirements. These platforms change slowly, require specialist skills, and must recover independently. They are a justified exception to the enterprise IT standard.

The enterprise IT domain. Workflow engines, API gateways, analytical platforms, and governance tools follow standard enterprise patterns. They change faster, use common skills, and benefit from standardisation. This is where strong defaults produce the most enterprise value.

The publication and data exchange domain. The LTDS publication pipeline sits between OT data sources and external regulatory consumers. It needs information interoperability with OT (to receive data), technical interoperability with the regulatory platform (to publish data), and business interoperability with the planning function (to ensure consistency). The publication domain may use enterprise IT platforms but has unique interoperability requirements that the platform strategy must address explicitly.

The telecom domain. Field communications, smart-meter networks, and control-system links have their own platform realities. The telecom strategy must be visible in the enterprise platform picture because telecom dependencies cross every other domain.

• London needs strong defaults, not false uniformity. OT platforms, enterprise IT, and publication infrastructure serve different purposes with different constraints.
• Interoperability rules matter because the estate spans planning, operations, data, telecoms, and governance views.
• The LTDS publication obligation creates a hard interoperability test: can operational, planning, and analytical data be combined and published reliably regardless of which platform holds each piece?
• The controlled-variance model means the Architecture Board should know why OT platforms differ from enterprise IT platforms, what interoperability rules apply at the boundary, and how exceptions are governed over time.