The Composable Enterprise: A Guide
To deliver in 2022, the modern enterprise must become composable. Here’s what it really means.
Gartner predicts that organizations that have adopted a composable approach will outpace competition by 80% in the speed of new feature implementation.
In a 2021 report, Gartner foresaw that by 2023, 30% of new applications will be delivered as packaged business capabilities, up from less than 5% in 2020. Over 75% of small-mids SaaS vendors will use the architecture of packaged business capabilities to beat their competition.
The modern enterprise must lean into the composable transformation and move away from monoliths in order to beat competition:
“An organization that delivers business outcomes and adapts to the pace of business change. It does this through the assembly and combination of packaged business capabilities… application building blocks that have been purchased or developed.” — Gartner
Conway’s law states that an organization’s structure is a mirror of its software. When building monolithic software, the enterprise builds a monolithic organization, which is not efficient enough to compete in the modern market.
To compete, the modern enterprise must become composable. It has to transition its software to composable components and APIs, and its organizational structure to autonomous teams with distributed business responsibilities who can deliver fast and independently.
It should democratize development, with governance and standardization.
An economy of components and APIs will be formed in the organization, made of both internal and external 3rd party software components.
Composability provides more than just speed, efficiency, and the ability to scale. It caters to a better consumer experience with customized journeys, performance, consistency, and constant new features releases.
In this guide, we will review the composable enterprise transformation and provide implementation tools and solutions. We will review the fundamentals and keys to the transformation and how a component-driven software platform (e.g. Bit ) can drive forward enterprise composability.
Recommended read:
1. Autonomous teams and software components
Much like in a car factory, each team owns and delivers a set of components to the production line, where composable software products are assembled and delivered with efficiency, speed, consistency, and scale.
The organization’s structure reflects its software and vice-versa. Therefore composability in the enterprise is twofold: Software and organization alike.
Autonomous teams
In the composable enterprise teams and software alike should be distributed to smaller autonomous components. Domain-expert teams should independently build and deliver product experiences to their market and quickly respond to fast-changing environments to beat the competition.
When certain products require a new feature — who’s better to understand, create, and provide that than the team which competes in that exact market and understands these exact consumers, their pains, and desires? The assigned product team should research, build, and rapidly ship.
This kind of innovation can only be allowed by moving from monoliths to component-driven software. Teams can own scopes of components and iterate on them, shipping small changes multiple times a day. Teams can discover and integrate each other components to create larger products, without losing each team’s autonomy and ability to deliver independently. Technologies such as component-driven platform Bit already make this possible in 2022.
From monoliths to components
“Monolithic application experiences no longer meet the requirements, expectations or preferences of innovative business users and their customers, now that they demand continuous business agility” — Gartner
In the past world of monolithic software, teams would be entangled with each other in the same bloated codebase and wait on the same version. Features would be re-created in each new project, and could not be leveraged to create more products. At scale, delivery became slow, painful, and inconsistent.
Component-driven software means building components and composing them into infinite products in a fast, efficient, scalable, and consistent way. This distributed form of development allows product teams to own well-defined business domains and deliver independently.
Business functions such as “payments” or “search” can be autonomously developed as scopes of components and served to every product in the organization to use without duplications and with managed updates.
The key to transforming from monoliths to components is technology and tooling, then the distribution of business responsibilities. Modularized technologies for modern applications (React, GraphQL, Node.js, Serverless, etc) can be completed with component-driven platforms such as Bit to make the transformation and enjoy component-driven software.
Distributed business responsibilities
Composability allows the organization to distribute ownership of business responsibilities. Much like in any modern industrial factory, teams can own components instead of projects, and serve them to production.
Just like in the Mercedes Benz factory one team owns wheels and another owns engines, in the composable software enterprise, one team can own “Payments” while another can own “Search” or “Design system”. The scopes of responsibility can vary according to each enterprise’s unique business.
Each team owns and delivers a set of components to the production line, where software products are assembled and delivered with efficiency, speed, consistency, and scale.
Thanks to Conway’s law this is made possible only when the software itself can be built in the form of modular and composable components, made available and integrated via a central component-driven platform like Bit.
Rapid delivery
Autonomous teams in the composable enterprise provide rapid delivery that helps the organization satisfy consumers and beat the competition.
When teams are decoupled (or loosely coupled) to each other they can ship to production more often. Component-driven software lets teams break features into smaller releases which can be shipped to production more often.
The domain knowledge of product teams in their respectable markets gives them an advantage that can be leveraged by empowering them to rapidly release without having to dwell in coupling with other teams.
To allow teams to ship independently and more often, it is necessary to decouple them from each other in terms of development — much like Microservices did for the back end. Each team should work in its own codebase, build independently-versioned components, and ship them to production via separate CI/CD pipelines. This workflow is possible using component-driven software platforms like Bit for web development.
Cross-functional fusion teams
In pre-composable enterprises, separation of working classes is often defined by the profession rather than by belonging to a product team. An engineer works in the R&D department and a designer works in a design studio. Each will often work on a single application or on a single specific product.
In the composable enterprise, each team is cross-functional and includes vertical stakeholders from product owners and managers to designers, developers, marketers, and often data analysts — making it autonomous in the ability to plan, build, ship, and measure product components to the market.
A modern platform for the composable enterprise should be inclusive in the sense that they must be developer-first, as code is the end product delivered to consumers (and not design or product specs), but allow other stakeholders to become active contributors in the product creation and release process.
A good example is the ability of non-developers to discover, view, and comment on components on the platform, or the ability to preview and discuss cross-product changes during CI/CD, as provided by tools like Bit.
2. Collaboration and integration
The composable enterprise should not integrate changes to a certain software project, but rather continuously integrate the entire organization.
In the composable enterprise, each team provides components or APIs to the organization’s production line, where it can be used in different products.
This makes integration and collaboration keys in the creation of software products by teams in the composable organization. The organization, therefore, needs a platform to serve as a marketplace for teams to share and discover components, allow consumption and integration, and streamline updates and changes to continuously integrate the entire organization.
Build-time and run-time integrations
Integration of components between teams and applications is taking place in build-time or in run-time.
Each approach has its own pros and cons, often measured in terms of performance, dependency complexity, safety, and developer experience.
A well-balanced platform should cater to both needs, offering build-time integrations via package installations or managed source-code consumption as well as the ability to add components in runtime as needed. This is the case with Bit platform which offers various integration types, build, and runtime.
Read More:
Versioning and Dependencies
The past monolithic tools applied application-level versioning where an entire software project is versioned together. By assigning a version (mainly semantic versioning) to every software component, each team is decoupled during development — no more fighting over the main branch.
Product teams that assign versions to specific components can rapidly release changes, upgrades, rollbacks, and fixes — and deliver them to multiple consuming applications and products in the organization. Thus, accelerating innovation and improving customer experience and satisfaction.
The composable enterprise builds software as a graph of components composed together. A component can be a dependency or be dependent on multiple components, across multiple products and different teams.
Versioned components are composed via dependencies. The organization’s software is represented as a graph of components, a graph of dependencies and dependants, which crosses the borders of teams and projects.
Through dependencies, components are composed with each other to create more complex and case-concrete components and eventually entire applications, removing the integration boundaries imposed by monoliths.
Updates
The composable enterprise should not integrate changes to a certain software project, but rather continuously integrate the entire organization.
As composable software is represented in a graph of components, changes are integrated to components up the dependency graph for every component that has a new version. The component-graph-driven CI/CD builds changes across projects and teams and does not build unchanged code. Each component is standalone tested, complied, and visually previewed if possible.
The overall impact of updates on the organization can be observed and monitored even before any of the changes ever reach production.
The only tool in the world today capable of this is Ripple CI — the first component-driven graph CI/CD — currently in beta on the Bit platform, but already leveraged by fortune-100 enterprises in the beta program.
Discoverability and marketplace
The composable enterprise must provide discoverability to all software components and APIs offered within its ecosystem. A central marketplace should be the foundation of a shared component economy.
The component searching and evaluation process must therefore be as quick and accurate as possible even at thousands of components and builders.
The discoverability experience should make it easy and simple to find and evaluate components, understand their context (e.g. framework, dependencies, API), and quickly integrate them into any project.
Documentation is therefore a key aspect and should be automatically generated and as flexible and customizable as possible.
In the case of UI-level components and product experiences, a visual discovery experience should be provided to all product builders so that not only developers can have access to the components available.
Democratization and non-developers
Gartner recommends democratizing software development by involving non-developer in the process using low-code or no-code platforms.
However, it is very important to distinguish two types of platforms:
A. Developer-first platforms that allow non-developers to collaborate over code created by developers and shipped to consumers.
B. None-developer platforms that offer non-developers a predefined set of capabilities that can’t be endlessly changed and extended by developers.
A developer-first platform allows developers to create components with any tech stack and tooling and provide them as building blocks for non-developers to visually collaborate on, iterate, style, compose and create with.
In cross-functional teams collaboration between developers and non-developers in the key to success as long as it’s carried directly over a single source of truth (code) and is infinitely extendable.
3. Extended experience and component economy
Internal and 3rd party components become an economy. Each component implemented creates an exponentially growing compounding value. This economy is free yet regulated. It is the democratization and legalization of components, in a governed way. It is not a monolithic monarchy.
The composable enterprise software is composed of components and is therefore highly extendable by design. Components and APIs software can be extended or customized by adding or changing components, in a growing component economy made of both internal and 3rd party components.
Today there are many enterprise-grade API-as-a-service solutions available such as Stripe (payments), Algolia (search), Twillio (comms), Auth0 (authentication), contentful (cms), and many others. Platforms like RapidAPI to help the enterprise manage and consolidate them.
Custom consumer experiences
For the composable enterprise, every part of its software can be extended and customized to fit a variety of usages and consumer needs, giving it the power to create and test infinite experiences to optimize consumer satisfaction.
When applying component-driven software methods such as componentized themes, plugins, and many others, a vast amount of product experiences can be created and customized with speed and ease thanks to modularity.
Build vs Buy for every component
In the composable enterprise, every part of the software becomes a “build vs buy” decision. This approach gets tailwind from the fast-rising API as a service industry with players such as Okta, Stripe, and Twilio providing enterprise-grade APIs to compete with in-house development.
Both internal and 3rd party components must meet the organization’s criteria in terms of security, compliance, quality, adaptability, and so on.
When the decision is to build, in the composable enterprise teams can provide components (e.g. “user authentication”) to all products and teams — reducing the friction of developing, maintaining, and updating the said functionality in multiple products developed by different teams.
Component ecosystem
In the composable enterprise, components are “alive” — they are created, composed with other components, used in different products, updated, and eventually deprecated or replaced. The process of component and API creation is “legalized” so teams provide them directly to each other.
Internal and 3rd party components become an economy. Each component implemented creates an exponentially growing compounding value. This economy is free yet regulated. It is the democratization and legalization of components, in a governed way. It is not a monolithic monarchy.
Product teams become creators and consumers of components. They engage in a “give and take” economy where they enjoy components by other teams and have “customers” that enjoy their components.
A component ecosystem requires a platform to serve as a marketplace where teams can host, discover, share, and collaborate on components.
4. Consistency, governance, and standardization
Hand-in-hand with the legalization of components, the composable enterprise must achieve governance over the way its software is developed, released, and designed. All components and APIs, internal or 3rd party, must meet prerequisite criteria for security, compliance, quality, and more.
Platforms like Bit provide bottom-up tools to standardize component development so that they will be developed and released meeting the same workflows and tech criteria. It also provides top-down tools to help the organization verify components, and to track their adoption and usage.
Standardized software
Alongside the legalization of components and their delivery, tools must be installed to guarantee all created software components meet requirements.
Standardizing software technologies, tools, and implementation greatly reduces the organization’s time to market, eliminates maintenance costs, reduces tech debt, and makes it easier for teams to share components.
For example in Bit builders can be equipped with custom templates, dev environments, build and test environments, and build pipelines. On the Bit platform components that meet the criteria can be “verified”, and the adoption of each component (in each version) can be measured and tracked across the organization — including the impact it has on other components.
Security and compliance
The composable enterprise should benefit from composability in terms of security and compliance. For example, a single authentication component can be used in hundreds of applications instead of a different authentication implementation in each application, making it easier to secure.
In the same way, best practices for compliance can be implemented as standard components verified and required to use by all teams in the enterprise. Platforms like Bit let organizations verify trusted components.
Even 3rd party components can meet security and compliance criteria. For example solutions like Snyk can help ensure security while working with 3rd party components and in a highly componentized infra such as Docker and K8S. Solutions such as WhiteSource can help do the same for licensing and legal compliance, to help ensure compliance in 3rd party components.
Initiating a Composable transformation
To begin a composable enterprise transformation there are several processes an organization can embark on, to gradually shift from a monolithic state to a composable state, benefiting organization and software development alike.
- Introduce composable software: Component and APIs. Introduce composable software platforms (e.g. Bit) for component-driven software.
- Create autonomous teams with distributed business responsibilities.
- Allow collaboration and continuously integrate the entire organization.
- Split components to build or buy decisions and create an economy.
- Legalize creation but ensure governance, standardization, and consistency. Leverage composability to improve security and compliance.
As a result, the enterprise can experience a critical acceleration in time to market, massive reduction of costs, and improvement of ROI on software development, ensure consistency at every touchpoint, and rapidly deliver to meet fast-changing modern market demands ahead of the competition.
