A monolithic system has not become technologically obsolete. However, it ceases to function effectively where different parts of the business are developing at different rates. The price list may change every week, whilst the general ledger is updated once a quarter. A recommendation engine requires rapidly increasing computing power, whilst an HR system requires, above all, stability. Confining these functions to a single implementation cycle restricts the company. Breaking each of them down into several services may restrict it even further.
A composable enterprise is not synonymous with microservices. It is a way of organising technology around independent business capabilities: payments, pricing, product catalogues, customer identity or analytics. Each such area should have clearly defined boundaries, an owner, interfaces and maintenance costs.
The technology needed to build such environments is already mature. According to a CNCF study published in January 2026, 82 per cent of container users are using Kubernetes in production. In 59 per cent of organisations, a large proportion or almost all development and deployments already take place using a cloud-native model. The availability of the infrastructure itself is therefore not an issue. The problem remains its complexity.
The cost of distributed architecture
Each separate component requires its own deployment, monitoring, security and troubleshooting. Added to this are alerts, API versioning, secret management, integration testing, data transmission and on-call duties. A microservice may have a small amount of code, yet still generate significant organisational costs.
The State of FinOps 2025 survey involved companies collectively responsible for $69 billion in public cloud expenditure. Optimising workloads and reducing waste remained their top priority. Already, 63 per cent of the teams surveyed were also managing AI costs, compared with 31 per cent a year earlier. The decentralisation of architecture is therefore not merely a technical issue. Increasingly, it is subject to the same economic controls as staffing, logistics or energy procurement.
The boundary should be the business, not the code
Separation is required, first and foremost, for functions that have their own development cycle, workload profile or risk level. Good candidates include payment systems, login systems, real-time pricing systems or AI model management systems. These can be deployed independently, scaled according to different principles and isolated in the event of a failure.
The boundaries of a service should not be defined by a database table, a technical layer or the structure of existing code. The point of reference is a coherent area of activity, known in domain-driven design as a ‘bounded context’. Within this context, concepts, rules and responsibilities remain unambiguous. AWS and Microsoft recommend separating systems according to business capabilities and subdomains, rather than an arbitrary number of functions or modules.
Autonomy must be genuine. A service that shares a database with several other services is not independent. The same applies to a component whose deployment requires simultaneous changes across three teams. In such cases, the coupling does not disappear. It is merely transferred from the code to the network, processes and organisational structure.
When a monolith is better
Stable backend systems, maintained by a single team and rarely modified, usually do not require a distributed architecture. If their functions use the same data model, participate in the same transactions and are always deployed together, a modular monolith will be simpler and cheaper.
Microsoft points out that microservices simplify individual components but complicate the system as a whole. Problems arise with data consistency, network communication, dependency testing and transaction handling. Overly granular services increase complexity and may impair performance.
A practical test is the number of connections exceeding the planned limit. If a new component has to fetch data from several other services for most operations, the limit has been set incorrectly. Instead of autonomy, a system of intensive communication emerges, prone to delays and cascading failures.
Modernisation without major rewriting
The separation of a component should yield a measurable benefit: shorter deployment times, independent scaling, reduced scope of failure, lower unit cost, or more effective data protection. Without such justification, modernisation remains a costly infrastructure project.
Large systems should not be rewritten all at once. The strangler fig pattern allows selected functions to be gradually spun off, with traffic redirected to them, whilst maintaining both the old and new versions in parallel for a certain period. This reduces the risks associated with migration and allows the change to be rolled back without bringing the entire organisation to a standstill.
Resilience requirements are also increasing. DORA has been in force in the financial sector since 17 January 2025, covering ICT risk management, incident management and third-party suppliers. The first EU report, published in June 2026, recorded 3,383 serious ICT incidents. Around one-third were cross-border in nature, with system failures and external events being the main causes. Every additional architectural dependency therefore also becomes an operational and regulatory dependency.
The architecture should reflect the volatility of the business. Functions with different rhythms, risks and economics should be isolated. Elements that are stable, transactional and highly interdependent should be consolidated. If two modules cannot be deployed, scaled and billed independently, labelling them as microservices does not alter the fact that they form a distributed monolith.
