How to select your composable platform

Making a decision when it comes to composable software can be intimidating. 

That was true years ago when traditional software vendors were trying to do everything at once, and even more so nowadays with specialized vendors. There is no longer a “one-stop-shop” and as products get better at what they do best, we tend to spend more time and resources comparing the different options.

Transitioning to a composable architecture is the new standard for a majority of organizations because it gives them the flexibility they need to react to market and organizational changes and avoid the headache and costs associated with re-platforming every few years.

In this post, we’ll walk you through the five steps you can follow to confidently and efficiently select the composable platform that best fits your needs. 

Step 1: Understand the market and your needs

Before going out to buy, you need to know what to buy and how it will help you. Some organizations are looking to (re)build their entire tech landscape from scratch, so they will be looking for many types of software. For others, the change happens gradually and legacy systems get replaced piece by piece with new, better composable alternatives.

Knowing what types of software exist in the market and what purpose they serve is the absolute start. For example, Headless CMS for content, DAM for assets, PIM for product data, CDP for customer information… and the list goes on and on.

Once you know what your organization needs, you’ll want to make a list of potential vendors. A good starting point is usually to look at the top-rated composable software vendors rated by leading analyst firms like Forrester, Gartner or IDC.

Pro tip: If you are evaluating multiple types of software at once, send the other requirements clearly separated to each vendor so they are aware of your complete envisioned architecture.

Step 2: Form a selection committee

The software you select is only as valuable as the impact it’ll have on your teams. 

As improving quality of life is one of the primary reasons to upgrade your software, you should engage representatives of all stakeholder groups early on when gathering requirements. That same committee should also be present throughout the evaluation process so they can steer the decision and react to findings accordingly.

Why form a selection committee? There is nothing worse than being forced to use a tool that cannot accomplish your team’s goals. In addition, ensuring a committee of stakeholders has input on the decision-making process can positively impact the adoption rates of the new software.

Step 3: Determine your selection criteria

What makes one composable vendor more suitable for your company than another? How do you find the right composable tools for your business? Can you simply apply the same criteria as you did years ago when evaluating the monolith or hybrid vendors like Sitecore and Adobe?

Yes and no.

It’s worth noting that, as is the case with any trending buzzword, composable has been picked up by big players and thrown around by their marketing team in all its flavors. That means traditional vendors (the “suites”, “monoliths” and “hybrids”) are now also using the term, which can get confusing pretty quickly.

When selecting the components of your composable DXP, you will want to take the following into account:

• Big picture

• Are you evaluating a single project, or can your organization benefit from a common foundation for future projects that could also use that system?

• Product vision

• Has the system initially been designed to be composable, or is it now marketed as so after haphazardly adapting to the situation? What is their roadmap for the coming year or years? Does it match your scale and growth goals?

• Employee experience

• Is the tool user-friendly? Will it reduce business teams’ dependency on developers? Are both groups enabled to work alongside each other, towards a common goal without slowing down the other?

• Sourcing

• Will you need to recruit an expert for this specific tool, or can it be quickly adopted without having to spend weeks learning the whole ecosystem?

• Automation

• Can you use APIs to replicate user actions? Is there a way to create no-code logic to customize behaviors unique to your business?

• Future-readiness

• Is it designed to be ready for new initiatives? Omnichannel-ready, meaning you can add a new marketing channel next year and this same setup will still make business sense?

Step 4: Compare vendors

The traditional route to compare various vendors involves sharing a list of requirements in the form of a spreadsheet, which the vendors will then fill in with their solutions that fit your use cases. You then schedule meetings with each vendor and they, hopefully, wow you with a demo suited to your needs.

Comparing on paper like this can prove to be an acceptable approach, but since the investment you’re making is one that will be making an impact for years to come, the safest best is to try out the application or vendor for yourself. 

That’s where a Proof of Concept (POC) comes in. During a POC you get the chance to uncover all the good and the bad, to test the truth of the system — not just what they want you to know. As a POC unfolds, you might stumble into one or two details that are deal breakers and, left untested, could have become the worst kind of surprises down the road. 

For example, Contentstack easily differentiates itself on paper with our DXP positioning and enterprise-scale features, but often customers will select us after a thorough POC because only then do they realize that a competitor cannot publish separately in different markets. That is the kind of thing that you can easily overlook in a paper-only evaluation, but can greatly slow down your team's usage post-purchase.

A POC doesn’t necessarily have to mean building something that works 100% of the way the live product will, as your time and resources may be limited, even though it would be the ideal outcome. Nevertheless, in a POC it is important to focus on: 

1. Allowing content editors to create and manage content in the application within an existing setup to envision how it would improve their daily operations
2. Ensuring developers build, define a structure, and understand the APIs and architectural possibilities
3. Bringing stakeholders together frequently to assess progress and impressions

Ideally, a POC should last a few weeks and involve one or two vendors to cement your impressions. The vendors themselves should be a part of the process, but should not be building it for you as that defeats the purpose. 

This is also a good opportunity to experience the guidance and support a vendor can provide. You might be surprised to see that some vendors barely respond to requests for assistance as their focus has moved elsewhere. 

Step 5: Choose the one

There you go! You can now choose the right composable vendor to help you achieve your goals. 

By following these steps you will: create an effective funnel for comparison, capture a group of potential vendors, define the criteria by which to evaluate them, and run a POC to ensure you find the best fit.

These simple but important steps are vital for selecting the best vendors suited for a composable architecture and will also lead to experiencing the best results regarding employee satisfaction and potential business growth.

Take the Contentstack DXP for a test drive with our Developer Fast Track.