Demystifying Platform Technology: Buzzwords and Jargon Never Deliver

I am really going to enjoy writing this week’s version of Topper Tuesday. It’s challenging because I am not an architect or developer. And, there are so many architectural opinions, methods to articulate technology and debates that follow. I enjoy it because it’s a challenge to simplify the complex for the non-technical folks while maintaining decent technical accuracy.

Here we go!

I’ve been or managed the CIO and/or CTO function in some fashion since 1997. But, having started in a CIO role directly out of the United States Coast Guard, the only “ranks” I came up through were the military ranks I progressed along during my tours of duty.

I do understand the value of technology, however, and how its architecture can lead to success (or failure). While I am not a brilliant architect, for the better part of three decades I have partnered with a huge number of people who were. They were a whole lot more educated, more experienced and smarter than I was in the areas of engineering and architecture.

Learning from my team’s combined intelligence

I remember during my interview with Rosetta Stone, their CEO asked if I could manage individuals who are smarter than myself. My response: It’s all I know how to do! The head engineers I have had the pleasure to lead, the “right hand” I could not do without, all had common traits even if they were very different humans. Here are a few characteristics they brought to the team:

1. They shared my love and excitement for what technology could do for our business.
2. They were patient, understanding that bringing others along for the journey was critical.
3. They were hungry to learn and remained curious knowing that building for the future was as important as building for the present.
4. They were brilliant engineers and architects with broad skills and a huge capacity to learn.
5. They wanted technology that would lead to outcomes, not merely that was focused on what they had used before or the current trends.

I owe these humans — and their teams — a lot. As much as any CEO, CFO or board member, these people shaped me. We formed unique relationships, true partnerships, and the evolutions and revolutions we went through together will never be forgotten. Amazing experiences, all of them.

This post is for them. But not TO them — they know this only scratches the surface of where we’ve been together.🙂

Understanding the architecture of today’s commerce technologies

If you have read my previous posts, you’ve gained a few pointers around Why replatform? and 5 key points to consider when making retail replatforming choices.

This post will give you the tip of the iceberg of what you might want to understand (or teach) around modern commerce technology, buzzwords flying around like “composable” and “configuration” and technology and architecture that enable you to modernize without sacrificing your ability to stay modern during your watch and that of the person who follows you. We’re going to focus on two main contrasts: Monolithic vs. Modular and Configuration vs. Customization. And a closing bonus, I’ll answer “Why be native cloud?” which most already know but it never hurts to re-emphasize.

Monolith vs. modular

What is a monolithic architecture? Well, Merriam-Webster (yikes!) defines monolith as “a single great stone often in the form of an obelisk of column.” That works!

In as simple of terms as I can describe it, a monolithic architecture in retail combines the commerce functions (client-side UI for the website or POS, database and server-side applications like pricing, search, OMS, etc.). These are all managed by a single code base sitting on one database. All the functions are reliant on each other as the data moves between them but remains in the same “box.”

What is a modular (or composable or microservices — all the buzzwords) architecture? In this architecture, the same functions are each a separate service or system with their own codebase and database, and they communicate with each other via APIs.

The “access” to these systems, or the front-end, is independent and can literally be anything such as a mobile app, customer service portal or website. Since the front-end (also referred to as “head”) is independent, a true microservices architecture is, by definition, “headless.” Sometimes, people will say they are working to “decompose” their architecture as they move towards a microservices architecture. This is where the word “composable” comes into play, as in a “composable architecture.”

There are pluses and minuses to both architectures. Some firms and technicians will position monolithic as evil. They are not. They have a place, usually where rapid and continued change is not critical (like an ERP).

Where we would agree though is that the place for monolithic architectures is not in the fast-moving discipline of commerce. Most commerce platforms are either based on a microservices architecture (although very few were built from scratch like fabric), or trying to get there, which is a heavy and long journey.

Slicing up a monolith anything less than perfectly to, for example, become “headless,” leads to potential future challenges for the customer trying to integrate into a suboptimal architecture. As a result, like with artificial intelligence that has recently become every vendor’s middle name, some platforms offer a less than stellar reality when they claim a microservices architecture versus actually having built one from the ground up.

I will highlight the strengths and challenges of microservices. I am going to keep it to a few of each or my editor will kill me — this post is already twice as long as it should be, and yet seems ridiculously short.

Microservices’ strengths. At the end of the day, better websites lead to better conversions, AOV and ultimately more traffic via improved SEO and loyalty. This is accomplished through the ability to enact change quickly — not just meeting but anticipating a customers’ needs.

Microservices architectures enable these outcome:

1. Easier to maintain, especially over time where changes are made to “modules” versus the entire monolith. The looser coupling of microservices requires strict standardization of communication, which enables speed of iteration of future features. Eventually, a monolith can (will) become bogged down with all the changes, and in some cases nearly grind a company to a halt. Ever been around an ERP that has been customized over decades?!
2. You have the ability to change “modules” instead of disrupting your entire ecosystem. Don’t like your product catalog? Swap it out by only dealing with its connections and not the entire monolith.
3. They are technologically agnostic, for the most part. Services or modules can be different technologies, databases or even cloud infrastructures.
4. Innovation, or really the speed to market of anything new, becomes far simpler and faster to implement. This includes the ability to “test before you buy.”
5. Tech debt is limited to a module and not the entire ecosystem. Changes to the code affect one module and not the entire platform. Your partner can and should be innovating faster and more deeply on the capabilities you need.
6. Scaling a service (versus the entire monolith) is easier AND cheaper!

Microservices’ challenges. The complexity of microservices architectures stems from the “plumbing.” This is the “orchestration” between your front-end experiences and all the different services in your commerce ecosystem plus the downstream passing of information to core systems like ERP. Accordingly, they can present challenges such as:

1. They can be more complex to implement. Those APIs (sometimes hundreds of them) require orchestration and/or a gateway to ensure the right data is passing between services and experiences. Great partners can be great simplifiers to help mitigate this.
2. If you have a microservices platform that pushes customization, you can develop anything you want on top of it. Configuration requires that users make many of the changes they need from a control panel. For configuration, you could find yourself in need of more modern (and expensive!) talent.
3. If you build a complete platform yourself (which I led a few companies ago using over 100 services), the complexity increases as a) the inherent integrations like cart to order are now the retailer’s responsibility, and b) most extensions require in-house building versus taking advantage of a platform’s pre-built extensions. At the time we decided to build, there was not a platform available that didn’t necessitate a large cadre of engineering resources to make it viable.

Why microservices wins

A platform like fabric is modular because it’s based on microservices. And, while we have done the work to connect our modules (as discussed, this is one of the biggest challenges with this architecture), a client could also choose to start with or purchase just one, like OMS or our product catalog.

While the microservices work in harmony, they also work with any commerce platform through a robust set of 400+ APIs. And, in fact, fabric embraces this incremental approach because it’s fast! Find partners and platforms that can deploy at speed, and show an ability to de-complexify the above mentioned challenges. But, as with any challenge, and you will always have them, and risk mitigation is key.

Customization vs. configuration

Choosing customization versus configuration comes down to the extent of changes to the system or platform that can be accomplished by the users. More specifically, it’s what can be accomplished without code versus the ability to add your own code to extend the capabilities of the base platform.

From Broadcom Software Academy:
● “(C)onfiguration is simpler and less costly since it relies on using the software’s inherent features and settings.”
● “[Customization] involves making changes to the software’s core code to add new features, change its behavior, or integrate it with other applications.”

Let me give you an example. You are routing orders to your stores for Buy Online, Pick Up In-Store (BOPIS). A particular store is either unseasonably busy or is experiencing staff absences. So, they need to change the threshold of how much BOPIS they can manage. In a customization scenario, you would need developers to make this change. With configuration, a non-technical user simply turns a digital dial and manages it up or down (or even higher than originally set) based on associate availability.

As technology advances and the speed to market of anything new continues to accelerate (AI?!), the ability of users to configure the software will decrease instead of users or even developers queuing up for new features in your or their development organizations. I’d rather have a platform company advance the configuration capabilities that matter to the users, and ultimately their customers, than almost anything else.

How many features, capabilities and projects have you delayed as you waited for a vendor to prioritize the feature (if it ever does)? If you have the capabilities to make changes yourself, that is configuration.

If you have an unapologetically large and sophisticated development organization with bandwidth, customizations can work. But every new line of code written today becomes legacy tech debt that you must continue to manage and maintain tomorrow. Instead, I recommend you dig deeply into the configuration capabilities of any platform you are buying. Not just where it is, but where it’s going.

The bottom line: Configuration reduces entropy.

I firmly believe in putting the power with the end user instead of the developer. Even the best of the best developers I have worked with feel the same way!

Why be native cloud?

I mean, really, almost everything is in the cloud. If you own a big server and manage it in your own building, you open that up via your private network to others on or outside your network, this is your own private cloud. If you move that to a more public cloud like Amazon, Google or Microsoft (they are all viable), you are moving a non-cloud-native system to a third-party cloud provider.

However, a native cloud application is one that was built for and resides in one or more of these public clouds. It makes a difference because of all the tools and capabilities these third-parties are far more readily available with applications that were built for this type of cloud infrastructure.

There could be times when on-premises applications make sense. I could make a good argument for a WMS to be on-premises. I have always been nervous running a DC through the cloud instead of your Local Area Network. However, I freely admit this is probably just me being old school.🙂

In the e-commerce world, most providers now are 100% cloud based (some native, some not). Below are just a few of the advantages, all generally included in the annual license fee. The fee is usually some base flat rate with additional costs for increased usage — the cloud is basically a utility, so the more you use, the more you pay. These items are generally what you pay for:

1. Infrastructure. Servers, databases, bandwidth, and all the associated management of hardware and telecommunications facilitated by the third-party you choose.
2. Business Continuity as in live, instant failover (called “Active Active” or “Hot Hot”) is simply a matter of course that is possible with on-premises but inherent to the cloud.
3. Security. Third-parties manage the security of their infrastructure. Generally, a security checklist is or should be part of your evaluation process.
4. Scale! Scaling is a) inherent with third-party cloud providers, and b) harnessed by your e-commerce partner. Double your traffic? Autoscaling comes into play.
5. Monitoring. All cloud providers have their own monitoring capabilities and accommodate most of the popular monitoring software.
6. Upgrades. With the right platform, upgrades are often non-ROI sinks of time, money and opportunity cost, but they are the job of the provider and covered in your fees.

Why fabric Commerce Platform?

And now, it’s time for my brief, shameless (but genuine) plug.

fabric was built from a blank sheet of paper to create a platform with a robust OMS and DOM. Its creation focused on these four principles:

1. Fast. Get to market quickly. Start with individual commerce services. Grow to power the entire commerce business with a pay-as-you-go pricing model.
2. Easy. Operators are in control with a fully configurable user experience from merchandising to order management.
3. Flexible. A cloud-native commerce platform with a composable architecture that allows retailers to craft the experience they want.
4. Integrated. Out-of-the-box reference architecture with prebuilt integrations to a best-in-class ecosystem of commerce services.

I hope this helps! I worked to make it understandable to the non-technical person and relatable to all the techies out there!

In the next Topper Tuesday, my take on “the order”

The order is magical! The order is the point in time, from the cart or cash register, where the customer has made a financial commitment to the merchant. She has put her trust with you.

Delivering on that trust doesn’t end with the order — it starts with the order. And, more and more, the order is the foundation for doing amazing things to meet and surpass customer expectations. It’s the “heartbeat” of the entire commerce experience.

Considering your OMS during a replatform, whether you change it or not, is super prudent. Tune in next week to learn why!

Toppers Tips & Tricks: Demystifying Technology

• Never take your eye off business outcomes versus technology tools. From my last post: Make sure you understand what you are buying, and remember that jargon doesn’t increase conversion rates!
• The more you can educate your less technical counterparts in the business, the more the digital IQ of your company will increase.
• Don’t be afraid to challenge the pros, even in their own backyard! But, you can’t challenge them if you don’t understand. #BeCurious
• A repeat from last week’s post: Speak to the doers such as the product and program managers, engineers, and architects. Get to know your builders.

Jay Topper

Chief Customer Officer @ fabric