A question I’m often asked is: “If I go headless, can I use my existing system integrator?”
I can’t fault the question -- after all, if you’ve been using a legacy commerce platform that includes the head, you’ve been tied to the hip with your current vendor for probably longer than you can remember. But the answer is more nuanced. Maybe you can use your existing system integrator -- and maybe not.
Let’s look closer.
Your current legacy commerce application has been developed over several years and has two or three million lines of custom code, on top of the five or 10 million lines of code that your legacy platform has out of the box. Your current commerce application might have deficiencies, but everything is carefully welded together. Every change, no matter how seemingly insignificant (like changing how a login works, or sending an email) required ridiculous amounts of not only code but knowledge of how it would impact something else.
So you couldn’t trust just anyone to make the change, it had to be someone with deep specialization. This meant you needed the equivalent of a brain surgeon for any sort of task. These platforms and the customizations built up over the years meant that every customization has to be done an extremely precise way. Whether it’s sending an email, changing the data model, or something as simple as logging an error - everything must be done only one way. The complexity is on the “inside” of the application.
Because of the entrenched knowledge about their systems, companies find they are increasingly dependent on their System Integrators. Many companies I speak to want to increasingly be more in control of their own destinies. Meaning, if situations change, they can adapt as needed.
With MACH, it is a completely different story. The beauty of MACH is that the functionality is written in microservices, each exposed by an API.
Rather than all the complexities being inside the application, the complexity is on the “outside,” as in the connections between the APIs. With the backend completely decoupled from the front, you can look for components that best suit the job. Meaning you have to find System Integrators who can handle a composable architecture.
One of the reasons to adopt headless is to have the agility to push data/content/product into any channel. Unlike with a single vendor’s application, , where all the features were determined for you, your System Integrator has to have a strong understanding of any and every channel.
You no longer need a brain surgeon. Now you need someone (actually a team) who are the equivalent of family doctors. Each with a solid foundation in medicine (IT), but who knows how to quickly solve common issues and forward to specialists in the fairly rare event it is required.
A strong, headless system integrator is one who can handle a multitude of best-of-breed vendors and solutions, and have the vision to see how it all can be woven together.
Of course, changing your mindset as to what makes a good System Integrator does require a bit of a cultural shift. It takes a certain amount of courage on the part of the organization to go from legacy, everything-thought-out-for-you to clean-slate-we-can-now-do-anything-with.
This might mean trying – and failing. But since you can now “try” quickly you can assess and adapt as necessary.
As to necessary skills? Well you want a team with the ability to:
- Call APIs
- Build microservices and all that entails - team structure, use of cloud, etc.
- Determine when to build vs. buy functionality
- Build frontends
So bottom-line, what should you look for in a headless System Integrator? You need a team that has
1. The vision to architect a solution – and source its components
2. A variety of skills to execute on that vision
3. Cloud-certified engineers
4. Strong UI sense -- different experiences for different customers
5. A drive to partner with you – and share common goals
MACH: Business Technology for 2020 and Beyond
”66% of developers find that maintaining and “paying for” technical debt (aka the money, flexibility, and opportunity lost to a bad technical investment) associated with outdated technology is bad for their productivity at work." State of the Developer report 2109, Devada