Distinguishing Signal from the Noise: B2B eCommerce Trends for 2022 that Matter

Let’s start with an overview of what’s going on in the market today. Joe, can you talk a bit about some of the high-level trends that we see in the market today? 

Joe Cicman: Thanks, Motti. Hi, everyone. So I cover B2B eCommerce, marketplaces, and digital experience platforms here at Forrester. As Motti mentioned before I joined Forrester, I was a client of Forrester, and I worked for years with the Salsify eCommerce platform. So I’ve got some really fun battle scars from that. Here’s what I would sum up. This is about platforms that can keep up with brands that are experimenting to figure out what digital interactions work for their particular customers. And that’s not a one size fits all type of thing. There are lots of nuances across industries. So you can’t copy what other companies or your competitors are doing. What I tell clients is that you wouldn’t take your neighbor’s medication, just because she’s feeling better today. You got to get to your own diagnosis, you got to figure out what you need, what your customers need from you. I’m really looking forward to today’s discussion because we’re going to get into the nitty-gritty details of a whole lot of these buzzwords floating around. And we’re going to put it into the context of what that means inside of the trends. All right, Yoav, over to you.

Yoav Kutner: Thank you, Joe. I think that we are figuring out a lot of things in B2B still. I compare my previous experience with Magento and if we look at 2004-2008 years, it feels like we’re here again, but with B2B companies this time, trying to figure it out, trying to prioritize how they go about digitizing their business and the experience that they’re giving to their customers. We were surprised once we started getting into this field when we found out that B2B companies are anywhere between five to 10 years behind the technology curve. A lot of this has to do with what they have to prioritize and where they have to invest. As Joe said, companies experiment, learn, and try to build something that works and gets them further on this path of digitizing their business, sales operations, and interactions with their customers. These are exciting times. It’s something that brings out companies that are going to figure it out faster, paving the way for other companies to go digital in the B2B space. This discussion is something that we’ve been doing with customers and partners in our community.

Motti Danino: Let’s get right into it. We hear a lot about headless today. And there’s a lot of discussion about if headless is good or bad. I’ll let Joe start and give his point of view on headless and what’s going on in the market.

Joe Cicman: Well, headless is real. But it’s a little bit difficult for people who aren’t technical to wrap their heads around it. I’ve got a couple of things I want to hit on this. I do get calls from investors, and they ask what is the total addressable market for headless commerce. And my answer to them is, look, all commerce platforms are headless. Now, some have better APIs than others. What I mean by that is they have more productive APIs. But no one is going to fund a new software company with a technology strategy that tightly couples a fixed set of touchpoints to it. Headless is the first step in the great decoupling. Now, I also tell those investors and other end-user clients that the term headless is proving to be a very bad word. And here’s what I mean by that. You need headless commerce because there are so many heads you need to do commerce on. So imagine if you’re a CFO getting that pitch. It’s not rational. I have not heard a single pitch for headless that would work for a non-technical audience. That’s the problem with headless: if you’re not technical and you’re not initiated into it, it makes zero sense, and it sounds ridiculous when people try to pitch it to you.

Yoav Kutner: I agree with Joe on this, and I think headless is a term that’s getting bigger and bigger noise in the B2B space. I’ll leave B2C a bit out of here. What we’ve seen with a lot of trends, the excitement about headless has been overused. We see companies that are almost religiously saying that they have to go headless, ignoring the problem at hand. We often see that technology is leading the problem-solving, rather than focusing on the problem at hand and figuring out what’s the right solution for that. 

One thing that I’ll add to what Joe said is that it’s not all or nothing. It hurts me to say this, but sometimes we get hung on how we’re going to do it rather than what we need to do. I think headless is a great example of this. It was exciting 15-20 years ago when we were talking about separating the view and the controller to allow more flexibility, move faster, innovate faster. But what we’re seeing, in reality, is that you just add more technology to the solution in the end, because now you’re separating it to n-number of technologies that are consuming some business logic. It causes usually more complexity, longer time to market, more expensive solutions, rather than quicker, faster, cheaper, as people think it will be. 

My point is, again, it’s not all or nothing. Headless has a lot of benefits. We’ve seen implementations where we were enabling B2B2C, allowing the B2C part of the B2B2C to consume in a headless manner, because every B2C implementation was using different technologies, so it made a lot of sense for us.

But if we’re looking at a project where their first thing is to post their catalog online, talking to them about headless is like forcing it down their throat. They need to go online fast, they need to be searchable and indexable. How that’s done is almost secondary to that. Now, again, I’m not saying leave any view or vision for future development. Choose a platform that will allow you to use headless the way it makes sense. Something that should remain in the technology discussion of how we implement or solve the problem at hand, rather than religiously saying, we have to go this or that route.

Motti Danino: The next trend we would like to discuss is composable, modular, and microservices. Yoav, any thoughts on this? 

Yoav Kutner: These terms are typically what companies start hearing when they look at going into B2B eCommerce. I believe that these technologies have to be implemented if they solve the problem at hand. Modular solutions in today’s world are expected. Let’s start with that. No monolithic system is going to solve your problem out of the box, especially when we talk about mid-market and larger enterprises. Off-the-shelf products are where we are today in B2B and B2C. We standardized what you expect from a shopping cart eCommerce website so that you can use it off the shelf, with some extensions and customizations. However, we see that today’s B2B companies are going modular. You have to be able to modularize your system and make it work for your workflows and business practices. 

But then we start digging to the next layer, whether it should be composable or microservices first. It has to be the right solution for solving the problem. Microservices is a very nice term. But it’s nothing new: that’s a way for us to use somebody else’s work to get the feature or part of the project already done. So this is something that brings us faster to market. But if it’s used solely as the architecture, it can extend the development time and cost. So it’s something that we definitely don’t want to go all-in on. A good approach or a good platform should allow you to use what they offer out of the box, or turn it off and replace it with a feature or a solution or a service that will do something better. This means selecting a platform that gives you the flexibility to use composable, modular, or microservices where it makes sense. 

From my experience, those are more successful projects, because companies don’t have to necessarily make all technology decisions right away. They can start with something that works, learn, and get feedback from their customers and sales teams. Flexibility is key. You want to leave your technology team enough room to play on different technologies. Trying to find a solution that is either composable or modular or microservices is not the way we should look at this. To sum it up, you should look for a platform that actually offers you the flexibility to choose the right implementation for the right problem that you’re trying to solve.

Joe Cicman: Composable, modular, and microservices are all technical terminology. But if I think my favorite metaphor right now is those televisions that have DVD players built into them. That’s an example of something that is not modular. It’s all in one. But is it signal to noise? It’s a signal for people who understand those technical terms. However, when it’s being served up to a non-technical audience, it gets a little bit dangerous and confusing. You have to put it in the audience’s terms. So the noise largely comes from the messaging. 

My hypothesis is that it’s a new crop of cool modern vendors trying to take their shots at the big old incumbents because these terms are part of the new generation of tech. And there’s still a large legacy installed base out there. 

I do see vendors quite literally using the term composable. I had one executive at a vendor say ‘we’re composable because we have APIs’. That’s not technically correct to say so, and reflects poorly to just slap buzzwords on your products. 

Motti Danino: We have two questions related to this. First one is, what’s your take on full suite monolith vs composable solution?

Joe Cicman: Let me take a crack at this one. With regards to TCO, I’ve seen a better TCO of composable. But I’ve also seen a better TCO of a suite. It depends on the dev team in the company that’s running it. So if you have a dev team that’s got modern skills, you can do great with modern tech. But if you’re not organized, it’s going to be an uphill battle.

When I ask myself why is there so much of this last-generation on-prem stuff in place? The correlation that I noticed was, all the tech in that environment was that same old age. To make that change, and embrace modern composable commerce, very often, companies have to make a new modern cloud tech mandate across their entire environment. But if you don’t get the mix right, if buy tech that your team can’t use, it’s a big bowl of hurt.

Motti Danino: Thank you, Joe. There’s another question for Yoav. How do SAP, Salesforce, and Adobe differ from composable solutions?

Yoav Kutner: These vendors differ between themselves. Starting from Salesforce, which is a SaaS solution that is extendable through the cloud. A lot of what is offered is almost monolithic and exposed through API’s, and then you build your own on top of it versus Adobe, or Magento, where it’s a truly modular application. The way it was designed can be consumed in many different ways. And of course, SAP is a behemoth that’s been around for many years and is layered with different technology. So even though it looks like a single product, it is a bunch of technologies working together. What I saw from our experience that a lot of SAP implementations suffer from this, where you roll a rock over, and you don’t know what to expect under that part of the application, because it’s been gathered together from many different solutions. I’ll add that about Salesforce as well because a lot of its features are actually either acquisitions or other technologies that are running almost behind the scenes for the user. 

It’s a bit different with Adobe. No secret, we were the ones who originally designed Magento. And it does have a lot of the components that we have at Oro. I think being able to have complete control over your platform, having the ability to modularize the system, use the features you need, extend them, is crucial. That’s the guiding principle that we use in developing platforms. And I think most of the modern platform follow it as well. But if we look closer, a lot of them have been around for 20-plus years, and are using older technologies. They put some patches on top of it, try to make it more flexible, more service-oriented, etc. With technology and time and money, anything is solvable.

Motti Danino: Thank you. Let’s continue to the next topic: API-first. Joe, can you comment on this first? 

Joe Cicman: Alright, this is real. But here’s my favorite smart-aleck rhetoric: API-first means that you wrote the API before the implementation, it does not mean that you have API on the first slide of your sales presentation. I don’t think we’re discussing the validity of any of the terms, I think we’re discussing the way people use them. If they use them thoughtfully, then it becomes a signal. But if they use the term thoughtlessly, then it becomes noise. People using the term are either going to contribute to the signal, or they’re going to contribute to the noise. What do you think, Yoav?

Yoav Kutner: I completely agree with you that this is a technology pitch again. But we cannot ignore API today. If you’re developing a system, and there’s no way to expose your business logic in an API manner, sooner than later, you’ll get stuck. A lot of what I was doing early on in the B2C world was connecting systems. And we were building middlewares, connecting multiple systems together. A lot of times, we were faced with systems that didn’t have API, and we had to use flat files for integrations. 

Those days are over. We cannot ignore that API is the way to go. That’s how usually two systems will interact and talk to each other, consume data from each other and implement business logic moving forward. That said, especially like I mentioned earlier, in B2B, there are still a lot of these archaic systems out there that don’t have API’s covering most or any of their features or data. 

If you’re developing a new system or selecting a new platform, API is a must. Now, back to Joe’s point, does it have to be first? And that’s a great question. My answer is no, it doesn’t have to. The time to market is going to get hurt if you invest so much time in building API framework, set it all up. And it still doesn’t do much work that is usable, either to the customers or to the company itself. 

If you select the new technology, find the application or platform that has great API coverage and extendability. When your platform can extend the API framework, this allows you to create new business logic that is covered through API. It’s going to save you a lot of time and money later on. But for businesses, I wouldn’t say that that’s a checkbox that has to be ticked because you don’t care at that point if it’s API-first or not, as long as you can actually write API and expose your solution via API, so it can be consumed by other companies, services, and solutions. That’s the key thing to keep in mind.

Motti Danino: Great, thanks. API is a signal, as far as what the audience thinks. 71% say it’s a signal 29% say noise. But we go on to the next buzzword: low code. Joe, do you want to start on this one?

Joe Cicman: Low code is real. Low code is spectacular. Think of it as a flowchart where you can show the logic of the application visually, and you write very little code. But again, this can be wildly misinterpreted, either intentionally or unintentionally. I once got pitched that something was low code, because the code they wrote was JavaScript. While low code is probably a little bit better understood than things like API-first, I still see a few instances of folks taking liberties with it. Yoav, what do you think?

Yoav Kutner: Yeah, I think low code does nothing new. This is a constant effort in the technology world to remove the need to write code to solve a problem. We’ve seen great categories where this was very successful. CMS is one. But in the B2B specifically, we’re not there yet where somebody can come and design a zero code application. We’ve seen that it’s still being figured out, the industry is not there yet. There’s a lot to learn before we can write a true zero-code application.

In B2B, there are so many systems talking to each other. So a lot of times, the code that you’ll have to write is about the integrations. For example, what we call a workflow engine that is designed to actually low-code all your business flows and processes. But there’s still work that needs to be done in connecting the systems together. The focus should be on the features and configurations that matter, meaning that not the whole system has to be low code. We have to look at what matters for the business and then build a solution that will not allow the customer to shoot themselves in the foot trying to configure something. 

So that’s where low code matters: customer onboarding. We don’t have to involve the technology team or developers to write the code for them. And we need it to be maintainable and extensible as we move forward. However, this should not be something that you religiously pick, especially if you want to do a lot of customization in the future.

Joe Cicman: You brought up a really great point about separating the other flows from the integration. The real benefit of low code is how it can bring about this citizen developer, who’s a business analyst knowing the complexities of the business. They’re not skilled up to be coders. But they can think about the business problem and then move big blocks around, just like they would draw a flowchart on a whiteboard. And that’s really the talent that you’re unlocking. It’s not about saving coders. It’s about unlocking the talent and the brilliance inside of all these business analysts.

Yoav Kutner: Absolutely. It’s about identifying what users need control over. We’ve seen systems that were low codes, error code, but setting them up takes longer than writing a code to solve the problem. Low code should be where it matters for the business exactly. We need to enable, disable features, provide a low code configurator or drag-and-drop system based on the role or based on the process.

Motti Danino: Okay, so I think we’ll have time for one more buzzword, even though we have way more than that. This is something that we hear a lot about today – marketplaces. Yoav, what are your thoughts on B2B marketplaces?

Yoav Kutner: B2B marketplaces are something that we see as a trend. We’re getting more and more requests to build marketplaces using Oro, so that’s definitely growing. B2B marketplaces share a lot of features of B2B distributor eCommerce. They have multiple sellers and multiple buyers who need access to the system. I think this is key: we need to able to provide eCommerce features for multiple buyers and sellers before we talk about marketplaces in B2B. Moving forward from there, before we get to marketplaces, we also see a lot of implementations that use a reseller model, or franchise model. And again, they start sharing a lot of what marketplaces promise or need to have. So B2B marketplace is not completely isolated from eCommerce implementations and features. They share a lot of requirements.

An interesting observation is that a lot of companies don’t understand the complexity of running a marketplace. The challenge often is not the technology or the solution. It’s how your business operates, who offers customer support, and who gives the customer service. Is it going to hurt your brand, if one of your vendors gives a poor customer experience? So there are a lot of questions that have to be answered. We’re early on when it comes to awareness about how marketplaces fit into the company’s current business and operations.

Joe Cicman: Marketplace is less about the tech because I think there’s a good amount of tech out there right now. The marketplace is a different business model. I worked with some clients who looked at it from a technology perspective, but there’s so much more to it. You have to code your revenue differently. Because you’re getting commission revenue. You have different opportunities, because once you hit a certain scale, then you can start making money from marketing and advertising services. 

In a lot of B2B companies, they would have non-stock items, they’ve done that for years. With marketplaces, how would you effectively manage an assortment where you have a mixture of fast-moving and slow-moving SKUs? How would you manage that long tail? When I talk to folks who operate marketplaces, the one thing they tell me repeatedly ‘I thought I could take my first-party buyers and make them third-party recruiters.’ And they can’t. It’s a very different skill set. In terms of the trend, marketplaces require more transformation in the business. It’s just a more ambitious undertaking. But a marketplace has real value, it just takes a lot of effort. That’s why the adoption curve is stretched out a bit.

Yoav Kutner: We’re seeing a lot of businesses go from the listing kind of marketplace where they just list products and send customers to have interaction somewhere else. They are trying to bring it all online. But there are also companies that are large brands that are trying to enable a marketplace, and that’s where you start hitting a lot of landmines. If you think that your business can transform into a marketplace easily, that’s not the case. 

Motti Danino: Yes, in my experience, we didn’t see any marketplace that was easy to implement. To wrap things up, we hope that we have provided you with some food for thought. And as Joe said, don’t take your neighbor’s medicine just because it made him feel better. You need your own. So make sure to select the tools that you need to get through your business transformation and get your strategy executed right. Thank you very much, everybody. We appreciate you coming today and looking forward to seeing you soon.