Headless Commerce: Advice for Goal Hangers
So, you are considering headless commerce and have made your way through the talks, videos and articles but still have doubts? The very first thing you need to do is understand who you are and what you are trying to do so you can properly dissect the arguments for or against a headless approach. The headless commerce value proposition is blended across numerous stakeholders: providers, consumers, and end users. This means that there may be perfectly valid arguments for going one way or the other that may not apply to your decision. Knowing what you are looking for will help you discard the noise and concentrate on what matters for you and your organization.
Agility is perhaps the most often cited benefit of headless commerce but agility is all about delivery. If your organization has an agile delivery program you brag about out conferences and you are not leveraging headless platforms to deliver bespoke user interfaces, you should be writing an article about why you are not. On the other hand, if your delivery organization is riding a barrel over a waterfall and you think going headless will make you agile, it’s time to get a second barrel!
You must be able to release UI updates independently of your back end. This gives you two separate streams of work and the opportunity to tune the processes that drive design, develop, test and release as frequently as possible. Need more agility? Keep dividing work-streams until the required coordination between work-streams threatens their independence. Indeed, you’ve heard this argument made for microservice adoption and it’s a good one, if you are in the business of building and maintaining core backend services. But this is where the headless argument gets a bit muddy.
You can’t “do” microservices well without DevOps, which is all about the tools and processes for coordinating these independent work-streams from their inception to their release as a single functioning system. While there is still much debate on the intricacies of doing that well, it’s a mature and well-defined space for delivering code. But what about delivering experience? We are talking about delighting customers, driving sales, optimizing pricing and boosting loyalty… what are your ComOps? What tools and processes will you use to coordinate discreet business goals into a well-oiled experience machine? To what degree is it really possible to compartmentalize the front end and still ensure holistic and meaningful customer experiences?
It turns out, that IT-lead organizations borrow from DevOps to manage their ComOps, quite successfully in some cases. I have had the pleasure of working with a multi-brand retailer with a single IT organization but a separate design team for each brand. Front-end teams dedicated to a given brand operate and release at their own pace until they hit a requirement that is beyond them. Those are kicked up to the platform team who develops new services that all brands may use. One brand is pure headless, their design team does its own stunts in parallel. Being software engineers at heart, they utilize a very mature CI/CD process to evolve several custom UIs that leverage services developed by the platform, the products they manage and various point solutions. However, most of the other brands leverage vender tools from either a DXP, Commerce or Search provider to deliver timely front-end updates to their customers independent of global IT’s schedule. It’s interesting to note, that at least one brand did not have a separately deployed UI.
I don’t believe there is any argument to the notion of having separate and independent release process for one’s core commerce services and their user interfaces, and headless commerce certainly supports that. Nor do I believe anyone would dispute the flexibility offered by developing one’s own UI. But, I am troubled by the agility argument for headless because it assumes the opportunity of agility in software delivery translates to business agility. It makes a great deal of sense for IT-led organizations, but others may be better served by a platform or a suite with UI tooling. Remember, a platform with a good API will still support separation of and composition at the UI.
I can’t tell you which is right for your business but I can say this: Agility is not only how fast you can kick the ball or make the pass. It’s about how quickly you can change direction and move the ball down the field. Business agility is about putting all of those things together to score goals. It takes a great deal of practice and conditioning. You can’t buy it, and if you are trying to build it, you better know the game, the pitch and the players in order to build the program that’s right for you.
