Responding quickly to changes – whether positive or negative – is a business value that is crucial to the success of companies. In practice, companies regularly find this difficult. Almost everything in today's marketplaces around the world changes so dynamically that it's hard to keep up. One obstacle are information structures and architectures that have grown over time in the company.

The Monolith

These monolithic software systems and architectures are tightly coupled overall structures and tend to become increasingly "hardened" as the application evolves. This makes it difficult to isolate individual services in order to change them or to compose new functions with new business value. Due to this close interlocking, changes always have direct and indirect effects on the entire monolith. The latest software technologies and the use of cloud services and architectures now offer a much more flexible design, which can be of existential importance for companies in the long term. The essence of composable business or composable commerce is a completely opposite and granular approach ("botton-up" instead of "top-down"). If all processes in the company follow this approach, we speak of the composable enterprise model - but more on that later. This article sheds light on the big picture behind this new approach while providing suggestions to: - to recognize one's own monolithic structures (in terms of technology and organizational form). - break up monolithic structures piece by piece - to design its IT for the future with new approaches more sustainable, efficient and future-proof

The grand vision behind Composable Business is that IT can be re-orchestrated and optimized with ease.

First, the head needs some “composable thinking”

Status Quo: Brick by Brick building further Monoliths?

Realize that you are building your monolith:

The traditional model of a typical enterprise platform is tightly coupled and woven together as a inseparable entity. Systems are interdependent and form the "big picture". Even a "best of breed" of "smaller monoliths" doesn't improve anything. For composable business, it is important to dissolve the monolith in the medium term and to design solutions in a more granular way. New IT projects in the direction of “composable” are the future.

Monolith against Business

A monolith consists of dependencies that run through all architecture layers. A best of breed approach is difficult to implement. Overall, this setup complicates maintainability, the company's responsiveness and lowers ROI. "Moving the whole monolith" with all changes to this construct is not sustainable.

Monolith against Customer

Individual customer channels are difficult to implement and the customer journey and customer experience suffers throughout. Customer insights and consent management are difficult to achieve across channels. In contrast, Composable Thinking is a new way of thinking. There are fundamental design principles that must be adhered to on the way to composable business. Therefore, it is recommended that any new IT project follows these principles.

Benefits of Composable Thinking

1. Speed through experience

Risk avoidance, long project times and project stability is the traditional logic. Nowadays, companies make better use of the risk and experience in short, flexible projects and thus receive modular IT products for a composable enterprise architecture.

2. Agility through modularity

Modularization and "interface contracts" (design by contract) help with the agile development of individual components without affecting other components. Dependencies in the implementation of changes decrease and agility increases.

3. Better leadership through orchestration

Top-down design of the technologies used and common paradigms enable better integration, control and make complex structures manageable and safer.

4. Resilience through autonomy

Construction of encapsulated, autonomous business objects that communicate with each other, but run autonomously and independently. Additional automations reduce error rates in administration and maintain autonomously.

This applies to technology as well as to people and organizations.

Composable Technology and Composable Architecture

These new ways of thinking and principles call for suitable technology to make this "thinking" a reality. Many software manufacturers have already recognized this and support, for example, an API-first approach and headless support in newer versions.

Composable architectures can be built with the right tools, open ecosystems, low-code platforms, cloud native and event-driven architecture. The so-called MACH architecture, which basically summarizes the interaction of the necessary requirements, has become popular.

MACH architecture as a platform for composable business/commerce

MACH architectures are digital ecosystems that are developed with regard to automation, modularity and scalability. These architectures are the core technology of composable enterprise operating models.

M.A.C.H. is an acronym and stands for a modern software and platform architecture made up of microservices, the API-first principle, cloud-native and headless frontend technologies for commerce and CMS or application user interfaces.

What is special about this architecture is that there are principles such as the consistent separation of the front end and backend used by APIs (Application Programming Interface, programming interfaces) and their data. The technologies used correspond to the API-first concept and can be controlled completely via interfaces without a user interface. Cloud-native technologies are the basis for merging in the cloud or multiclouds for the automated orchestration of applications, data resources and processes. The interfaces to the respective user are detached from the backend, tailored to the user and his needs, which are specially designed and designed for the respective requirements.

In order to control business processes or operate applications, the front ends of the software manufacturers (back offices for administrators) are certainly available, but with the appropriate front end technology, individual cockpits or dashboards can also be created.

To illustrate: Within a MACH architecture, e-commerce with all its functions, front and backend, data, design, content, products and processes that make up your capabilities, comes as no more than a single monolithically forged and configured piece software therefore. Because this is difficult to manage in the long run and expand procedurally and functionally.

A shop within a MACH architecture thus consists of self-contained applications/microservices and self-contained systems that function independently of dependent structures and processes. It is possible for the user to vary the entire presentation in the front end as desired and to expand it for specific channels. The development and expansion with MAM/DAM and PIM is much more independent of technology restrictions, which has an extremely positive effect on the overall performance of the company.

For example, the data required by the shop is no longer welded to the shop monolith, but is compiled from various sources via API and services. Nevertheless, it is possible that all shop and customer information is used by other systems.

The actual interface and system communication and their design are considered just as detached. In order not to hard-wire functions and information, it is necessary to clarify how, what, when, for what reason and for what purpose is conveyed. The use of a messaging system and standardized and consistently defined communication processes creates the message and event-driven IT architecture that is indispensable for today's digitization requirements.

If a company not only adjusts its shop, but all its business processes to MACH technology, a business becomes highly scalable and communicative while remaining performant and flexible. Because modular. Roughly sketched, this is what the Composable Enterprise Model looks like – an important and evolutionary step in digitization in the company.

Winds of Change: The Composable Enterprise Model

Basically, you transform - technologically speaking - 20-year-old processes and IT systems into granular, encapsulated and reusable business capabilities based on a common, uniform communication and information architecture.

The paradigm is: In the past, due to technology and communication, monolithic information architectures were built up, which ultimately dictated the business capability, the processes and the operating model of the company and often missed the actual goals. However, it is nobody's fault. For one thing, the technology wasn't as advanced as it is today. On the other hand, companies are forced to design these systems in such a way that they correspond to their own internal communication structures. See Conway's Law

For example, companies develop websites that correspond to their own internal structure and do not primarily satisfy the information needs of users for which these websites were originally intended.

With a composable enterprise architecture, you get rid of this technology corset and at the same time regain the necessary agility to focus on customer needs. With a company-wide communication standard, you consistently regulate and standardize the communication between the interfaces, people and systems involved. Dealing with errors in a message-driven IT architecture and with their interpersonal dependencies are important building blocks for a successful change.

They define and describe:

  • all your business skills (key factors of success: status quo and in the future?),
  • their operational and business models (how they work, how they generate their profits),
  • Your communication and information skills
  • and all business objects, people and processes derived from it (e.g. account management, HR management, order management and procurement processes, credit assessments, resources and data references, analyses, etc.)

and convert these technologically into encapsulated, well-composed, reusable software components for individual business processes and their users.

When describing your skills, focus on information and people and not primarily on technology and the processes that arise anyway. Processes can be reused, scaled, modified and exchanged at will without changes – as in monolithic architectures – having a direct impact on adjacent systems, communication or the entire business architecture.

It goes without saying that such far-reaching changes are not implemented in one project. Nevertheless, this way of thinking is crucial for success and implementing new projects in key areas as MACH core services is the better strategic decision in the medium term. That means: Become aware of your business and your skills. Form teams and departments that live and are responsible for this vision. This also includes the corresponding affinity for technology. Most projects and companies fail because of this.

The goal is to view the full range of business processes, organizations and interrelationships, functions and technologies as a set of reusable process components that are configured as needed. No lengthy implementation projects or IT products are delivered as microservices, but composed applications that fit into an overall architecture as "entrepreneurial ability" - the so-called packaged business capabilities.


If it used to be: "Never change a running system", it is now being varied, implemented, expanded and reconnected. The core technologies are MACH, Multi-Cloud and Information as a Service in the Cloud (Cloud IaaS).

With a MACH-based architecture, companies are well prepared for future challenges and constant change.

This is accompanied by extensive change management and initially increased costs in the transformation phase. This is part of the risk, which is further minimized with trustworthy system integrators for advice, analysis and conception of architectures as well as the right approach.

Because companies rarely start on a green field, the step-by-step conversion through hybrid system worlds is a good way to make the transition. Many manufacturers are already adapting their software to make this cloud-native. Headless and API-First are the most important keywords for the new software evaluations.

Experienced service providers and software integrators provide valuable assistance on how to get started with Composable Business. Companies are rewarded with a flexible, individual and easily adaptable ecosystem for their unique business, which meets modern trading requirements.

Our offer to you:

With our expertise from many customer projects, we help you to convert your business to composable technology in the long term. communicode has extensive experience with this technology and related aspects in order to make your entry goal-oriented and gradually raise key areas of your business to a modern business platform architecture

Frequently Asked Questions about Microservices, M.A.C.H. and Composable

  • What is a monolithic architecture?
    Traditionally, in the past, software systems have been designed and operated as a single structure and unit to handle interrelated tasks. Functions and APIs to extension modules and other systems extend this autonomous entity and increase the dependencies within monolithic systems
  • What is a microservice?
    Microservices are a cloud native architecture solution in software development. Software components are logically divided into microservices and can be adapted, changed, scaled or developed individually without affecting the rest of the architecture.
  • What does API-First mean?
    In order to use functions within a software, a graphical UI is usually required. However, applications that offer an API-First approach can be addressed and used entirely via interfaces. Various headless frontends as a separate build or as a buy solution can be connected to these APIs so that functions can be used extremely flexibly in frontend applications and other systems.
  • What does Cloud Native mean?
    Cloud native is software in the form of microservices that is predestined for operation in the cloud. These applications are designed in such a way that they can scale themselves automatically without being dependent on servers, their computing power, networks or storage.
  • What does MACH architecture or MACH technology mean?
    The acronym MACH stands for a modern software and platform architecture composed of microservices, the API-first principle, cloud-native and headless frontend technologies for commerce and CMS or application user interfaces. MACH architectures are digital ecosystems that are developed with regard to automation, modularity and scalability.
  • What is a headless architecture?
    In a headless architecture, all business logic and functionality is packaged as a microservice by dedicated API-first applications in a set of APIs that are operated and exposed by the specialized backends. Any frontend channel can leverage these APIs to provide a customer experience desired for that channel.
  • What does headless commerce mean?
    Headless commerce is an e-business concept in which front and backend technologies are no longer coupled as a unit/monolith. Companies can thus build agile, specialized e-commerce solutions that are more flexible, faster, more sustainable and cost-sensitive in the long term, optimize them and align them with constantly changing customer and market requirements.
  • What are the advantages of a MACH architecture?
    Despite extensive change management and initial additional costs, a MACH architecture offers a significant competitive advantage in the medium and long term, since this technology is the core of composable enterprise models and enables rapid and flexible development and scaling of technical ecosystems. According to Gardner, savings of up to 80% compared to traditional IT architectures are possible.
  • What does Composable Commerce/Business mean?
    Composable Commerce means businesses can buy value-added, pre-packaged solutions and integrations as pre-configured applications and easily integrate them into their commerce experience. The prerequisite for this is composable thinking, a composable architecture and composable technologies
  • What is a Self Contained System (SCS)?
    In a self-contained systems architecture, entire functions and processes are packed into several smaller web applications. Communication between them is optimally asynchronous and business code is not shared with other SCS to ensure independence. SCS often get their own UI to provide the functions to users and can also have their own service API.
  • What is the difference between Microservices and Self Contained Systems?
    Microservices can, for example, communicate with each other. With SCS, Self Contained Systems, this is conceptually not desired. Conceptually, entire services and processes with all data and functions are mapped in SCS and can have their own UI. A microservice can only have one single task, for which no user interface is required. A system contains more microservice components than SCS components.
  • What does Packaged Business Capabilities mean?
    Packaged Business Capabilities (PBCs) is a term coined by Gardner and describes software components that represent clearly defined business capabilities and their processes and can be used by a user as such to carry out corresponding tasks.