Microservices and when not to use them

Start with what the word means. A microservice is a small, independently deployable service that owns a single business capability and its own data, and talks to other services over the network rather than through shared code or a shared database. A microservices architecture is a system built as a set of these services, each one released, scaled, and operated on its own. The style was named by James Lewis and Martin Fowler and set out in depth by Sam Newman in Building Microservices; the TOGAF Series Guide G21I treats the decision to adopt it as an architecture concern rather than a purely technical one.

Microservices are often introduced as a modern engineering pattern, but their real consequences are broader. They affect team structure, deployment discipline, observability, resilience, support burden, platform needs, and how quickly change can spread or be contained across the estate. That is why this topic belongs in enterprise architecture.

The TOGAF Series Guide G21I addresses microservices explicitly. It positions the decomposition decision as an architecture concern that must be evaluated against enterprise conditions, not just engineering preferences. The guide makes clear that the pattern is not inherently good or bad. Its value depends entirely on whether the enterprise can sustain the operating model it requires.

The question is not "are microservices modern?" It is "does this enterprise benefit from this level of decomposition, and can it pay the operating cost?" Those are enterprise questions, not engineering questions.

Microservices provide genuine architectural value under specific conditions. All three conditions should be present, not just one.

Strong domain boundaries. The business responsibilities are clear enough that service boundaries support them rather than fragment them artificially. If the domain model is still unclear, drawing service boundaries is guesswork, and guessed boundaries tend to create expensive cross-service dependencies. The capability map from Phase B should provide the domain clarity. If it does not, the microservice boundaries will be invented rather than discovered.

Real deployment pressure. Different parts of the estate genuinely need to change or scale at different speeds. If the entire system changes together on the same cadence, independent deployment boundaries add coordination cost without delivery benefit. The test is straightforward: do the proposed services actually release independently, or do they always change together?

Operating maturity. The enterprise can support observability, release discipline, interface governance, and failure management at the required level. Microservices without mature observability create systems that nobody can debug. Microservices without interface governance create systems that nobody can change safely. Microservices without distributed-tracing capability create systems where latency problems are invisible until customers complain.

The enterprise should resist microservices when the conditions that justify them are absent. G21I does not say "never use microservices." It says: test the conditions first and choose the simplest decomposition that meets the business need. Here is the full decision framework.

Condition 1: The organisation cannot support the operating overhead. Observability, release coordination, interface versioning, failure propagation, and distributed tracing all require capabilities that many enterprises have not yet built. If the enterprise does not have these capabilities and cannot realistically build them before the system goes live, microservices will create more problems than they solve.

Condition 2: The domain boundaries are still unclear. Service boundaries drawn without domain confidence tend to split things that belong together and join things that should be separate. The rework cost when boundaries are wrong is much higher in a distributed system than in a modular monolith because every boundary change affects network communication, data ownership, failure handling, and interface contracts.

Condition 3: A modular monolith would meet the business need. Not every system needs independent deployment boundaries. A well-structured modular application with clear internal boundaries can deliver most of the maintainability benefits of microservices without the distributed-systems overhead. Internal module boundaries are cheap to move. Service boundaries are expensive to move.

Condition 4: The team structure does not align with service boundaries. Conway's Law is not optional. Service boundaries that cross team boundaries create communication overhead that offsets the architectural benefit. If one team owns three services and another team needs to change two of them for every release, the service boundaries are creating coordination cost rather than reducing it.

If two or more of these conditions are present, a simpler architecture is almost certainly the better choice.

A monolith-first strategy means starting with a well-structured modular application and extracting services only when the conditions justify extraction. This approach has significant advantages that enterprise architects should understand.

Domain boundaries emerge from experience. When the system runs as a modular monolith, the team discovers the real domain boundaries through operational experience rather than guessing them from a whiteboard exercise. The modules that change at different speeds, the modules that scale differently, and the modules that are owned by different teams become visible over time.

Extraction is cheaper than correction. Extracting a well-defined module into a separate service is a relatively straightforward operation. Merging two microservices that were split incorrectly is a much harder operation because data ownership, interface contracts, and failure handling all need to be reunified.

Operating capability builds gradually. The enterprise can build its observability, distributed tracing, and interface governance capabilities incrementally as services are extracted, rather than needing all of that infrastructure in place before the first line of code runs.

Delivery is faster initially. A modular monolith is simpler to develop, test, deploy, and debug than a distributed system. The team can focus on business value rather than distributed-systems infrastructure during the critical early delivery period.

The monolith-first strategy is not anti-microservice. It is pro-evidence. It says: earn your service boundaries through operational evidence rather than assuming them from architectural theory.

A structured decomposition assessment should cover four dimensions before the architecture commits to microservices. For each dimension, the architecture team should rate the enterprise's readiness and record the evidence.

1. Domain quality. Are the business boundaries clear, stable, and well understood? Evidence: the capability map and value-stream analysis from Phase B should provide clear domain boundaries. If Phase B produced unclear or contested boundaries, service decomposition should wait.
2. Deployment pressure. Do different parts of the system genuinely need to change or scale independently? Evidence: release history, change-request patterns, and scaling requirements should show that different modules have genuinely different change rates or load profiles.
3. Operating capability. Can the enterprise support observability, interface governance, failure management, and release discipline for the number of services proposed? Evidence: existing tooling, team skills, incident-response capability, and platform maturity should all be assessed honestly.
4. Team structure. Does the team structure align with the proposed service boundaries? Evidence: the team topology should show that each service can be owned, developed, tested, and released by a single team without requiring coordination across team boundaries for routine changes.

Scoring. If two or more of these dimensions score weakly, a simpler architecture is almost certainly the better choice. The assessment should be recorded as an architecture decision so that the reasoning is visible to the Architecture Board and can be revisited when conditions change.

Enterprise architecture must also decide how to handle emerging technologies such as artificial intelligence, the Internet of Things, blockchain, and edge computing. The position this course takes is that emerging technologies should be assessed through the existing ADM lens rather than managed through separate innovation tracks that bypass architecture governance. For the adjacent question of how ready the enterprise is to adopt a digital technology at all, the TOGAF Series Guide G212, Digital Technology Adoption, provides a readiness assessment and roadmap development method.

The working principle: assess through the ADM, do not create separate tracks

When an enterprise encounters a new technology, the temptation is to create an innovation lab, a proof-of-concept programme, or a separate delivery track that operates outside normal architecture governance. That approach creates two problems. First, it delays the integration decision: the proof of concept succeeds, but nobody has assessed how the technology fits the enterprise estate, data architecture, security posture, or operating model. Second, it creates "innovation theatre" where experiments run in isolation and never connect to enterprise-level change.

The alternative is to assess emerging technologies within the ADM. Phase A asks whether the technology addresses a genuine business driver. Phase B asks what capabilities it would support or replace. Phase C asks what data it produces, consumes, or transforms. Phase D asks what infrastructure, integration, and security implications it creates. This is not bureaucracy. It is the minimum assessment that prevents the enterprise from adopting technology without understanding its consequences.

Innovation theatre versus architecture-governed experimentation

Innovation theatre produces demonstrations that impress stakeholders but never reach production because nobody planned for integration, data governance, security, or operating cost. Architecture-governed experimentation uses the same ADM disciplines but applies them proportionately: a lightweight Phase A assessment for the business case, a focused Phase D assessment for technical feasibility, and explicit criteria for when the experiment graduates to the enterprise roadmap or is retired.

The distinction matters because enterprises often accumulate dozens of proofs of concept that consume engineering time without producing enterprise value. The discipline that prevents this is a defined exit condition for every emerging-technology experiment: either it graduates into the architecture landscape through a governed ADM process, or it is explicitly retired with lessons recorded.

Practical assessment for common emerging technologies

Artificial intelligence and machine learning. The architecture questions are about data quality, model governance, explainability requirements, and where AI outputs enter decision chains. An AI model that produces predictions used in regulatory reporting has different architecture requirements from one that suggests internal process improvements.

Internet of Things and edge computing. The architecture questions are about data volume, network dependency, edge-to-cloud integration patterns, security at the device level, and lifecycle management for large device estates. IoT creates concentration risk if all devices depend on a single cloud platform.

Blockchain and distributed ledger. The architecture questions are about whether the trust model genuinely requires distributed consensus or whether a traditional database with audit trail would serve equally well at lower complexity. Most enterprise blockchain proposals fail the simpler-alternative test.

The London case involves several emerging technologies that need ADM-based assessment rather than separate innovation tracks.

Smart meters and IoT. The smart-meter estate is a large-scale IoT deployment. The architecture questions include: how does meter data flow from devices through concentrators to the head-end system? What happens when the communication network fails? How is meter firmware managed across millions of devices? These questions belong in Phase D, not in a separate innovation workstream.

Edge computing for fault prediction. If the enterprise explores edge analytics for predicting equipment failures from sensor data, the architecture assessment must cover data quality at the edge, the latency requirements for predictions that affect operational decisions, the security model for edge devices on the OT network, and the integration path between edge predictions and the distribution management system.

AI for network planning. Machine-learning models that predict demand growth or optimise connection offers must be assessed for data provenance (what training data, and is it representative?), model governance (who validates the model, and how often?), and regulatory acceptability (will Ofgem accept AI-generated capacity assessments in LTDS publications?).

In each case, the approach is the same: assess through the ADM, define graduation criteria, and retire experiments that do not meet them. London does not need an innovation lab. It needs architecture discipline applied to emerging technology decisions with the same rigour as any other technology choice.

The London case is useful because some responsibilities may benefit from clearer service decomposition while others would become slower and more fragile if split too aggressively. Publication, planning, telemetry, and governance all have different change pressures.

Publication may benefit from separation. The LTDS publication pipeline has a distinct regulatory cadence (quarterly or annual), clear domain boundaries (data validation, formatting, and submission), and a different change rate from operational systems. The four-dimension assessment would likely show strong domain quality, real deployment pressure (regulatory deadlines differ from operational cadences), and manageable operating requirements. This is a reasonable extraction candidate.

OT telemetry should probably stay monolithic. The coupling between SCADA telemetry, the distribution management system, and protection relay management is tight. These systems change together on the same long cycle (three to five years). Breaking them into separate services would add distributed-systems complexity to a domain where simplicity and reliability are paramount. The four-dimension assessment would show weak deployment pressure and high risk from added complexity.

The connections workflow is a borderline case. The digital customer self-service channel has a faster change rate than the backend network assessment systems. If the team structure supports it, the customer-facing layer might benefit from separation. But the backend assessment depends on real-time network data from operational systems, creating tight coupling that service boundaries would need to manage carefully.

• London should not be decomposed into microservices by default. Each decomposition decision should follow the four-dimension assessment.
• The operating model is as important as the service diagram. A service architecture that the enterprise cannot observe, govern, or recover is worse than a monolith that it can.
• Publication may benefit from separation because it has a distinct regulatory cadence. OT telemetry may not, because its coupling to operational systems is tight and its change rate is low.
• A monolith-first strategy for the connections workflow would let the enterprise discover the real domain boundaries through operational experience before committing to service extraction.