ZHICE PERSPECTIVE / DIGITAL TRANSFORMATION

Composable architecture and legacy modernisation.

Modern architecture should reduce the cost of the next change.

More compute increases technical supply but does not remove waiting between systems. We believe architecture will increasingly earn its value by allowing local change: can one business rule evolve without reopening an entire estate of systems, contracts and teams?

A SIGNAL WORTH EXAMINING950 TWh

Central projection for global data-centre electricity demand in 20301

2026 · Global data centres · 2030 projection
THE ZHICE INTERPRETATION

Compute decisions are also energy decisions.

Expanding compute meets shared constraints in electricity, networks and field operations. ZHICE believes an energy business must compare more than server prices: which tasks stay near their data, which can move, and who maintains service during disconnection will shape reliability and cost. Architecture must connect the business task, the compute resource and the energy context.

THE ARGUMENT BEHIND THE VIEW

A judgement needs a complete argument.

ZHICE PERSPECTIVE

Modern architecture should reduce the cost of the next change.

THE BUSINESS LOGIC OF TECHNOLOGY

THE REASONINGThe business conditions behind the view
01

Value flows outlast system boundaries

Asset operations, settlement and customer service span applications. Tracing these flows reveals which connections should remain stable and which functions need to be replaceable.

02

Legacy can retain an advantage

Established systems often contain years of business rules. Replacement that loses tacit knowledge can recreate old problems in newer technology. Modernisation must distinguish a capability from its current implementation.

03

AI magnifies interface quality

Agents may call business services more frequently. Without clear authority, states and error semantics, automation amplifies coordination ambiguity rather than resolving it.

IMPLICATIONS FOR LEADERS

What should leaders reconsider?

01

Design around rates of change

Stable settlement and control capabilities need not evolve at the same pace as analytical experiences. A common technology agenda does not require identical release cycles.

02

Untie the critical dependencies first

Modernise interfaces that actually constrain business change. Establish transitional accountability and exit conditions before deciding whether further decomposition is worthwhile.

03

Maintain replaceability

Keep interface contracts, test assets and migration capabilities usable. Suppliers and technologies should remain evaluable choices rather than fixed conditions.

WHEN TO RECONSIDER

Composable does not mean maximally fragmented. Limited team capability, weak interface management or modest business scale can make excessive decomposition costly.

When the next business change arrives, which components must change with it and which can remain stable?
FROM PERSPECTIVE TO PRACTICE

Put this perspective to work.

ExpandCollapse

The challenge is often not a shortage of systems: a trading-rule or asset-process change requires coordinated changes across several applications. Vendor boundaries, data copies and tangled interfaces accumulate hidden costs and constrain new services and risk controls.

01

Find the cost of change

Trace representative requirements from request to release, identifying repeated entry, cross-system waits, shared-data changes and vendor dependencies.

02

Define capabilities and interfaces

Clarify boundaries for asset master data, contracts, metering and settlement. Agree service interfaces, event definitions, identity and version management while preserving legitimate variation.

03

Replace high-friction components gradually

Sequence replacements by business value and technical dependencies. Isolate before migrating, using reconciliation, parallel validation and explicit rollback conditions to control transition risk.

Work products

Capability and application-dependency map

Target boundaries, interfaces and data contracts

Modernisation portfolio and migration decision register

What to measure

Business-change lead time
Time from an agreed requirement to usable capability, compared within similar complexity groups.
Coupling burden
Record systems, teams and duplicated-data changes required by a representative business change.

Composability does not require universal microservices. Architectural granularity must fit team capabilities, system scale and operating constraints.

Data notes and research foundationsExpandCollapse
  1. 1
    IEA · Key Questions on Energy and AI, 2026

    Central projection for all global data centres, not AI alone or a capacity plan for an individual enterprise.

    IEA 2026 · Global data centres · 2030 projection
  2. 2
    IBM Institute for Business Value · 2025 CDO Study

    Self-reported confidence across 27 geographies and 19 industries; not an energy-sector adoption rate or observed project success rate.

    IBM 2025 · 1,700 senior data and analytics leaders globally
  3. 3
    DORA · 2024 Report Infographic

    The study uses a broad platform definition; associations with productivity, throughput and stability are mixed.

    DORA 2024 · Cross-industry software-delivery survey
THE NEXT CONVERSATION

The question worth discussing:
what should you do next?

Contact ZHICE