If you’re in charge of a digital transformation project or even building a startup, there’s always this big question of where we invest our effort. Are the open-source components a real shortcut? Which elements should you buy on the market, and which ones to build on your own?
The all-inclusive eCommerce platforms are long gone and composable commerce services or Packaged Business capability (PBC) based is apparently the future. This post will help you to successfully navigate that issue.
Return on investment
This is a question of which fights you’re going to fight by knowing which ones you’re able to win. Knowing your limitations, you must pick just a few. The fact is that the complexity and amount of software required for a successful digital transformation is only growing. At the same time, the urgency for the time to market is increasing with growing competition.
What I’ve heard in my 12+ years in digital commerce from the merchant-side CTOs was usually something like,: “We’ve got a budget, it’s not unlimited, so my CEO is asking me for results. I’ve had a hard time dealing with all these maintenance/devops costs around the actual value chain.”
Simply, a business is rarely fully OK with accepting costs that aren’t easy to justify. I mean justify as in having to explain spending more customers’ dollars. Having two or three devops folks dealing with service level agreement (SLAs) to just keep things going. At the same time, having another two or three devs working on new features is like you’re wasting 50% of the budget that could have been spent on wins like new features.
Moreover, with maintenance costs, you can’t win. You just can’t lose. I mean, if the system fails, despite all the engineering capacity invested into keeping it up, you’re in trouble. On the other hand, no one was promoted by just having the eCommerce site up and available all the time. Better think twice about if you really need to host and handle all these netty microservices your team planned to deploy on their own ;)
It’s not about building it. It’s all about maintaining it
When the software was mostly built in a fixed-budget manner and with waterfall methodologies, there was common wisdom among the software companies. The wisdom said that, despite the implementation phase being in red, the true money will be made on the maintenance and further development. The initial implementation costs, given the full CTO of a system for its utilization period, typically a minimum of two to three years, were 20-30% percent of the total cost. The budget spent on features was one-third of the total cost of the project.
The problem with the software you own, created, and/or deployed is that you need to keep it up and running. If you’ve got a small team, say less than 20 developers, it can be challenging to maintain, deploy, monitor, and keep the 24/7 SLA for a few dozen services. You need to have a devops inside your team.
The developers working on the software you deploy usually won’t be ready. They also won’t like to be on a pager 24/7 and having to have the secure shell (SSH) terminal always on and ready to react for any kind of issue their service will face. You must ensure the proper error and failure handling, network traffic balancing, and redundancy. Then, the team needs to be in charge of the whole thing 24/7
Having your application based on enterprise grade services, meaning maintained and serviced by the provider, is a totally different situation to having your core business system fully decoupled and maintained by your team. I think that the power of cloud computing is that you don’t have to take care of the details and can actually fully outsource the devOps to the service provider.
What makes the difference?
The value is built, first and foremostly, where your technology faces the individual clients, and their problems. Their needs are a great place for improvements. No wonder that building and owning a custom front end and buying and just using all the other back-end components is usually the intuitive choice. The business model and conversion rate is something you need to focus on and invest your effort in.
When I spoke with Philipp Triebel of Highsnobiety, he put it this way:
“So, we know that we need something that gives us freedom on the front end. We are a very visual company. That makes our front end may be more important than for the average brand. Also, given the model that we’d want to do content-driven commerce, we knew that we want to integrate commerce very smoothly and seamlessly into our existing front end and like our existing experience. We already had some technology choices there. So, on the front end, that also played into it. This led us to the search for something versatile.”
They choose to use commercetools as a back end and to build a custom React front-end application. They spent 90% of the engineering time building features and the unique selling proposition for the customers.
I’ve heard pretty much the same story from Steffen Sandner from Marc O’Polo Digital where they pick the About You Cloud as the back end and Vue Storefront Next for the front-end application.
The Marc O’Polo folks decided to host some of the back-end services as well. They were mostly deployed as serverless functions to minimize the time spent on maintenance and hosting.
The architecture Marc O’Polo has is pretty complex:
Their architecture includes several components from different vendors like AboutYou components, such as Backbone, Checkout, CMS, company’s CRM from Microsoft, and Internal ERPs to provide features like Order Management mentioned above.
What are the key reasons for owning these? Flexibility, sustainability, the highest possible speed of making adaptations, and no vendor lock-in.
I asked Matthias Zielezny, Chief of Software Development at Marc O’Polo, how you could actually customize the eCommerce platform which is SaaS:
“We somehow have to connect that system to our internal or other external systems. As AYC expects data in a specific format and also sends data in a specific format, we build a middleware on AWS and Azure to transform the data between those systems.
Matthias Zielezny, Chief of Software Development at Marc O’Polo
“So our order management system, for instance, gets the order as JSON through AWS API gateway which triggers a lambda function.
“This function makes a few checks and writes the order to our order database, which is DynamoDB. On this table, we have a trigger, so on order creation, we are triggering another lambda function that exports the order to our logistic partner and another lambda which sends the bonus points for our members to the CRM system, and so on.”
This is a pretty similar story to the case of Mirka.se, a sandpaper B2B leader from Finland. Mathias Rönnlund told me their story about why they picked a customized Spartacus front end while taking the whole back-end eCommerce functionality out of the box from SAP CX.
The winning CTOs know what makes the difference. They wisely choose to only fight the fights they can win.
Wrap up
The ownership problem is the key question to answer. You should keep an eye on your company’s goals, Objectives and Key Results (OKRs), even profit and loss, or whatever other indicator of success you use. Then, choose the components that will let you maximize it. Composable commerce is great because you can just use the services that work with reliable APIs that you don’t have to maintain.
Even having your custom code now doesn’t mean the maintenance cost will be high. This is especially true with the JAMStack approach where the front end is compiled, hosted over reliable cloud CDN, and which is just using the APIs for getting the dynamic data. No dynamic application equals no maintenance costs.
The services businesses you would like to have are the ones that make a difference for customers or are key to the business model. These change a lot. It may be the front-end application or the product configurator.
They are usually the processes that are quite common and aren’t customized, like invoicing, general Enterprise resource planning (ERP) features, or Warehouse Management System (WMS). These services increase your overall costs of ownership without giving back the proper business value. I’d recommend you avoid owning these services, and just integrate them altogether.
To read more about the options you’ve got for choosing the right components for your eCommerce site, I can recommend two of my recent blog posts. The first one is about the choices CTOs are making in regards to eCommerce platforms. The second one is a blog post plus a whole eBook on composable commerce platforms.
What I tried to do is to show a landscape of components and the reasoning that seasoned CTOs are using to make the best choices. They know best which fights they are able to win and how to build a unique value for customers.
I’m curious about your thoughts. Which elements of your architecture have you decided to build, and which ones you’re going to buy?
Published March 16, 2021
