Com­pos­able or not composable

The role of head­less ecommerce

There are a myr­i­ad of options for head­less, with all kinds of pro­gram­ming lan­guages and struc­ture that allow mer­chants to update or even com­plete­ly change store­fronts keep­ing the same platform.

Accord­ing to Andy Hoar and Bri­an Beck’s Mas­ter B2B ecom­merce pre­dic­tions for 2024, ​“the future won’t be head­less, but most­ly com­pos­able”.

Although head­less archi­tec­tures pro­vide flex­i­bil­i­ty, they may lack key pre-com­posed fea­tures. On the oth­er hand, com­pos­able com­merce — which actu­al­ly pre­dates head­less- goes beyond by sep­a­rat­ing all com­po­nents, not just fron­tend from back­end. So we are like­ly to see more com­pa­nies grav­i­tate towards a more com­pos­able approach and find a mid­dle ground, hybrid archi­tec­ture between all in one solu­tions and ful­ly com­pos­able struc­tures to strike a much need­ed bal­ance between the val­ue offered by full flex­i­bil­i­ty and the speed and ease of use that come with pre-com­posed functions.

The term com­pos­able com­merce (coined by Gart­ner) is defined by the abil­i­ty to decom­pose an enti­ty into var­i­ous mod­ules, which then com­bine to form the whole. Com­pos­abil­i­ty is a design prin­ci­ple in tech­nol­o­gy and busi­ness that empha­sizes the abil­i­ty to select and assem­ble var­i­ous com­po­nents or ser­vices to cre­ate cus­tomized solutions.

So what is the question?

This approach allows for flex­i­bil­i­ty, scal­a­bil­i­ty, and rapid adap­ta­tion to chang­ing needs or tech­nolo­gies. It is there­fore vital for busi­ness­es seek­ing to main­tain a com­pet­i­tive edge by lever­ag­ing mod­u­lar archi­tec­tures, such as microser­vices or APIs, to build agile and resilient systems. 

A com­pos­able archi­tec­ture allows com­pa­nies to build their orga­ni­za­tion from inter­change­able build­ing blocks, with four key tenets: mod­u­lar­i­ty, open­ness, flex­i­bil­i­ty, and a busi­ness-cen­tric approach. This struc­ture facil­i­tates the assem­bly of Pack­aged Busi­ness Capa­bil­i­ties (PBCs) like vir­tu­al shop­ping carts, order man­age­ment, or account man­age­ment to meet spe­cif­ic busi­ness needs. It enables busi­ness­es to select best-in-breed ven­dors for a robust, func­tion­al tech­nol­o­gy stack, offer­ing cus­tomiza­tion flex­i­bil­i­ty beyond the con­straints of tra­di­tion­al, mono­lith­ic platforms.

More­over, this mod­u­lar strat­e­gy allows busi­ness­es to select and inte­grate the best-of-breed solu­tions — rang­ing from con­tent man­age­ment sys­tems to pay­ment gate­ways — into a cohe­sive platform. 

How­ev­er, the need to inte­grate var­i­ous com­po­nents and man­age a mod­u­lar sys­tem intro­duces com­plex­i­ty and may require spe­cial­ized skills not read­i­ly avail­able in all organizations. 

More­over, adopt­ing a com­pos­able approach might entail sig­nif­i­cant ini­tial invest­ment and pose chal­lenges in inte­grat­ing dis­parate sys­tems, espe­cial­ly for busi­ness­es with lim­it­ed tech­ni­cal exper­tise. So, while com­pos­able com­merce offers B2B com­pa­nies unpar­al­leled flex­i­bil­i­ty, scal­a­bil­i­ty, and future-readi­ness, it also demands care­ful con­sid­er­a­tion of its com­plex­i­ty, resource require­ments, and inte­gra­tion chal­lenges. Busi­ness­es must weigh these fac­tors based on their spe­cif­ic cir­cum­stances, resources, and strate­gic goals. That is the question.

Three archi­tec­tures, three tradeoffs

Before ​“com­pos­able or not,” a wider view. There are three shapes B2B eCom­merce archi­tec­ture tends to take. Each makes a dif­fer­ent bet.

Mono­lith­ic. One plat­form does every­thing — cat­a­log, cart, check­out, con­tent, account. Big­Com­merce, Shopi­fy, and the clas­sic Magento/​Adobe Com­merce sit here. The bet: speed to launch, low­er cost to oper­ate, few­er inte­gra­tion points to main­tain. You sac­ri­fice some flex­i­bil­i­ty in exchange for a plat­form that works out of the box and a ven­dor who owns the whole stack.

Head­less. The fron­tend is decou­pled from the com­merce engine. The com­merce plat­form stays most­ly mono­lith­ic, but you get free­dom on how the store­front looks, behaves, and per­forms. The bet: fron­tend inno­va­tion and chan­nel flex­i­bil­i­ty (web, app, kiosk, mar­ket­place) with­out hav­ing to rebuild the back end. You pay for a sec­ond devel­op­ment team — one for the engine, one for the head.

Com­pos­able. Every capa­bil­i­ty is its own ser­vice. Your com­merce engine talks to a sep­a­rate CMS, search, check­out, PIM, CDP, and loy­al­ty stack. Best-in-breed at every lay­er. The bet: you get exact­ly what you want at each point. You also get to own the inte­gra­tions forever.

None of these is objec­tive­ly bet­ter. The right one depends on what you’re opti­miz­ing for and what your team can real­is­ti­cal­ly main­tain — today, and three years from today.

How to tell which one you need

Stay mono­lith­ic if…

• You’re still grow­ing into your cur­rent plat­for­m’s fea­ture set. Most com­pa­nies are.
• Your team is lean. A com­pos­able stack needs peo­ple who under­stand how APIs fail.
• Your com­pet­i­tive edge is not the check­out expe­ri­ence. If it’s prod­uct, ser­vice, or brand, a mono­lith won’t hold you back.

Go head­less if…

• Your con­tent and com­merce teams are at war, and the com­merce plat­for­m’s CMS is the reason.
• You need to ship expe­ri­ences across chan­nels (store­front, app, kiosk, in-cat­a­log) that can’t share a sin­gle ren­dered frontend.
• You have the fron­tend team to own the head — not just to build it, but to keep build­ing it.

Go com­pos­able if…

• You have a capa­bil­i­ty that has to be world-class and the mono­lith’s ver­sion isn’t. (Search for a 400,000-SKU parts cat­a­log. Loy­al­ty for a mul­ti-brand oper­a­tion. Sub­scrip­tion billing with rev­enue recognition.)
• You have the engi­neer­ing lead­er­ship to think of your stack as a port­fo­lio of inte­gra­tions rather than a prod­uct you bought.
• You’ve made peace with the fact that inte­gra­tion is a per­ma­nent line item on your roadmap.

A com­pos­able exam­ple you can actu­al­ly picture

Imag­ine a B2B dis­trib­u­tor with 80,000 SKUs, three cus­tomer seg­ments (retail­ers, installers, end-users), and a loy­al­ty pro­gram they built them­selves in 2019.

A mono­lith­ic plat­form gives them 70% of what they need out of the box. Search is ​“fine.” Loy­al­ty is a plu­g­in that almost works. Seg­ment­ed pric­ing is sup­port­ed but awkward.

The com­pos­able ver­sion: com­merce engine from Big­Com­merce B2B. Search from Algo­lia (because 80k SKUs with tech­ni­cal specs demands it). Loy­al­ty from a ded­i­cat­ed ven­dor who sup­ports mul­ti-brand tiers. Pric­ing log­ic in a cus­tom ser­vice that talks to the ERP. Check­out from the com­merce engine — because rein­vent­ing check­out is almost nev­er worth it.

Each piece does one thing well. The glue — APIs, events, error han­dling, mon­i­tor­ing — is now the dis­trib­u­tor’s respon­si­bil­i­ty. Forever.

This works beau­ti­ful­ly for the dis­trib­u­tor above. It would be a dis­as­ter for a 15-per­son B2B start­up with no ded­i­cat­ed DevOps.

The hon­est version

Com­pos­able is often sold as the sophis­ti­cat­ed choice. It can be. It can also be the way you end up main­tain­ing six ven­dor rela­tion­ships, three inte­gra­tion lay­ers, and a dash­board that shows where the last sync failed.

A few things that are true but rarely pitched:

• The mono­lith you already have is prob­a­bly fine. Most com­pos­able migra­tions we see hap­pen because a plat­for­m’s 20% gap became emo­tion­al­ly intol­er­a­ble, not because the 20% gap actu­al­ly hurt the busi­ness. Check the math before you rebuild.
• Com­pos­able makes every upgrade some­one’s prob­lem. When your com­merce ven­dor ships a new fea­ture, you don’t get it by default — you get it after your team inte­grates it. That’s a real tax.
• Ven­dor roadmap align­ment gets hard­er. Ven­dors, roadmaps, pric­ing changes, sup­port tick­ets. All on you to coordinate.
• Com­pos­able does­n’t fix a bad strat­e­gy. If your prob­lem is that you don’t know what your B2B por­tal should do, no amount of archi­tec­tur­al ele­gance will save you.

None of this means com­pos­able is wrong. It means com­pos­able is a com­mit­ment bet­ter made with your eyes open.

What comes next

Archi­tec­ture is the blue­print. Actu­al­ly build­ing the thing is where inten­tions meet real­i­ty. Here’s what B2B eCom­merce web­site devel­op­ment looks like in prac­tice.