The Composability Bill

Section 01: Executive summary

For most of the past decade, the prevailing wisdom in enterprise architecture held that the monolithic suite was dead and the future belonged to composability: assemble the best tool for each capability, connect them through interfaces, and gain the agility to replace any piece without disturbing the rest. The movement acquired a name, MACH, for the microservices, API-first, cloud-native, and headless principles that underpin it, and an analyst-backed narrative that organizations adopting it would dramatically outpace those that did not. Enterprises across commerce, marketing technology, and the broader software estate decomposed their suites and assembled best-of-breed stacks, buying the promise of agility and freedom from lock-in.

This article is about the bill for that promise, which comes due later and lands harder than the purchasing decision anticipated. The cost of a composable architecture is not the sum of its license fees, which is the visible and budgeted part. It is the cost of owning the assembly: managing dozens of independent vendors, paying for overlapping and redundant functionality, absorbing the version and compatibility drift of components that evolve on their own schedules, staffing the specialized talent required to run the stack, and, above all, maintaining the connective layer and the governance of a system that no single vendor owns and that, inside the enterprise, frequently no one owns either. By 2025 and 2026 the pendulum was visibly swinging back toward consolidation, with vendors inside the movement conceding its costs, competitors attacking it, and organizations re-consolidating stacks that had become unmanageable. We say honestly that composability is genuinely valuable at the points of real differentiation, and that a blanket retreat to the suite is as mistaken as composing everything was. But a buyer should understand the full bill before signing up for the seams, because the agility is real and so is the cost, and the cost is mostly the part the license price conceals.

Section 02: The bill comes due

The composability bill has a characteristic timing that shapes how organizations experience it: the benefits are front-loaded and visible, while the costs are back-loaded and diffuse. At the point of decision, the composable approach offers a compelling and immediate case. The organization can select the best tool for each capability rather than accepting the compromises of a suite, can avoid committing to a single vendor's roadmap, and can imagine replacing any component that disappoints without disturbing the others. These benefits are concrete, articulable, and available at the moment of choice, and they make the composable decision feel obviously correct. Figure 1 sets the promise against the reality that emerges later.

The costs arrive on a different schedule. They accumulate over the years of owning and operating the assembly, and they are diffuse enough that no single one prompts a reckoning. The integration that connected the components must be maintained as the components change. The vendors must each be managed, renewed, and coordinated, a burden that grows with their number. The connective layer that makes the pieces work together becomes a permanent operating cost, not the one-time build it was imagined to be. The specialized talent required to run a composed stack must be hired and retained. And the redundancies between overlapping tools quietly inflate the spend. None of these is a dramatic, budget-line failure; each is a slow, diffuse cost that the organization absorbs without fully attributing it to the composable decision that created it.

This timing asymmetry is why the composability bill is so frequently underestimated at the point of decision and so frequently a source of regret later. The decision is made on the front-loaded, visible benefits, which are real, and the back-loaded, diffuse costs, which are also real, are not fully weighed because they are harder to see and to quantify in advance. By the time the costs have accumulated to the point of prompting a reckoning, the organization has a complex assembly it depends on, staff whose roles are built around it, and a sunk investment in the integration, so the reckoning is difficult and the re-consolidation, if it comes, is expensive. The bill comes due, but it comes due slowly, in a form that makes it hard to attribute and hard to reverse.

The purpose of this article is to bring the back-loaded costs forward, so they can be weighed at the point of decision rather than discovered after it. This is not an argument against composability, which has genuine value, but an argument for costing it fully, for understanding at the moment of choice what owning the assembly will actually require over its life, so the decision reflects the whole bill and not only the visible, front-loaded portion. An organization that costs composability fully may still choose it, correctly, for the capabilities where its benefits justify its costs, and will avoid choosing it for the capabilities where they do not. The failure this article addresses is not choosing composability but choosing it on a partial accounting, and the remedy is a complete one.

The timing asymmetry has a further consequence that compounds the difficulty of reversing course: by the time the back-loaded costs become undeniable, the organization has restructured itself around the composed architecture in ways that resist unwinding. Teams have been hired and organized around the individual components; processes have been built to bridge the seams; institutional knowledge has accumulated about how the particular assembly works and where its fragilities lie. This organizational entrenchment is itself a cost, and it is one that grows with time, so that the longer a composed architecture runs, the more the organization is shaped around it and the harder any consolidation becomes. The bill is not only financial and operational; it is organizational, embedded in how the enterprise has arranged its people and processes around the assembly, and that embedding is what makes the eventual reckoning so difficult.

There is an instructive parallel with the way technical debt accumulates in software, and it clarifies why the composability bill is so easily deferred and so painful to pay. Technical debt, like the composability bill, is incurred through decisions that are locally reasonable and immediately beneficial but that accumulate a hidden liability payable later, and like the composability bill, it is invisible on any balance sheet and easy to ignore until it becomes acute. The composable architecture accumulates a form of architectural debt: each best-of-breed addition, each unowned seam, each redundant tool is a small liability that does not prompt action in isolation, and the liabilities compound silently until the cost of servicing them, in integration maintenance, vendor management, and operational friction, becomes a drag the organization can no longer ignore. Recognizing the composability bill as a form of debt, incurred now and payable later with interest, is the right mental model, because it captures both why the bill is so readily deferred and why deferring it makes it larger.

Section 03: MACH and the composable promise

To assess the composability bill fairly, one must first understand what composability is and why its promise is truly attractive, because the critique that follows is not that the promise is empty but that its cost is understated. The technical foundation of the composable enterprise is captured in the acronym MACH, and Figure 2 sets out its elements.

Microservices means building functionality as independent, individually deployable services rather than as a single monolithic application, so each service can be developed, scaled, and replaced on its own. API-first means that every capability is exposed through a well-defined interface, so services can be connected and recombined. Cloud-native means the architecture is built to run on elastic cloud infrastructure, scaling with demand. Headless means the front-end presentation layer is decoupled from the back-end business logic, so the same back-end can serve many front-ends and each can evolve independently. Together these principles describe an architecture assembled from independent, interface-connected, cloud-based, decoupled components, which is the technical realization of composability.

Each of these principles is sound, and the promise they collectively enable is real. An organization built on MACH principles can, in theory, select the best microservice for each function, connect them through their interfaces, run them on elastic infrastructure, and present them through whatever front-ends it needs, replacing any component independently as better options appear or requirements change. This is genuine agility, and for capabilities where the ability to select the best tool and to evolve rapidly matters, it is materially valuable. The critique in this article is emphatically not that MACH is bad architecture or that composability is a mistake in principle; the principles are sound and the agility is real for the situations that need it.

The critique is that the bill for realizing this promise is understated, and specifically that the cost lives not in any individual principle but in owning and operating an architecture built on all of them at once, assembled from many independent vendors. Each principle, applied, adds a dimension of independence, and independence has a cost as well as a benefit: independent components must be connected, coordinated, and kept compatible, and the connecting, coordinating, and keeping-compatible is work that grows with the number of independent pieces. The elegance of the architecture in the diagram conceals the operational burden of the assembly in practice, and the promise of agility is real but is purchased with a permanent cost of integration and governance that the next sections quantify. Understanding MACH is understanding both why the promise is attractive and where the bill comes from: the same independence that enables the agility creates the cost.

It is worth being precise about the relationship between the technical principles of MACH and the organizational costs this article emphasizes, because the two are frequently conflated in the debate. MACH describes an architecture, a way of building software as independent, interface-connected, cloud-based, decoupled components, and as architecture it is sound. The composability bill is not a critique of the architecture but of what owning an architecture built on those principles requires organizationally, and the distinction matters because it locates the problem correctly. An organization can adopt MACH principles competently, building truly composable software, and still pay the full bill if it lacks the organizational structures, the owner of the whole, the portfolio governance, the platform engineering, that owning a composed architecture requires. The technical soundness of the architecture does not spare the organization the ownership costs, and the debate frequently errs by treating the question as architectural when it is largely organizational.

This locates the constructive response correctly as well. If the composability bill were an architectural problem, the response would be architectural, a better way of building composed systems. But because the bill is largely organizational, arising from the ownership, governance, and integration that composed architectures require, the response is organizational: establishing the owners and governance and disciplines that keep the bill in check. An organization that responds to the composability bill by seeking a better architecture is looking in the wrong place, because the architecture is not the problem; the organization's arrangements for owning and governing the architecture are. The later sections' emphasis on owners of the whole, portfolio governance, and continuous rationalization reflects this diagnosis: the composability bill is paid down not through better technology but through better organization, the deliberate establishment of accountability for the seams, the estate, and the total cost that a composed architecture would otherwise leave orphaned.

Section 04: The bill-of-materials the license hides

The central financial error in composable purchasing is to reckon the cost as the sum of the license fees, because the license fees are the smallest and most visible part of the true cost of ownership. The larger part is a bill-of-materials that the license price conceals, and Figure 3 sets it out.

Begin with the connective layer, which is the most underestimated cost. In a composed architecture, the components must be connected to one another, and that connection, the middleware, the integrations, the data flows, the orchestration, is not a one-time build that can be completed and forgotten. It is a permanent operating cost, because the components it connects change continually, on their own schedules, and each change may require the connections to be updated. The organization that budgeted the integration as a project cost, to be incurred once during implementation, discovers that it is an operating cost, incurred continually for the life of the architecture, and that the team maintaining it never disbands because its work never ends. The connective layer is the price of composability, and it is a recurring price, not a one-time one.

Add to this the vendor-management burden, which scales with the number of vendors. Each vendor in a composed stack must be contracted, renewed, monitored for performance and security, coordinated with the others, and managed through its own changes and incidents, and a stack of dozens of vendors multiplies this burden accordingly. A suite concentrates the vendor relationship into one; a composed stack disperses it across many, and the dispersed relationships consume procurement, security, and management attention in proportion to their number. Add the specialized talent required to run a composed stack, which is scarcer and more expensive than the talent to run a suite, because it requires understanding the many components and their interactions rather than a single vendor's product. Add the effort of managing version and compatibility drift, as independently-evolving components fall out of alignment and must be realigned. And add the expanded security surface, as each component and each connection is a potential vulnerability, and the attack surface grows with the number of pieces.

None of these costs appears on the license invoice, and that is precisely why they are underestimated. The license fees are visible, budgeted, and easy to compare across options, so purchasing decisions anchor on them, and the far larger costs of owning the assembly, being diffuse, recurring, and spread across integration, operations, security, and talent, are not fully weighed. An organization comparing a composed stack to a suite on license fees is comparing the two on the dimension where the composed stack looks best and the true cost is least represented, and it will systematically underestimate the composed stack's total cost of ownership as a result. The remedy is to build the full bill-of-materials before deciding, costing the connective layer as permanent opex, the vendor management as a function of vendor count, the specialized talent, the drift management, and the security surface, so the comparison reflects the whole cost of owning each option and not merely the price of licensing it. The license is the visible tip; the bill-of-materials is the mass beneath.

A concrete way to make the hidden bill-of-materials visible is to compute the fully-loaded cost per composed capability and compare it to the suite alternative on the same basis, which frequently reverses the apparent cost advantage. The composed stack often wins on license fees, because best-of-breed components can be individually cheaper than a suite's bundled pricing, and this apparent saving is what the license-anchored comparison sees. But when the connective layer, the vendor management, the specialized talent, the drift management, and the security surface are added, the composed stack's fully-loaded cost frequently exceeds the suite's, sometimes by a wide margin, because the suite bundles the integration and the single-vendor management that the composed stack must provide separately. The organization that computes the fully-loaded comparison discovers that the license saving it thought it was capturing is more than offset by the ownership costs it did not count, and that the suite it rejected on price was cheaper on total cost of ownership.

The specialized-talent cost deserves particular emphasis because it is both large and easily overlooked, and it has grown more acute as the market for the relevant skills has tightened. Running a composed architecture requires people who understand the many components and, crucially, their interactions, which is a scarcer and more expensive skill than operating a single vendor's suite, where the vendor provides much of the operational knowledge and support. The composed stack makes the enterprise responsible for the integration knowledge that a suite vendor would otherwise supply, and that knowledge is embodied in specialized engineers whose scarcity commands a premium and whose departure creates risk, because the knowledge of how the particular assembly works is frequently held by a few individuals and poorly documented. An enterprise that composes is taking on a talent dependency, on scarce, expensive, hard-to-replace specialists, that a suite would have spared it, and this dependency is a real and recurring cost that the license comparison entirely omits and that the enterprise feels acutely when a key engineer leaves.

Section 05: The owner of the whole

Beyond the financial bill lies an organizational one that is subtler and frequently more damaging: in a composed architecture, no single party owns the whole. Each vendor owns its component, and the enterprise owns its selection of components, but the end-to-end experience, the way the pieces work together to deliver a coherent capability, belongs to no vendor and, inside many enterprises, to no one at all. This accountability vacuum is where composed stacks decay, and it is a cost the purchasing decision rarely considers.

Consider what happens when a composed capability fails in a way that spans components. A customer-facing process that draws on a headless front-end, several microservices, and a data layer, each from a different vendor, breaks in a way that is not clearly attributable to any single component. Each vendor, examining its own piece, finds it working to specification, and the failure lives in the interaction between pieces, in the seams, which no vendor owns. The enterprise, if it has not designated an owner of the whole, finds that no one is accountable for the end-to-end experience, and the failure persists in a gap between responsibilities, with each vendor correctly disclaiming ownership of a problem that is truly not in its component. The seams are where composed stacks fail, and the seams are precisely what no vendor owns.

A suite does not have this problem to the same degree, and this is one of its genuine and underappreciated advantages. When a single vendor provides the integrated capability, that vendor owns the whole, and a failure anywhere in the capability is the vendor's responsibility, because the vendor provided the integrated whole rather than a component of it. The enterprise has a single accountable party for the end-to-end experience, and the seams are internal to the vendor's product and therefore the vendor's problem. The composable approach trades this single accountability for the flexibility of assembling best-of-breed components, and the trade is frequently made without recognizing that single accountability was a benefit being given up, so the enterprise finds itself owning the seams it did not realize it was taking on.

The remedy, examined further in the governance section, is for the enterprise to explicitly designate an owner of the whole, a team accountable for the end-to-end experience and the seams between components, since no vendor will own them. This is a real cost, a platform or architecture team whose job is the integration and coherence of the assembly, and it is a cost the composable decision creates and must fund, because without it the seams belong to no one and the stack decays in the gaps between vendor responsibilities. An enterprise that composes without designating an owner of the whole has created an architecture whose most failure-prone parts, the seams, are unowned, and it will pay for that omission in persistent, unattributable failures that no vendor will fix because no vendor is responsible. The owner of the whole is not optional overhead; it is the organizational counterpart to the connective layer, the human ownership of the seams that the connective layer technically implements, and composing without it is composing without anyone responsible for whether the pieces actually work together.

The owner-of-the-whole problem has a precise analogue in system reliability engineering that sharpens what is at stake, which is the distinction between component reliability and system reliability. A composed architecture can have highly reliable components, each individually robust and well-maintained by its vendor, and still have poor system reliability, because system reliability depends not only on the components but on their interactions, and the interactions are the seams that no component owner is responsible for. A chain of individually reliable components connected by unowned seams is only as reliable as its seams, and the seams, being unowned, are frequently the least reliable part, so that the composed system's reliability is dragged down by exactly the connections that no vendor maintains. The owner of the whole is the party responsible for system reliability as distinct from component reliability, and an architecture without such an owner optimizes component reliability, which the vendors provide, while neglecting system reliability, which no one provides.

This distinction explains a frequently puzzling experience of composed architectures, which is that they fail in ways that no post-mortem can cleanly attribute. When a composed capability fails, the investigation examines each component and finds each working correctly, because the failure was not in any component but in the interaction between components, in a timing dependency, a data-format mismatch, an assumption one component made about another that the other violated. These interaction failures are truly no component's fault, and each vendor correctly reports its component healthy, so the failure lives in the seams and the post-mortem cannot pin it on any owner, because no owner exists for the seams where it occurred. An organization that experiences repeated unattributable failures in a composed architecture is experiencing the symptom of the missing owner of the whole, and the remedy is not to press the vendors harder, since none is at fault, but to establish the owner of the whole who is responsible for the interactions and can address the failures that live between components rather than within them.

Section 06: The pendulum swings back

Enterprise architecture has a long history of swinging between integration and decomposition, between the consolidated suite and the assembled best-of-breed stack, and the composable movement represents one full swing of that pendulum toward decomposition. By 2025 and 2026, the pendulum was visibly swinging back, and understanding the swing helps a buyer avoid being caught at the extreme. Figure 4 illustrates the oscillation.

The swing toward composability was driven by real frustrations with the monolithic suite: its compromises, where a single vendor's version of each capability was accepted even where a better alternative existed; its lock-in, where the enterprise was committed to one vendor's roadmap and pricing; and its slowness, where change required the vendor's cooperation. These frustrations were genuine, and composability answered them, which is why the movement gathered force. But the answer created its own frustrations, the ones this article catalogs: the cost of owning the assembly, the missing owner of the whole, the sprawl and redundancy, the operational burden. And as those frustrations accumulated, the pendulum began to swing back, toward consolidation and platformization, as organizations sought to reduce the number of vendors, re-integrate the assembly, and recover the simplicity the suite had offered.

The swing back is visible in several forms. Organizations are undertaking application-rationalization initiatives to reduce the number of tools they run, consolidating overlapping functionality onto fewer platforms. Vendors are repositioning from pure best-of-breed toward platforms that offer multiple capabilities in a more integrated form, capturing the demand for consolidation. And the discourse has shifted, from the near-unanimous enthusiasm for composability of a few years ago toward a more skeptical assessment of its costs and a renewed appreciation for the advantages of integration. The pendulum has not swung all the way back to the monolithic suite, and it will not, because the frustrations that drove the move away from the suite were real. But it has swung back from the extreme of composing everything, toward a more balanced position that composes selectively and consolidates where composition is not worth its cost.

The lesson for a buyer is to avoid being caught at either extreme of the pendulum, because both extremes are wrong and the pendulum's position at the moment of decision is a poor guide to the right architecture. An organization that adopted composability at the height of the enthusiasm, composing everything because that was the prevailing wisdom, is now confronting the costs and may over-correct by consolidating everything as the pendulum swings back, which would be the opposite error. The right position is not wherever the pendulum happens to be but a stable, considered one that composes at the points of genuine differentiation and consolidates the commodity capabilities, regardless of which way the fashion is currently swinging. The pendulum's swing is a caution against following the fashion to either extreme, and the constructive sections of this article describe the stable position that resists the swing.

The pendulum metaphor, while useful, should not obscure an important asymmetry between the two extremes it swings between, which is that the costs of each extreme fall on different parties and at different times. The costs of over-consolidation, the suite's lock-in and compromise, fall relatively evenly and are felt continuously, as a steady friction of accepting one vendor's version of everything. The costs of over-composition, by contrast, are back-loaded and concentrated, felt lightly at first and then heavily as the bill accumulates, and they fall disproportionately on the operational and engineering functions that must run the assembly, while the strategic benefits were credited to the functions that chose to compose. This asymmetry means that the swing toward composition is easier to initiate than the swing back, because the initiating functions capture the visible benefits while the costs land later and elsewhere, and it helps explain why organizations over-compose: the decision-makers capture the upside and diffuse the downside across time and function.

Understanding the pendulum also guards against a specific error that organizations make as it swings back, which is to consolidate reflexively in reaction to the composability bill without applying the per-capability discipline that would preserve composition where it truly pays. An organization that has suffered the costs of over-composition may swing to the opposite extreme, consolidating everything onto suites to escape the bill, and in doing so sacrifice the composition of the differentiating capabilities where the agility was materially worth its cost. This over-correction trades one blanket error for its opposite, giving up real competitive advantage at the points of differentiation in order to escape a bill that was only justified to eliminate at the points of commodity. The disciplined response to the composability bill is not to consolidate everything but to consolidate the commodity capabilities while preserving composition where it differentiates, which requires resisting the reflexive swing and applying the per-capability judgment even, and especially, when the accumulated pain of over-composition creates pressure to abandon composition entirely

Section 07: The hype and its author's reversal

The composable movement was propelled by an analyst-backed narrative that lent it the authority of research and the momentum of predicted inevitability, and examining that narrative, and its author's subsequent reversal, is instructive about how technology fashions are made and unmade. Figure 5 juxtaposes the original predictions with the later ones.

The influential analyst firm that coined the term composable business made, around 2020, a set of predictions that became central to the movement's momentum. It forecast that a large majority of organizations would move toward composable business within a couple of years, and that organizations adopting the approach would outpace their competitors by a dramatic margin. These predictions were widely cited, by vendors selling composable products and by organizations justifying composable initiatives, and they gave the movement the authority of analyst research and the urgency of a predicted competitive divide: adopt composability or be left behind. It is important to read these as forecasts, projections of what the firm expected to happen, rather than as measurements of what did happen, because they were predictions, and predictions of adoption and competitive advantage are exactly the kind of claim that a movement's momentum is built on and that later reality may or may not vindicate.

The same analyst firm later made predictions in a different direction, forecasting that cloud ecosystems would consolidate the vendor landscape substantially over the following years. This is not a contradiction so much as a reading of the pendulum: the firm that identified and named the swing toward composability also identified the swing back toward consolidation, and its predictions bracket the hype cycle, the enthusiasm at the top and the consolidation on the way down. But the juxtaposition is instructive, because the organizations that adopted composability on the strength of the early predictions were acting on forecasts that the same source would later balance with forecasts of consolidation, and a buyer who took the early predictions as settled truth rather than as one moment in an evolving analyst view was building an architecture on a fashion the analysts themselves would move past.

The broader lesson concerns how much weight to give analyst-backed technology narratives in architectural decisions, which is less than their authority suggests. Analyst predictions of adoption and competitive advantage are well informed and worth considering, but they are predictions, subject to revision, and they participate in the hype cycles they describe, lending momentum to movements at their peak and identifying their reversal on the way down. An organization that makes a major architectural commitment on the strength of a prediction that a technology approach is inevitable and competitively decisive is building on a foundation that may shift, as the composable narrative shifted, and the same analysts who supplied the original momentum may later supply the momentum for the reversal. The prudent posture is to weigh analyst narratives as informed input into a decision that rests on the organization's own analysis of its own needs, not to treat them as a mandate, because the narratives move, and an architecture built to follow them will be perpetually chasing a fashion rather than serving the enterprise. The predictions that launched the composable movement, read years later against the predictions of its reversal, are a caution about the durability of the narratives on which architectural fashions are built.

The dynamics of the analyst-driven hype cycle deserve a closing observation, because they recur across technology fashions and a buyer who recognizes the pattern is inoculated against the next one. A fashion begins when an influential source names and champions an approach, lending it authority; vendors align their products and marketing to the named approach, amplifying it; early adopters and case studies accumulate, and the approach acquires the momentum of apparent inevitability, which pressures later adopters to follow lest they be left behind. Then the costs of the approach accumulate, the early enthusiasm meets the operational reality, and the same sources that championed the approach begin to identify its limits and its successor, and the fashion swings the other way. Composability followed this arc exactly, and the next architectural fashion will follow it too, which is why the durable posture is not to chase the fashion at its peak but to make architectural decisions on the enterprise's own analysis of its own needs, weighting analyst narratives as informed but interested input rather than as mandates, and thereby resisting the pressure to adopt at the top and abandon at the bottom that the hype cycle exerts on those who follow it.

Section 08: The re-consolidation, in cases

The swing back toward consolidation is not only a matter of analyst predictions and general discourse; it is visible in specific cases of organizations that composed, found the assembly unmanageable, and re-consolidated. These cases must be handled carefully, because the best-documented ones come from interested sources, and Figure 6 both presents them and flags their provenance.

The most prominent public critique came from a commerce-platform vendor whose co-chief-executive published a pointed attack on what he called the MACH mirage, arguing that the pure best-of-breed approach led organizations down a path of hidden costs, operational difficulties, and unfulfilled promises, and his company suspended its support for the industry alliance that promotes the approach. This is a serious and specific critique from someone with deep knowledge of the domain, and it must be read with the clear understanding that the vendor is a commercial competitor to the pure-composable vendors and has an interest in attacking their approach. The critique is not neutral, and the alliance it targeted rebutted it, arguing that forcing the approach across an entire enterprise without regard to context was the actual error. The competitor's critique is evidence, but interested evidence, and it is flagged as such.

More telling, because it comes from inside the movement rather than from a competitor, is the concession by composable vendors themselves that a phenomenon they call MACH-washing exists: architectures marketed as composable that are, in practice, monolithic, composable on paper but not in operation, because the organization lacked the ownership and discipline to realize the composable promise. When the vendors selling composability concede that much of what is sold as composable does not deliver the composable benefit, and that the difference lies in organizational ownership rather than technology, they are corroborating, from inside the movement, the central argument of this article: that the composable promise depends on owning the whole, and that many organizations that compose do not, and end up with the costs of composition without its benefits. This concession from interested parties who would prefer to report success is more credible for being against their interest.

The most concrete cases come from the agencies that build and migrate commerce sites, who report brands that went headless, encountered rising development costs and slow turnaround because every content change required a developer, and migrated back to more integrated platforms, in at least one cited instance with the composable complexity a contributing factor in a business failure. One agency reports that it talks a large majority of brands out of headless architecture, and that abandoned headless builds accumulate technical debt within months when the organization lacks a dedicated team to maintain them. These agency reports are the richest source of specific cases, and they too are interested, because the agencies make their living migrating brands and have a view to sell. But the pattern across all these sources, a competitor attacking, vendors inside the movement conceding, and practitioners who inherit the failed builds reporting, is consistent despite no single source being neutral, and it is the consistency across differing interests that makes the re-consolidation credible. Each source alone would be discountable for its interest; together, pointing the same direction from different interests, they describe a real phenomenon, which is why the cases are presented with their provenance flagged rather than either suppressed or accepted uncritically.

Section 09: SaaS sprawl and the economics of too many tools

The composability bill has a macro-scale counterpart in the phenomenon of SaaS sprawl, the accumulation of software-as-a-service applications across an enterprise to numbers that create their own management and cost problems. The composable philosophy, applied across the whole software estate rather than a single domain, produces sprawl, and Figure 7 shows its scale.

The marketing-technology landscape, tracked annually, has grown from roughly 150 tools in 2011 to over fifteen thousand in 2025, a proliferation that illustrates how many independent, best-of-breed options exist and how the composable philosophy, applied at scale, multiplies the tools an enterprise might assemble. At the enterprise level, the average organization now runs on the order of three hundred SaaS applications, and a substantial share of these are redundant, with multiple tools performing overlapping functions, or underused, with licenses paid for and not used. The sprawl is the aggregate result of many local best-of-breed decisions, each sensible in isolation, accumulating into an estate that no one designed and that carries substantial redundancy and waste.

These figures come from interested parties and must be flagged as such. The martech landscape count comes from a marketing-technology commentator who is himself a vendor executive, and the enterprise SaaS figures and the waste estimates come from a company that sells SaaS-management software and therefore has an interest in the perception that SaaS is sprawling and wasteful. The specific waste figures, in particular, should be treated as interested estimates rather than established facts, and it is worth noting that even within the SaaS-management discourse there is skepticism that the waste is as large as claimed, on the grounds that enterprise licensing deals give whole teams access to tools regardless of individual usage, so that apparently unused licenses may not represent waste in the way the headline figures suggest. The direction of the phenomenon, toward proliferation and some degree of redundancy, is not in dispute, but the magnitude of the waste is contested and comes from parties who benefit from its appearing large.

The genuine lesson, net of the interested framing, is that the composable philosophy applied without portfolio discipline produces sprawl, and sprawl has real costs even if the specific waste figures are inflated. An estate of hundreds of applications, accumulated through many local best-of-breed decisions, carries redundancy that duplicates spend, integration complexity that grows with the number of tools, security surface that expands with each application, and management burden that no one fully owns. Application rationalization, the disciplined reduction of the estate by consolidating overlapping tools and eliminating unused ones, has become a recognized response, and it is essentially the portfolio-level version of the discipline this article recommends: composing selectively and consolidating where composition is not worth its cost. The sprawl is the composability bill written across the whole software estate, and rationalization is the enterprise-scale version of paying it down, undertaken with appropriate skepticism about the self-interested figures that vendors of rationalization tools attach to it.

The rationalization discipline that answers sprawl has a characteristic difficulty that explains why sprawl persists despite widespread recognition of the problem, which is that rationalization is organizationally harder than accumulation. Adding a tool is a decision one function can make to serve its own needs, requiring no coordination and imposing its costs diffusely on the portfolio, whereas removing a tool requires coordinating across everyone who uses it, migrating their workflows, and overcoming their resistance to losing a tool they have adapted to. The asymmetry means that the forces favoring accumulation are strong and local while the forces favoring rationalization are weak and diffuse, so that in the absence of deliberate governance the estate grows monotonically, each addition easy and each removal hard, until the sprawl becomes acute enough to force a rationalization initiative that temporarily reduces the estate before it begins growing again.

Sustained control of sprawl therefore requires making rationalization a continuous governed discipline rather than a periodic crisis response, which means giving some party ongoing responsibility and authority for the estate as a whole, with the mandate to evaluate additions against the portfolio and to drive removals of redundant and unused tools. This is the portfolio-governance function that the later section develops, and its application to sprawl is to counterbalance the local, continuous pressure to add with a central, continuous discipline to rationalize, so that the estate is actively managed toward the minimum set of tools that meets the enterprise's needs rather than allowed to accumulate toward the maximum that local decisions produce. Without such a continuous counterweight, rationalization is a recurring project that never sticks, because the accumulation pressure that produced the sprawl resumes the moment the project ends, and the estate sprawls back to where it was. The discipline must be permanent because the pressure it counters is permanent, and an enterprise serious about controlling the composability bill at the estate level must institutionalize rationalization rather than treating it as an occasional cleanup.

Section 10: The vendor claims, and who is selling what

The composability debate is unusually crowded with interested parties on all sides, and a buyer navigating it must understand who is selling what, because almost every claim in the debate comes from someone with a commercial stake in the buyer's conclusion. Mapping the interests is essential to weighing the claims.

On the pro-composable side are the best-of-breed vendors, who sell the individual components of a composed stack and therefore benefit from the philosophy that an enterprise should assemble the best tool for each capability. Their claims about the agility and advantage of composability are genuine arguments but interested ones, because their business depends on enterprises choosing to compose rather than to buy a suite. The industry alliance that promotes the composable approach is funded by these vendors and advances their collective interest. And the analysts who championed composability, while not vendors, participate in the ecosystem and lent it authority. The pro-composable claims should be read as coming from parties who profit when enterprises compose.

On the pro-consolidation side are the suite vendors, who sell integrated platforms and benefit from the philosophy that an enterprise should consolidate onto fewer, more integrated tools, and the platform vendors repositioning to capture the consolidation swing. Their claims about the hidden costs and complexity of composition are, again, genuine arguments but interested ones, because their business depends on enterprises choosing to consolidate. The competitor whose critique of the MACH mirage was cited earlier is exactly such a party, making a substantive critique from a commercially-interested position. And the SaaS-management and rationalization vendors benefit from the perception that sprawl is rampant and wasteful, which supports demand for their tools. The pro-consolidation claims should be read as coming from parties who profit when enterprises consolidate.

The buyer's task, given that almost every claim is interested, is to weigh the arguments on their merits rather than to trust the sources, and to recognize that the truth is not at either interested extreme but in the per-capability judgment that neither set of vendors is incentivized to recommend. The best-of-breed vendors will not tell a buyer to consolidate the commodity capabilities, and the suite vendors will not tell a buyer to compose the differentiating ones, because each vendor's interest is served by the buyer choosing that vendor's approach across the board. The balanced position, composing selectively and consolidating selectively, serves the buyer but not any single vendor, which is precisely why the buyer must arrive at it independently rather than adopting the recommendation of any interested party. This publication has no stake in either outcome, and its counsel is the balanced one that the interested parties will not offer: read every claim in the composability debate as coming from someone selling something, weigh the arguments rather than the sources, and make the per-capability judgment that maximizes the enterprise's value rather than any vendor's revenue.

Section 11: The fairness case: composability is not the enemy

This article has cataloged the composability bill in detail, and fairness requires an equally serious statement of composability's genuine value, because a reader who concludes that composability is a mistake and that the suite is always the answer would be embracing the opposite extreme, which is as wrong as the one this article criticizes.

Composability is materially valuable at the points of real differentiation, and this is the core of the fairness case. For a capability that differentiates the enterprise from its competitors, where being able to select the best tool and to evolve rapidly creates real competitive advantage, the agility of composition is worth its cost, and accepting a suite's compromises would sacrifice the differentiation that matters. An enterprise whose competitive edge depends on a particular capability should compose that capability, choosing the best components and retaining the ability to evolve them, because there the best-of-breed advantage and the agility are decisive, and the bill, while real, is justified by the competitive value. The critique of composability is not that it lacks value but that its value is concentrated at the points of differentiation and is frequently paid for across capabilities where it does not apply.

Monoliths have real costs too, and the fairness case must acknowledge them, because the suite is not a cost-free alternative. A monolithic suite carries genuine lock-in, committing the enterprise to a single vendor's roadmap, pricing, and pace of change, with the switching costs that this article's companion analyses of lock-in describe. It carries the compromise of accepting one vendor's version of every capability, including the ones where a better alternative exists. And it carries an agility cost, because change frequently requires the vendor's cooperation and proceeds at the vendor's pace. These are real disadvantages, and an enterprise that consolidates onto a suite to escape the composability bill takes on the suite's lock-in and compromise in exchange, which may or may not be a good trade depending on the capability. The choice between composition and consolidation is a choice between two sets of real costs, not between a costly option and a free one.

The honest synthesis, which the constructive sections develop, is that the right architecture is neither composed everything nor consolidated everything but a considered mix, composing at the points of differentiation where the agility is worth the bill, and consolidating the commodity capabilities where the suite's simplicity outweighs its compromises. A blanket rule in either direction is wrong: composing everything pays the composability bill across capabilities that do not need the agility, and consolidating everything accepts the suite's lock-in and compromise across capabilities that would benefit from composition. The skill is the per-capability judgment, and the fairness case for composability is that it is the right answer for some capabilities, just as the fairness case for the suite is that it is the right answer for others. An enterprise that understands both sets of costs and matches the architecture to the capability will outperform one that follows either fashion to its extreme, and this article's critique of the composability bill is in service of that balanced judgment, not of a retreat to the suite.

A further point in fairness concerns the maturity of the tooling and practices that support composition, which have improved substantially and which mitigate, though they do not eliminate, the bill this article describes. The integration platforms, API-management tools, and orchestration technologies that connect composed components are far more capable than they were when the composable movement began, and they reduce the cost of building and maintaining the connective layer, though they do not reduce it to zero and they add their own licensing and operational cost. Similarly, the practices for managing composed architectures, the platform-engineering disciplines, the internal developer platforms, the observability tooling, have matured, and an organization that applies them competently pays a smaller composability bill than one that does not. The bill is real, but it is not fixed; it depends on the maturity of the organization's integration tooling and platform practices, and a sophisticated organization with strong platform engineering can compose at a lower cost than the raw critique might suggest.

This maturity point cuts both ways, however, and it should not be taken as a reason to dismiss the bill. The organizations that can compose cheaply, because they have strong platform engineering and mature integration tooling, are a minority, and the majority that compose without those capabilities pay the full bill this article describes, because the tooling and practices that mitigate the bill are themselves a capability that must be built and that many organizations lack. The composable movement's error was frequently to sell composition as accessible to any organization, when in truth composing well requires a platform-engineering maturity that is scarce, and organizations that composed without it got the costs without the mitigations. The fair statement is that composition's bill is smaller for organizations with mature platform capabilities and larger for those without, that most organizations are in the latter category, and that an honest assessment of whether to compose must include an honest assessment of whether the organization has the platform maturity to compose cheaply, because composing without it is paying the full, unmitigated bill.

Section 12: Compose at differentiation, consolidate commodities

The governing principle for architectural decisions follows from the full accounting of costs on both sides, and it can be stated as a rule that resists the pendulum: compose at the points of genuine differentiation, and consolidate the commodity capabilities. Figure 8 sets out the framework.

The framework rests on two dimensions: how much a capability differentiates the enterprise, and how much strategic value it carries. A capability that is both highly differentiating and strategically valuable, where being best matters and where the capability is central to the enterprise's competitive position, is a capability to compose, because there the agility and best-of-breed advantage of composition are worth the bill, and accepting a suite's compromise would sacrifice differentiation that matters. A capability that is commodity, where any adequate implementation suffices and no competitive advantage flows from being best, is a capability to consolidate onto a suite, because there the agility of composition buys nothing the enterprise needs and the suite's simplicity and single accountability are worth more than the flexibility.

The framework's value is that it replaces an ideological choice with a per-capability judgment, and in doing so it dissolves the false dichotomy that the pendulum swings between. The question is not whether the enterprise should be composed or consolidated as a whole, which is the wrong question because different capabilities warrant different answers, but which specific capabilities warrant composition and which warrant consolidation. An enterprise might compose the handful of capabilities that truly differentiate it, accepting the bill for those because the differentiation justifies it, while consolidating the many commodity capabilities onto suites, avoiding the bill where the agility would buy nothing. This mixed architecture is neither composed nor consolidated as a whole; it is composed where composition pays and consolidated where it does not, and it reflects the reality that the right answer varies by capability.

Applying the framework requires the enterprise to assess its capabilities rigorously on the two dimensions, which is harder than it sounds because every function tends to believe its capability is differentiating and strategic, and the discipline is to distinguish the few capabilities that truly differentiate the enterprise from the many that are commodity however much their owners value them. A capability is differentiating only if being best at it creates competitive advantage the enterprise can actually capture; a capability is strategic only if it is central to the enterprise's position rather than merely important to its operations. Most capabilities, rigorously assessed, are commodity: necessary but not differentiating, better bought as an adequate suite component than composed at the cost of the bill. The framework directs composition to the few capabilities that pass both tests and consolidation to the many that do not, and its honest application, resisting the universal tendency to over-rate one's own capabilities as differentiating, is what produces an architecture that composes where it counts and consolidates where it does not, paying the composability bill only where the differentiation justifies it.

Section 13: A portfolio protocol, and a scoring rubric

The principles above combine into a protocol for managing an enterprise architecture as a portfolio, and a rubric for assessing whether a proposed composition is justified or is signing up for an unbudgeted bill.

The protocol runs as follows. Assess each capability on differentiation and strategic value, and compose only those that are truly both. For any capability proposed for composition, build the full bill-of-materials, including the connective layer as permanent opex, vendor management, specialized talent, drift, and security surface, and compare it rigorously to the suite alternative on total cost of ownership rather than license fees. Designate an owner of the whole for any composed capability, a team accountable for the end-to-end experience and the seams. Maintain a bill-of-materials for the architecture, documenting every component, its owner, its cost, and its dependencies. And rationalize continuously, auditing for redundant and unused functionality and consolidating it, so the estate does not sprawl.

A scoring rubric

The dimensions below distinguish a justified composition from an unbudgeted bill.

A composition scoring in the left column is justified: the capability warrants it, the full cost is understood, the seams are owned, and the estate is managed. A composition scoring in the right column is an unbudgeted bill: a commodity capability composed by habit, costed on license fees, with an unowned connective layer and seams, in a sprawling estate. The rubric does not make composition wrong, which for differentiating capabilities it is not. It ensures that the enterprise composes deliberately, where composition pays, with the full bill understood and provided for, rather than composing by default and discovering the bill later

Section 14: Governing the architecture as a portfolio

The deepest remedy for the composability bill is to govern the enterprise architecture as a managed portfolio rather than as an accumulation of independent decisions, because the bill arises precisely from the absence of portfolio governance, from local best-of-breed choices accumulating into an estate that no one designed or owns. Portfolio governance is the organizational discipline that keeps the bill in check.

Portfolio governance means, first, that architectural decisions are made against a view of the whole rather than locally. When a function proposes to compose a capability or add a tool, the decision is evaluated not only on that function's needs but on its effect on the portfolio: whether it duplicates existing functionality, whether it adds to the vendor-management and integration burden, whether the capability is differentiating enough to warrant composition, and whether the full bill is justified. This is a governance function, a body or process with the authority to evaluate architectural additions against the portfolio and to say no to compositions that do not pass the per-capability test, and it is precisely what most enterprises lack when their estates sprawl, because in the absence of such governance each local decision is made on local grounds and the portfolio effects accumulate unmanaged.

Portfolio governance means, second, that someone owns the architecture as a whole, with accountability for its coherence, its cost, and its evolution, in the same way that a portfolio manager owns a portfolio of investments. This owner maintains the bill-of-materials, tracks the total cost of ownership, identifies redundancy and drives rationalization, and ensures that the composed capabilities have their owners of the whole and their connective layers provided for. Without such an owner, the architecture is an orphan, the sum of decisions no one is accountable for, and it decays into sprawl and unowned seams. With such an owner, the architecture is a managed asset whose composition reflects deliberate choices and whose bill is understood and controlled. The owner of the architecture is the portfolio-level counterpart to the owner of the whole for each composed capability, and both are the organizational mechanisms that keep the composability bill from accumulating unmanaged.

Portfolio governance means, third, that the architecture is periodically reviewed and rationalized as a whole, rather than only added to. Estates sprawl because addition is easy and subtraction is hard: each new tool is added by whoever wants it, and no one is responsible for removing the redundant or unused ones, so the estate grows monotonically. Portfolio governance institutes the discipline of periodic review, examining the whole estate for redundancy, unused licenses, and compositions that no longer justify their bill, and consolidating or eliminating accordingly. This is application rationalization as an ongoing discipline rather than a one-time project, and it is what keeps the estate from sprawling back after each rationalization. An enterprise that governs its architecture as a portfolio, evaluating additions against the whole, owning the whole, and rationalizing the whole periodically, controls the composability bill; an enterprise that treats architecture as an accumulation of local decisions pays the bill in full, in sprawl, redundancy, unowned seams, and a total cost of ownership that no one is tracking. The governance is the difference between an architecture that is managed and one that merely accretes, and it is the organizational foundation on which the per-capability discipline of composing at differentiation and consolidating commodities actually rests.

Section 15: Conclusion: fund the foundation

The reckoning described in this article is not a prediction. It is already happening, in the form of artificial intelligence pilots that produce no value, planning systems that were supposed to transform performance and did not, and agents that make confident decisions on inputs that nobody has verified. The organizations experiencing these failures overwhelmingly attribute them to the technology, and in most cases they are wrong. The technology arrived working. It was deployed onto a foundation of records that were accurate two-thirds of the time, inconsistent across systems, missing the fields it needed, and owned by nobody, and it did exactly what such a system will always do, which is to compute a precise answer to a question the data could not support.

The correction is not glamorous and it is not fast. It consists of naming the twenty fields that matter, measuring them against physical reality, publishing the result where the people who create the data can see it, putting validation at the point of entry, deciding which system is authoritative for each master entity, and giving every critical element an owner with a name. That is the whole program. It requires no new technology, it can begin next week, and it will produce, within a year, a measurable improvement in forecast accuracy and inventory availability that the organization can bank before it spends anything at all on artificial intelligence.

The final argument is one of sequence, and it is the one worth taking to the board. The data foundation is not a prerequisite that delays the artificial intelligence program. It is the artificial intelligence program, or at least the first year of it, because there is no version of an automated supply chain that works on data that is right two-thirds of the time, and every dollar spent on a model that will consume such data is a dollar spent on a confident error. The organizations that will get value from this technology are not the ones that adopted it first. They are the ones that could feed it. That is a less exciting sentence than the vendors are offering, and it is the one the evidence supports.

It is worth ending on the note that this article is, despite its severity, an optimistic one. The problem it describes is entirely solvable, requires no technology that does not already exist, and the interventions that solve it are among the cheapest available to any technology organization. A validation rule at the point of entry costs a developer a day. A physical count of a warehouse costs a morning. A decision about which system is master for the product record costs an executive a difficult conversation. None of this is a research problem or a capital project. What it requires is that somebody with standing decide that the foundation matters more than the next feature, and then hold that position through the eighteen months in which the work is invisible. That is a leadership problem, and leadership problems, unlike technical ones, can be solved by deciding to solve them.

The question to carry from this article into the next steering committee is one sentence long and will not be comfortable to ask. What is our actual inventory accuracy, measured against a physical count taken this quarter, and does anyone in this room know the number. In most organizations nobody will know, which is itself the finding, and the silence that follows the question is the beginning of the program. The organizations that will succeed with automation over the next five years are not the ones that moved earliest or spent most. They are the ones that could answer that question, and that did something about the answer.

Section 16: Methodology, caveats, and sources

Methodology

• This article synthesizes analyst commentary on composable business and MACH, vendor and competitor positions, agency-reported migration cases, and SaaS-management and martech-landscape data, current to mid-2026. Supply Chain Research is independent and accepts no payment from the vendors, alliances, or agencies discussed.
• The composability debate is unusually crowded with interested parties on all sides. Each source's commercial interest is identified, and conclusions rest on the consistency of the pattern across differing interests rather than on any single source.

Caveats

• The re-consolidation cases are drawn largely from interested sources: a commerce-platform competitor, MACH vendors conceding limitations, and agencies that migrate brands. Each is flagged. The pattern is credible because it is consistent across sources with differing interests, not because any source is neutral.
• The SaaS-sprawl and waste figures come from a martech commentator who is a vendor executive and from a SaaS-management vendor, both interested. The direction, toward proliferation, is not in dispute; the magnitude of the waste is contested, and even within the field there is skepticism that team-licensing makes apparently unused licenses less wasteful than claimed.
• The analyst predictions cited are forecasts, not measured outcomes, and are presented as the high-water mark of the hype and its later reversal, not as established facts about what occurred.
• Figures 3 and 7 use illustrative relative magnitudes and mixed-source figures to convey a structure and a direction, and are labelled as such; they are not measured benchmarks from a single dataset.
• The framework in Figure 8 is a decision aid, not a formula. Assessing differentiation and strategic value requires judgment, and the discipline is to resist every function's tendency to over-rate its own capability as differentiating.

Sources

1. RetailTechnology Innovation Hub. VTEXco-CEO on the 'MACH mirage' and the suspension of MACH Alliancesupport (flag: competitor).
2. SeriesEight. Shopifyvs headless: what brands really need to know (flag: migratingagency).
3. Tante-E.Headlesson Shopify: why we advise against it (flag: agency).
4. AskPhill. Shopifyheadless commerce: when it is worth it and what it costs (flag:agency).
5. commercetools.Becomingcomposable: a Gartner Trend Insight framing (flag: composablevendor).
6. Zylo.SaaSManagement Index: average apps per enterprise and license waste(flag: SaaS-management vendor).
7. Mi3.Onthe Zylo SaaS-waste figures and the skepticism about team licensing(flag: interested data).
8. Zylo.Thegreat SaaS rationalization: consolidation as the counter-trend (flag:interested).

Additional context drawn from analyst commentary on composable business and MACH, from martech-landscape tracking, and from vendor and agency positions across the debate. Every source's commercial interest is identified. This article is analysis, not architectural or procurement advice, and its conclusions should be validated against your own circumstances before any decision.

Supply Chain Research is an independent, vendor-neutral research platform for supply chain and technology leaders. We accept no payment from the vendors, consultancies, or firms discussed. This article is analysis, not legal, procurement, or investment advice, and its conclusions should be validated against your own circumstances before any decision.