How to Move from Monolithic Suites to Composable Stacks
Agility is a quality that all enterprises chase.
Agile organizations move quickly to act on trends, edge out competitors, and respond to crises. In this pursuit of agility, many engineering and IT leaders are realizing that their traditional monolith suites are hindering speed and precision. A 2023 Gartner study found that improving operational excellence is now one of CIOs' top two priorities—and that leaders are now focusing on optimization rather than growth.
This trend is bearing out in the form of plans to abandon monoliths in favor of composability. Last year, Gartner predicted that 60% of finance organizations will realize this and invest in composable stacks by 2024.
Suites vs. Stacks
Traditional enterprise suites are like sculptures—practically immutable. Suites tend to be all-in-one platforms from a single vendor. IT then has the pain of integrating and managing multiple vendors and technologies together, whether with custom code or otherwise. This kind of environment technically has the ability to change, but it is difficult and time-consuming to do so because of the way it is built. Effecting changes in an enterprise suite takes more customization—and there is much less room for flexibility.
Composable stacks, on the other hand, are more like Legos. Technology in a composable setting is easy to select, swap out, assemble, rearrange, or reuse with minimal disruption. To wit, a composable system is exactly what it sounds like: a system that offers users the flexibility to change its composition to make it work in their surrounding environment (while satisfying their requirements). To this extent, it represents the opposite of a suite—which is monolithic and inflexible, requiring users to instead change the surrounding environment to support it.
As with a suite, there are still multiple vendors to deal with in a composable environment. With composable stacks, however, integration, scaling, upgrading, and development all become more seamless, pivoting takes less time, and outpacing your competition becomes easier. To this extent, composable stacks can help every department in your organization achieve the agility it's after.
Shifting an entire architecture from suites to stacks is not easy, however. There is much to consider—like the best team for the project, what the ideal stack looks like, and the right migration strategy.
The way organizations choose to act on this migration strategy varies based on their goals. For the sake of this article, we’ll focus on what this might look like in a marketing environment—but the overarching process stays the same regardless.
Phase 1: Pick a Mini-Transformation to Start
When migrating from suites to stacks, many organizations first adopt a composable technology that sits at the foundation of the stack, moving toward full migration in phases—what I like to call "mini-transformations." Starting with a single composable technology can be, and often is, the catalyst for a wider evolution toward digital maturity. With this strategy, enterprises also experience quick wins such as improved operational efficiency and faster time to market.
For the first mini-transformation, pick a project small enough to be manageable—especially if you run into problems—but significant enough to be noticed by important stakeholders when you succeed. A landing page or a microsite can be a good target, because problems therein can be contained relatively easily—but the benefits are noticeable.
Identify what you want to take on first. Then define clear goals by which to judge success or failure. Maybe it’s cutting down development time or the time it takes to go to market. You might need certain features and capabilities such as you wouldn’t be able to get with a suite.
Once you have defined these goals, move to Phase 2.
Phase 2: Put a Small Team Together with Agile Methodologies.
A small team can move quickly, so a small team will be well suited to tackling the project you have chosen in Phase 1. Your mini-transformation team should stay focused on what "agile" means: the ability to change direction quickly.
Focus on good leadership, incorporating a healthy mix of talent and experience, and finding the right level of autonomy to address problems immediately. Emphasize completing small goals that build to big ones. If team members can communicate easily and openly, small goals will let them see what works and what doesn't sooner so that they can go back and fix any issues.
I recommend that your team have experience with the technologies you're working with. They will think about not only the back end but also the user experience on the other side. Find architects that excel at solving back-end issues but understand the purpose of the entire project.
Successful mini-transformations depend on implementing agile methodologies. The team should strive to create goals based on outcomes and customer impact—rather than solely around productivity and risk. Ask questions about how well certain individuals work together to support each other. Work on building trust and transparency as a team—because those team elements generate results for customers.
Phase 3: Pick a Composable Technology that Sits at the Foundation of Your Stack, Like a Headless CMS.
The central composable technology for marketing teams tends to be a content management system (CMS). Implementing a headless CMS (a type of CMS without a connected front-end layer like a traditional CMS) with a multi-tenant cloud structure is a good place to start. Because the back and front ends are separate, there are fewer limitations on where you can distribute content. A headless CMS can push to a variety of channels, including websites, mobile, wearable technologies, and VR/AR systems.
But before you commit to a composable CMS, it is important to take inventory of what is housed in your current CMS. Map out the different functionalities to ensure that you have the right technology in your composable stack to handle those functions after the migration. Figure out how each feature works and what APIs will be needed to connect those features. This will help you down the road when building out your composable stack.
Make sure that the CMS you choose is lightweight and that you can get up and running reasonably quickly. Then, integrate with a good hosting provider.
This is where your Phase 1 and Phase 3 should meet. Once the headless CMS is in place, check that the landing page or microsite works the way you intended. Can the new CMS keep up with the demand? Identify and address any problems, keeping in mind the goals that you set in Phase 1. Are those goals being achieved?
Phase 4: Repeat Phases 1–3 Until Finished
Once you have completed the first mini-transformation, pick another project and repeat the process. Start iterating and building. Let’s say that you've upgraded a landing page or a microsite; now how would you integrate composable architecture with your main website? What interdependencies will you need to find, isolate, and untangle between your functions so they can become separate apps in your stack?
Keep in mind that a fallback plan can help during the transition. Many enterprises have their old CMS run simultaneously with the new one until everything has been moved over to the composable architecture.
After finishing the first mini-transformation, your team will know how to start and deliver a project in a few weeks. This will be useful for managing speed until you get to your fully composable stack. But the work doesn’t stop there.
The benefit of composable stacks is that you can always improve and add technologies your company needs to stay ahead (such as an e-commerce or content-personalization platform). It’s up to you and your team to decide when to slow down or stop phasing toward a more optimal stack. Remember that composable is a journey—not a destination. Because the market is always changing, your organization should be too. This methodology will help your teams pursue continuous improvement to deliver the experiences your customers want.