Published on January 12, 2023
Whether they’re aware of it or not, virtually every organization is at least a little composable. Even organizations with monolithic technologies are likely to have a separate component or two. It’s an approach to be embraced, not dismissed.
No matter how you get there, once you go composable, you’ll never look back. Based on a how-to guide co-authored by Appnovation and Contentful teams, here are seven steps to become (more) composable.
Companies with MACH (microservices, API-first, cloud-native, and/or headless) architecture that embrace “composable” technology opt for piecemeal, modular solutions. Think small parts over big platforms.
For example, instead of using a monolithic solution to power a website, a composable approach would involve a tech stack made of purpose-built tools that excel at a single function — like a headless CMS to store and structure content and a personalization engine to tailor messaging for specific users.
Each component is like a tool in a toolbox. They can be used, removed, or rearranged as needed to build experiences and streamline processes. The components are then ideally connected by developer-friendly APIs that provide straightforward integration, with no heavy orchestration or batch data loading required.
The Contentful® composable content platform meets the unique demands of digital content and all the teams that produce and work with it. Built with an API-first architecture, a composable content platform orchestrates content from multiple sources and publishes it to any digital channel. It ensures content is discoverable and reusable, provides tailored interfaces, and incorporates governance through role-based access management and workflows.
Thirty-seven percent of IT leaders consider modernizing legacy apps a high priority, but many companies have concerns about the transition to a more modular setup, particularly regarding time, expense, and adoption. These concerns are valid, but not new.
Though dealing with legacy apps is difficult, the right strategy can produce impressive results. Traditional enterprise vendors have often grown their tech stacks through acquisitions in an attempt to provide a universal solution to customer problems. The resulting platforms are more frankensteined than seamlessly integrated — and are built from the vendor’s viewpoint.
With a composable approach, companies can optimize small, easily integrated components to solve their immediate and potential future problems in a way that creates ideal value for them and their customers. In this ever-accelerating digital world, organizations can find their own definition for “best-in-breed,” not have it dictated to them by the market or a vendor. The best viewpoint is the organization's viewpoint.
An incremental migration allows organizations to realize swift returns and enables business units (and individual teams in those units) to iterate at their own pace, while eliminating both risks and bottlenecks. Organizations can create their own unique ecosystem, a tech stack like no other. Such exclusive setups have the potential to be a massive differentiator in delivering unparalleled customer experiences.
Just as a guest list can make the difference between an enjoyable or disastrous dinner party, the stakeholders involved in a composable project can determine its success. Ensure there’s a cross section of perspectives and consider creating dedicated task forces for efforts such as the tech audit or governance.
Stakeholder balance: This collective should extend beyond those who’ll build or use the tech stack. Consider including the following:
Individuals representing various levels of the organization, not just the C-suite
Business units across brands, verticals, regions, or departments
Those with in-depth knowledge of customer needs
Cultural influencers who understand the company and its people
Experienced team members with insight on historical projects
New talent with fresh outlooks on the company
Getting buy-in: Easier said than done, of course. It can be difficult to get all the necessary teams, groups, or regions of a business to support a composable project. It is important to communicate realistic expectations. As well, it is integral to show how the outcome will benefit them once complete.
There’s only one hard-and-fast rule when beginning a tech audit: Stay open-minded as you progress through it. What you learn will inevitably influence your transformation, often in unexpected ways.
And, whether you’re a marketing team looking to enhance your digital capabilities or a tech team hoping to avoid expensive licensing renewals, remember, you want the solution that delivers the fastest time to value. You’re not doing this because it’s fun. You’re doing it because some aspect of your business needs to evolve.
There are a number of different questions that need to be considered.
Historical questions might include “When was the last time we did a replatforming?” or “What was important then?”
Meanwhile, current questions could look like “What are we trying to accomplish,” “What’s changed since our last replatforming,” or “What aspects of our business aren’t meeting changing needs?”
The difference between customer-centric questions and comparative questions are, for example:
“How are our users interacting with our current platforms?”
“What level of effort is required to make these changes?” respectively.
On the logistical side, an appropriate question might be “How much risk are we able to absorb?” or “How easily can we isolate the impacted functionality?”
Finally, a future-focused question could include “What are we going to need a year from now?” and “Five years from now?“
Tech stack construction today is more complicated than ever before. It’s not uncommon for a modern stack to include a dozen or more products. To see tech stack visualization elevated to the level of art, take a look at these Stackie Awards winners.
Two things stand out among them: a robust tech stack is a blend of built versus bought applications, and the customer is placed firmly at the center of it all.
Functionality: Needs will differ depending on your company, but here are the most common:
Commerce management, possibly encompassing:
Product information management (PIM)
Enterprise resource planning (ERP)
Content management system (CMS, like Contentful)
Personalization
Digital asset management (DAM)
Translations
Flexibility: This is one of the biggest benefits of transitioning to a composable stack. The consolidated components each have a very specific purpose, which means they can be easily swapped out or customized. But exactly how flexible your stack should be will depend on the internal user needs.
Priority: With the switch to composable, it’s easier to make decisions that align with changing business needs. If you’re an ecommerce business, for example, you’ll likely add a PIM, DAM, and CMS from the start. Or if you don’t have a personalization team, you might wait on finding a vendor for that but still structure your content such that when you’re ready to plug in a personalization engine, little preparatory work is needed.
The beauty of composable is that the migration process isn’t one-size-fits-all. Businesses can move at their own pace and decide which components to change, plus when and how to go about these changes. This is where assessment findings become crucial.
The ideal approach should not only offer the fastest time to value, but must be weighed against other factors as well. If the highest ROI requires a huge development lift but the team is tied up on another short-term project, that could impact the direction of the migration.
An incremental approach can offer small, but measurable impacts in a relatively short time (eight-12 weeks versus nine months, for example) and carry less risk, since the outcomes can be evaluated and managed throughout the transition.
Strangler fig: Like the namesake tropical plant that survives by wrapping itself around a host tree, causing it to perish, this approach to composable migration involves gradually replacing services until the original system is “strangled” and able to be decommissioned.
This approach can be used to replace a legacy monolith or ecommerce platform market by market, starting with the smallest. Once it proves successful, migration continues to larger markets until the old platform is no longer needed. Moving in increments minimizes migration risks and speeds development efforts over time.
Steel thread: In this approach, the goal is to migrate an entire experience from the backend to the frontend, like pulling a thread through the tech stack. A company using this method might transition its entire content management system in one motion. Rather than replacing a single layer of functionality, this method focuses on the technical implementation. It’s useful for validating designs and preparing core components for further development and rollout.
Spike: This approach focuses on implementing only a part of the solution to gain a better sense of its performance. For example, in an ecommerce upgrade, the project might prioritize replacing just the checkout process, to ensure it functions as expected. This approach is depth-oriented, as opposed to breadth-oriented, and is used to quickly verify technical capabilities.
Big Bang: Just as it implies, the Big Bang takes an “everything, all at once” approach to migration. It could be as sweeping as replacing an entire monolithic system, or as simple as launching a website to serve an entire customer base. This approach carries significant risk and has the longest time to value.
Once the composable elements are in place, they must be appropriately linked, whether that’s via point-to-point integration or API orchestration. Or, as one CTO we worked with put it, “It’s not about the boxes, it’s about the arrows.”
An amazing personalization engine won’t be much use without access to customer data. It’s well and good to have best-in-breed components in a tech stack, but their true value can only be realized if they’re successfully connected to each other.
Source of truth: Once all the tools are in place, it’s essential to figure out what will provide the “source of truth” for each component. Identifying this will impact how the stack is governed.
Component | Source of truth |
---|---|
Product data | PIM |
Content | CMS |
Assets | DAM |
Brand consistency | Design system |
Ease of integration: This is where the “API-first” perspective comes in. Selected components should have a robust set of APIs. If not, treat it as a red flag — it will likely be tough to make the component work within the stack.
Design system: While a composable tech stack can certainly exist without a design system, it’s definitely a worthwhile addition, particularly for global brands.
A design system provides standardized design elements that designers across the organization can use to build consistent experiences. For example, if you’re a company that caters to global markets, a design system can better ensure that website buttons look the same across region-specific websites.
But maintaining a design system isn’t always easy — it’s a balancing act between flexibility and consistency. It must be strict enough to provide uniformity across brand touchpoints, while allowing developers to easily find and amend elements as needed.
Governance is a phase often overlooked as digital solutions are frequently built and then thrown over the fence to end users with little more than a wave of “good luck.” This is where the people you brought into the fold at the task stage become vital.
The governance team should understand various user objectives and include relevant stakeholders affected by system changes. After working diligently to build a future-proof tech stack, the aim is that the products are not just adopted, but effectively used. Otherwise, it’s like owning a sports car and never taking it out of the driveway — an utter waste.
Change is tough: Becoming composable is about more than just tech — it’s a mindset. Change is psychological and new workflows can leave users feeling incompetent or confused. Overcoming this goes beyond training, it’s about engaging as early as possible with those impacted by the migration.
Instead of informing them the change is happening, give them the story of why it’s necessary — and how it will make their jobs easier. Again, there’s no clear-cut approach for this. Do what works for your organization. Change management is not about methodology, it’s about awareness and empowerment.
Jobs, not systems: When deciding on the right governance structure for your stack, think about it in terms of the jobs to be done rather than the systems themselves. Your organization size and vertical will dictate what’s needed. A small company won’t have the same governance needs as a large healthcare or fintech firm whose systems manage sensitive data.
Who needs what? Your marketers need access to specific functionality in the ecommerce system, but you don’t want them touching pricing or inventory data. Now what? Simplify governance by consolidating permissions into one login so users access only what they need from a single UI, with no risk of touching anything they shouldn’t. (Contentful can help with this.)
Gone are the days of whole teams working through the night to launch a new website. With composable stacks, teams can make deadlines without feeling dead tired as site components are broken up and handled by specialized teams, each able to move at their own velocity. There’s freedom to define iteration cycles and support continuous improvement in specific areas of the system.
Make quick changes: The benefit of a composable ecosystem is that changes can be targeted to specific systems or parts of systems, allowing them to be made rapidly. Observe changes and respond to them in a timely manner.
Make small changes: Composability decouples teams from the need to do massive rollouts with tons of changes that then require in-depth evaluation to determine success. When building iteration cycles, identify the smallest, most realistic increment in which it’s still possible to create meaningful change for the business.
Make informed changes: Testing shouldn’t be a random process. Monitor how your system works in real time and make changes that are informed by data, business, and end-user values.
Make people-centric changes: When maintaining a system, it’s easy to forget it exists to serve people. Listen to feedback, keeping in mind not all of it requires action. Sometimes people just want to be heard. But, be proactive in making fixes before they turn into issues for customers.
That’s our guidance for your organization to become (more) composable. We hope you’ve found it useful. But before you go, here’s a summary of the key takeaways.
While undertaking your assessment, keep an eye out for solutions with fast time to value.
There are a range of options when it comes to migration. Incremental ones often offer the fastest ROI.
It is mission critical to select project champions who possess insights from high-level strategic, business awareness, implementation, and day-to-day usage perspectives.
A robust tech stack is a blend of built versus bought applications, with the customer placed firmly at the center.
The best components in the world mean nothing if they can’t connect to each other.
After working diligently to build a future-proof tech stack, the goal should be that the products are not just adopted, but effectively used.
Create a cycle of continuous improvement that delivers small, fast changes informed by what users actually need.
Subscribe for updates
Build better digital experiences with Contentful updates direct to your inbox.