Sitemap

Why Do They Call Them Apartments When They’re All Stuck Together?

4 min readMar 14, 2021
Photo by Ján Jakub Naništa on Unsplash

I’m a big fan of service oriented front-end design and microservice based architectures. If I were I building a new service to take to market, I’d most likely go that way. Certainly, I would design it cloud native and my MVP would be API-first… After all, why would I invest the effort of building a slick UI when everyone is so gaga to go headless? But, as a purveyor of digital commerce, would I redeploy my front-end to take advantage of headless design or rearchitect my back-end to leverage all the advantages of a microservice architecture? Probably not.

I would definitely favor a headless design if I had a legitimate business reason to overhaul my storefront and I would probably consider replatforming if my business outgrew my current digital commerce system or if it were a complete mismatch for my aspirations or the team I had to support it. However, as long as my platform met my scalability, availability & performance criteria, I think I would prefer to invest in matters that had a direct impact on growing my business.

The first thing I’d do is eliminate friction. If my UI were preventing people from finding or buying the things they ought to be buying from me, I’d chase those things down, and only consider a complete redesign if I couldn’t fix those issues with the tooling already available. The reason I wouldn’t, “go headless,” out of the gate is because headless is hard and its benefits piggy-back on those of a mature agile development process. Chances are, I’m already in the cloud because I didn’t have the wherewithal to do that well. To eliminate friction in the back-office, I’d turn to microservices, very conservatively. Afterall, we have already called into question my ability to manage the complexities required by a disconnected front-end, which pale in comparison to the mastery required to orchestrate hundreds of independent services on the back.

Strategic IP, fluid features and functional gaps, in that order, would drive my microservice roadmap. For example, I would want to, “own,” my own secret sauce and not worry about losing it to a replatform. So, if my loyalty program was my differentiating value proposition, I would attempt to bring that strategic intellectual property in-house with a small set of microservices, (one if I could manage it) so I could take it with me. If I found I was forever tinkering with promotion logic to keep up with my competition, the social landscape and a myriad of other reasons, I would see that as a good candidate for a microservice. The ability to concentrate on a dedicated fluid feature so I could revision it frequently, without major disruption, is an excellent way to capitalize on the microservice value proposition. Finally, I’d spackle my existing platform where it had cracks. If I didn’t like the way it managed coupons or cross-referenced external assets, microservices.

It’s worth noting how frequently folks get wrapped around the axle during platform selection over a handful of, “critical,” features. Look at it this way, there are no truly bad commerce platforms, just, “bad for you.” Conversely, “perfect for you,” is probably a unicorn. Those already committed to replatforming might reduce their stress by accepting, up-front, that they are going to have to build something and take the things they ought to own off the table. They could concentrate on finding the platforms that best meet their business goals, the abilities of their staff and balance their financial and operational means. They can then select the one that minimizes their need for bespoke services, accepting how unlikely it is that they’ll find one that completely eliminates that need. Headless or not, integrating such services, whether build to order or rented from your favorite point solution vendor, is not a major task for most digital commerce systems.

Gallagher credits his daughter with posing the question, “why do they call them apartments when they’re all stuck together?” Like children, our customers see our brands, “all stuck together,” digital experience, customer service, product quality, and so forth. Same goes for underlying architecture that supports our digital personalities. There is very little Apple or Amazon can do to their websites that will make me visit them any more, or less, often and no amount of slick architecture, AI or crypto-currency will make me the next mustache wax tycoon. There are many advantages in employing headless design to orchestrate best-of-breed services to deliver world class digital experiences; likewise, for decomposing strategic aspects of your enterprise into smaller, manageable services. But keep in mind, some architectural decisions benefit system developers, maintainers and managers more than system consumers and that may matter to you, more or less, depending on your being on-premise or in the cloud. When you are asking yourself, “is the juice worth the squeeze,” consider the kind of juice you’re looking for, who’s drinking it and who’s doing the squeezing.

--

--

Tony Moores
Tony Moores

Written by Tony Moores

Tony Moores is a veteran digital commerce practitioner who has been developing, teaching and consulting in that domain for over 20 years.

No responses yet