Emporix's CPO on the role of "greenfield" development and best-of-breed as commerce platforms need to adapt to new market requirements faster and more flexibly than ever.
Stefan is a visionary and entrepreneur with a proven track record in the technology industry. Prior to Emporix, he was part of the core team at Hybris Software for 18 years where he shaped the Hybris’ positioning within the SAP portfolio, expanding its scope by adding marketing services and sales. When it comes to trends and transformation in digital commerce, Stefan is the man to talk to. We did just that and asked him three questions on Composable Commerce.
“Your choice is customize or compose”, Forrester says. What does that mean to you?
Custom build or Greenfield development played an important role in building digital commerce platforms more than 20 years ago when I helped grow Hybris. It meant to write a large portion of the business logic from scratch only relying on low-level application SDKs like Java and a limited number of third party monolithic components like database, CMS, ERP, Payment Service Provider and a few more. Almost every potential customer we spoke to at the time had embarked on their version of an E-Commerce stack in which the business logic was custom built and third party components were “composed” into that logic.
What we realised back then at Hybris was that we needed to separate the commerce stack from the ERP stack, to make it easier to compose end-to-end business processes with an extension mechanism and empower developers to build business logic faster - relying on common commerce components. Thus, we could address the performance problems of the ERP, could empower our customers and implementation partners to build custom business logic faster than with any of our competitors, dramatically shorten implementation cycles and could create a large ecosystem of software partners utilizing our extension mechanism. It was never a question of or; it was always an and. Which I still believe it is.
What has changed since you helped grow Hybris?
For a couple of trends the writing was on the wall very early on. Headless for instance. Contrary to popular belief it’s around much longer and probably started in the very early 2000s, accelerated by the demand of using Flash as a user interface for web applications and the first internet enabled mobile devices. I’d argue without headless being part of the plan so early on so many user touch points from social media to mobile apps would not have been possible. It is the only way to make these things work. Back then, it was certainly innovative but today it is common practice and not even a hallmark of great software design in my books as any monolith can be headless.
For me, a watershed moment was the arrival of AWS in 2006. Suddenly computing power has become as ubiquitous as electricity. It is there when I need it. For me it’s the equivalent of plugging an appliance into a wall plug. I’m sure there are a lot of complicated and expensive processes happening generating that electricity but at the end it is an utility that is available for me when and if I need it. The same is now true for computing power. The transformative power of AWS (GCP or Azure for that matter) is that all I need is an idea and a laptop to start writing software.
This coincides with the explosive growth in packaged business capabilities available in the market. Just take a look at the marketing technology landscape over the years: From 2006, when I saw a first version of it with 50 vendors in it, it had grown to 150 vendors by 2011. Not bad you might think, but when you compare it to the growth from 2011 to 2021 it pales. In those ten years the landscape grew to over 8,000, a year on year growth by almost 500%.
The next key moments were NoSQL databases as well as Amazon’s Redshift as a data warehouse. It completely changed the thinking about data and how it can be stored and processed. Now we have a new, different kind of technology stack than 10 years ago. It allows businesses and software developers alike to think of data completely different than just a bucket in which I put something and then occasionally retrieve it.
This dynamic creates an interesting conundrum for me as a software vendor but also for my customers. From a software vendor's point of view I have to accept that I can’t longer own the entire software stack. I can neither develop fast enough to compete with every single specialist solution out there nor can I consolidate competition by acquiring them. It’s an expensive arms race that I just can’t win, no matter how deep my pockets may be when I start doing it.
These two factors are forcing me to think of software as a network of composed capabilities, an ecosystem of composable software services if you like, rather than a vertically integrated stack of software libraries and components. The latter one favours a monolithic software architecture, whilst the former is only achievable with a true cloud architecture in which composition is a core principle.
From a customer’s perspective the picture is similar though mirrored. Firstly, the number of software tools in my organisation is exploding, fragmenting business processes. One New York based manager put it quite well to me: The mood has swung from “there is an app for that” to “not another app, please”. A few years ago the reaction would have been that we need to consolidate all with one vendor, getting everything from one hand. This feels like the most natural conclusion but I think it’s fair to say that the one stack, one vendor, one suite approach has failed and devoid businesses of their ability to innovate.
So what now - customize or compose?
I think composition must be the default approach today. Regardless of whether you are starting from scratch (aka Greenfield) or you are looking to innovate with what you have today. Many components in a commerce stack are commodities today. When you look at payment providers, chat functionality or search engines it is the most obvious. It’s not to say that these components are not valuable but there is really no good reason to build this from scratch as these areas will provide very little differentiation for you in the market. Getting this from a third party provider and composing it into the commerce stack would always be my default position.
That’s not to say that customization or even building a greenfield solution for a very specific, but differentiating value proposition aren’t valid options anymore. The difference in a composable software stack is that I can, with almost surgical precision, pick the area that I want to customize or in which I want to build something innovative. That’s the true power of a composable software architecture for me. Now I can mix and match what I build myself - hopefully something innovative that doesn’t exist in the market -, tweak something to fit my customers needs better but without the need to consider the entire stack or just use a component that is readily available in the market.
The questions now are: Where and how do I do the composition of my stack? How do I orchestrate my end to end business process in which each of these components and packaged business capabilities plays an important role?
What does “Best of Breed” mean in times when e-commerce systems must adapt to rapidly changing market needs, rather than setting the scope for digital commerce?
I think the term “best of breed” may be somewhat misleading. It suggests to me that the software vendor has selected for me which components are best of breed. I prefer the term “mix and match” since that choice has actually moved on to my customers. Today, in digital commerce, best of breed means for them to use the most suitable component that adresses the problem that they are trying to solve when executing a business process. Whether that comes from a third party vendor or is something that was custom built is almost secondary to them. What they are looking for is a platform that supports that modularity and lets them combine capabilities from different providers, including those Emporix is offering.
Today, specialized solutions are available for the entire purchasing process, ranging from product search, ordering, and payment to delivery and beyond. Integrating suitable services leads to an end-to-end, highly flexible ecosystem. We call this Composable Commerce, of which Headless and API-First are features. However, all these terms always refer to the opposite design to all-in-one solutions, where the entire system comes from a single provider.
I used to think of digital commerce as a linear, vertically integrated stack. Which feels natural when you look at how a product flows through a selling process, how the checkout works or how an order is processed. What has become clear to me though is that digital commerce is actually an ecosystem, a network of components and processes. Thus I truly believe that it is time for a new class of commerce systems that focus on business process orchestration and execution and that fully embrace the core concepts of a network: decentralisation, federalism and distribution.
Build or buy? This question is still heavily discussed in companies. How does Emporix’ Composable Commerce Platform help get the most out of both worlds?
It's very simple: a composable commerce platform like Emporix is designed to help businesses shape their commerce exactly the way they need to grow. Today we give them a platform that was founded in the core concept of a composable commerce stack and ecosystem. It offers ready-made components that help to get digital commerce projects faster off the ground and the mechanism to easily bring other capabilities from other vendors or that exist in-house into the mix.
Right now we are enabling solution providers and in-house development teams to implement composable commerce projects for businesses, whilst in the future we want to empower businesses themselves to manage their end-to-end digital commerce projects through Emporix and the means of composition. Any service - ready-made or home-built - that contributes to the success of your business model and can be connected via API will be deployed quickly and with little effort and risk.
A true composable platform gives you full freedom to choose, no ifs, ands or buts. You decide which services you want to use, regardless of where they come from. That's a great thing but, funny as it sounds, challenging for some companies. If you've been using monolithic all-in-one solutions for decades and are used to maintaining them, tediously adapting them, and managing growing complexity, then the shift to composable commerce may require a fundamental rethink and new ways of working.
Teams are no longer responsible for an entire system or areas within, but work on individual services connected to other services. The modular structure of the digital ecosystem is reflected in the organization, which is gradually becoming more flexible and also composable. This is a huge opportunity for businesses to adapt to fast-moving e-commerce.
Stefan, thank you very much for the chat!
To find out more about how Composable E-Commerce can help grow your business, get in touch with Emporix today by clicking here.
