Skip to main content

← All writing

The move from monolithic to composable architectures

The move from monolithic to composable architectures

Success in business can be attributed to many factors, notably team talent and efficacy of products or services. What also counts in this digital age are immersive and performant online experiences. Realistically, delivering engaging experiences is a never-ending undertaking. To avoid lagging behind rivals, brands must do that time and again in all their interactions with consumers.

Can you adapt and iterate as rapidly as necessary? Can you quickly respond to current trends and launch digital experiences without tech support? When it comes to digital capabilities and speed to market, technology makes all the difference. This post explains why the industry is moving from monolithic to composable architectures and how those two architectures can actually work together.

##What are monolithic applications?

Built as a single unit, monolithic applications (aka monolithic architectures) are all-in-one, self-contained suites with robust features. Known as legacy systems, monolithic applications occupy a long-standing place in today’s makeup of businesses as the easy way to acquire digital capabilities. You go through one purchase for all your business needs and sign a contract with one solution provider, who would make it all happen and support you along the way.

Such a mono approach might not be the best for the long haul, however. In a free-market economy, monopolies are generally frowned upon because of the guardrails put up by those dominant players, who would enforce rules and regulations to stifle or eliminate competition altogether. What’s more, monopolies have no incentives for innovation or improvements in efficiency.

That’s not a direct comparison to monolithic solutions in tech per se since competition does exist among tech solution providers. Rather, a brief assessment of monopolies is helpful context for why stand-alone architectures aren’t ideal for businesses. If one vendor has all the say about the ways your tech stack is used and adapted, you are limited in many ways.

Why are monolithic applications not the way forward?

A pro-con analysis shows real (or at least perceived) benefits in relying on a monolithic architecture for your tech stack. If your IT team is well versed in the vendor along with its code and operating system, an established ease of use exists. Furthermore, it feels simple to keep and manage everything in one place and to have, theoretically, one source of truth, with all the tools housed together under the purview of one provider. Not to mention that you have one all-knowing point of contact or support team to call on in case of issues.

Nonetheless, given the future of business and the digital experiences consumers demand, the cons of monolithic applications far outweigh the pros in three key areas:

  • Customization. Limited is the ability to tailor monolithic applications to meet business needs. Also, even though those applications offer wide-reaching features, you might not ever use some of the features. And you’re at the whims of the monolith’s technology roadmap for innovation. For example, something you need to meet customer needs might not be available until the application’s next software update, potentially months away. In addition, in contrast to today’s fast market changes, upgrades can be time-consuming and slow with a need for developers to make changes or adaptations. With those modifications come complexities, third-party add-ons, or new applications that developers must painstakingly build themselves.
  • Agility. Trends change and new opportunities emerge more rapidly than monolithic applications can keep up. Adaptability becomes a struggle, especially if you’re locked into the suite on contract.
  • Scalability. Businesses that aspire to be fast-moving and competitive are hindered by monolithic technologies that are difficult to scale. Accordingly, growth is hampered because of the slow and heavy lift for developers to morph one monolithic architecture into an all-things-for-all-people stack.

Another hurdle businesses face is adapting a monolithic application to be composable or as a “MACH monolith.” Rather than replatforming or ditching an established monolithic architecture to build a new microservices-centric one, brands apply API-first and composable solutions to an existing framework by integrating a host of composable products. Doing so could seriously muddy the waters, however, creating a beast of an architecture that’s not composable, sustainable, or agile.

How can monoliths and composable work together?

Legacy monolithic architectures can, in fact, work with composable applications through digital experience composition platform (DXCP), which acts as composable’s opinionless foundation by doing the following:

  • Offer the prebuilt system integrations and tools business users need, lightening the burden of innovation through new features.

  • Enable teams to merge their legacy platform with a composable approach, orchestrating best-of-need tools and offering a user-friendly interface for developers and practitioners alike.

How does DXCP help make composable mainstream?

Without doubt, monolithic architectures are no longer ideal for brands that are focused on creating digital experiences that drive impact and conversions. Composable architectures give control of the experience-creation process to the brands responsible for the end results, instead of one tech vendor.

Despite the promise of future-ready composable stacks, building them can be a slow and expensive process, with weeks of custom glue code needed to integrate the multiple services. They are often also incredibly frustrating for marketing teams, content writers, graphic designers, and other business users, as previously simple tasks require multiple tools and developer support.

This is where DXCP and companies like Uniform enter the picture. With rapid integration tools that dramatically speed system build and maintenance and powerful no-code interfaces for marketers and other business users to create engrossing experiences in a single, integrated environment using every tool they need.

On this page
Sep 4, 20267 min read

Building MCP Profile Hub part 2, one MCP server is the wrong abstraction

This article argues that a single, monolithic MCP server per platform is the wrong abstraction, especially for complex systems like Contentstack. Instead, it introduces managed profiles as the right unit of configuration, aligned to jobs, teams, or access boundaries rather than product catalogs. Each managed profile bundles a curated set of tools, Automations, and agents, enriched with account context, while still respecting individual user identities and permissions. Profiles can only narrow what a user can do, never expand their underlying platform permissions. This makes configurations easier to reason about, review, audit, and replicate across environments, and offers a scalable pattern for enterprise platforms with many roles and capabilities.

  • Composable architecture
  • AI engineering
  • API design
Aug 31, 20269 min read

Building MCP Profile Hub, part 1: Stop making the agent ask

Introducing MCP Profile Hub. I explain why enriching tool definitions with tenant-specific context dramatically improves agent performance. Instead of exposing generic CMS tools that force models to discover content types, environments, locales, and branches through multiple lookup calls, Profile Hub injects real account data directly into JSON Schemas as enums, defaults, and descriptions. This reduces tool calls, latency, and reasoning tokens while avoiding misleading examples and invalid defaults. The piece also covers the production engineering behind enrichment, how Automations and Agent OS agents are exposed as high-level deterministic tools, and why reusable HTTP-based tool definitions let teams run their own MCP runtimes. The core takeaway is that fewer, richer, context-aware tools beat large generic catalogs for real-world agent workflows.

  • Composable architecture
  • AI engineering
  • API design
Aug 24, 20267 min read

Claude Desktop MCP lifecycle is broken

Claude Desktop currently launches duplicate local MCP stdio servers for a single configuration, causing two independent OAuth flows, extra browser tabs, and unnecessary resource usage. The bug is masked once credentials are cached, so it silently persists in production while still spawning two processes every time. This is not an mcp-remote or external service issue but a host-level lifecycle problem, likely caused by overlapping legacy and new MCP managers and poor observability for one of the processes. Workarounds like pre-authenticating with mcp-remote mitigate UX pain but do not fix the duplication. The article argues that open-source tools should not shoulder complex coordination logic just to survive a major desktop app’s sloppy process management.

  • Composable architecture
  • AI engineering
  • Performance