That's why you should prioritize flexibility when building a new e-commerce platform

Most people working in e-commerce know that “today” rarely lays the foundation for “tomorrow.” New technologies, new markets, and thus new opportunities are constantly emerging.

To seize these opportunities, you need to be able to adapt your existing system landscape. The faster the pace of change, the harder it hits companies that have built IT architectures lacking flexibility.

A flexible IT architecture is one where outdated, underperforming, or insufficient components can be replaced with new, value-creating ones.

Engage in architectural decisions—and secure a future-proof setup

The IT industry is a prolific producer of clever acronyms. And that makes it harder to engage in architectural decisions than it really needs to be.

Among the buzzwords dominating the conversation today are “Composable DXP,” “Headless,” “Microservices,” “MACH” [insert MACH link here], and “JAMStack.”

These terms are usually coined with good intentions—by consultants. Like us. Guilty as charged.

Typically, the aim behind introducing such terminology is to help our clients make informed decisions when investing in new IT solutions.

At the core, we use these concepts to encourage you—as the system owner—to actively engage in the crucial architectural decisions that must be made when purchasing a new IT solution.

Our hypothesis is that many IT projects go off track because the buyer side evaluates only the feature list. As a result, important nuances of the decision are lost—such as how the chosen platform impacts the overall architecture and the ability to seize future opportunities.

From our side of the table, we unfortunately often see customers choosing the easy route—“PLATFORM X – does it all at half the price”—because it seems cheapest to go with a one-stop shop. And on top of that, all your feature requests are met. Sounds smart, right?

The problem with “PLATFORM X” solutions is that decisions are often made based solely on the feature list and the price tag—without considering the underlying technical conditions for things like scalability, integration, and adaptability. In other words, you end up with a solution that might be sufficient right now, but one that, in a year or two, becomes a bottleneck for your future ambitions.

And it often turns out there is no silver bullet—there’s almost always a need and desire for customizations and configurations to make the new platform fit your specific context.

The expensive lessons

The worst-case scenario is, of course, that you invest valuable time in building a solution that’s outdated before it’s even finished. Maybe your company suddenly needs to enter a new market or support a new channel. If your solution doesn’t support that—or only supports it in a clumsy, inefficient way—you’ll end up paying the price. And just like that, the cost savings you thought you achieved are lost. That’s a costly lesson.

We completely understand that it’s difficult to navigate the jungle of consultant-generated buzzwords. But we still firmly believe: it’s worth the effort to try.

Before we dive into architectural decisions and terminology, it might be helpful to take a step back and look at the bigger picture—a high-level overview of the processes an e-commerce platform is actually meant to support.

After all, we don’t buy IT systems because they have a fancy name or because they’re fun to use (though that certainly helps!). We invest in them because they’re supposed to help us carry out specific tasks and processes.

In that context, ByteByteGo has created an excellent mapping of the typical processes an e-commerce platform supports—to varying degrees depending on the setup:

From the moment a customer visits your site until they have their order in hand, your platform needs to support a wide range of processes, including:

• Product management
• Pricing management
• Displaying products and prices
• Campaign and promotion handling
• Inventory management
• User account management
• Cart and checkout
• Order management
• Payment systems
• Shipping and logistics

These functions—and often many more—are at the core of what an e-commerce platform is meant to support.

Choosing an e-commerce platform is naturally very important, as it becomes central to a wide range of processes, data, and ultimately customer experiences—all factors that are crucial for your sales and branding.

One of the first considerations you should make is the choice between a “monolithic platform” versus a “component-based platform that you build yourselves.”

In industry terms, this is known as the choice between “Integrated Suite” and “Best of Breed,” each of which obviously comes with its own advantages and disadvantages.

There are no inherently right or wrong IT solutions—only wrong architectural choices. A solution that is perfect for one type of business may be hopeless for another.

When we look at the archetypes in the e-commerce architecture market, at one end of the spectrum we find suites—large platforms offering a complete e-commerce package without relying on third-party solutions. All features come bundled in one package.

At the other end of the spectrum are custom-built platforms (“Best of Breed”), where each function on the platform is a standalone solution (e.g., CMS, payment module, CRM, hosting) that is combined into a complete platform. This means the CMS, payment module, CRM, PIM, etc., exchange data via APIs (communication interfaces between systems). In other words, you choose the most suitable system within each “breed” (or “race” in Danish).

Between these two archetypes, there are countless variations. For example, you could have 80% of your functionality within a suite, and build the remaining 20% (e.g., the CMS) into the solution. This can be a good middle ground, ensuring your business needs are met.

Why choose Best of Suite?

• You are willing to compromise on your ability to customize the solution’s functions and can accept the conditions the platform is “born” with from the vendor.
• You want a solution that requires less development effort.
• You want the shortest possible path to launch your solution.

Why choose Best of Breed?

• You want to free yourself from a suite whose technical roadmap (development plan for features and core functions) may not align with your own.
• You understand that technology and your business evolve, and you want the freedom for your e-commerce platform to keep pace on your terms.
• You are willing to invest extra resources upfront to build the platform with the components and services you have selected.
• You can accept a more complex process leading up to your platform’s launch—with the trade-off being a better chance that ongoing costs will be lower.
• You want a platform that can support rapid scaling.

Software is an infinitely flexible material that can be shaped and colored as we wish.

The big question when developing new software usually comes down to how time, cost, and quality impact the degree of freedom you have in choosing a new solution.

If your budget is limited, an all-in-one packaged solution is often a good choice.

To figure out where you fall on this spectrum (whether to choose an all-in-one suite, a tailored Best of Breed approach, or something in between), it’s wise to first consider the technologies you already have in your system landscape.

Just as it can be a good idea to replace old, insufficient technology, it can also be beneficial to hold on to technologies and solutions that are either functionally adequate (some moving parts aren’t always worth replacing “just because you can”) or particularly value-adding.

For example, if you already have both a PIM and an ERP system in your current architecture and want to add a commerce layer on top, it is often premature to invest in a suite where the old solutions either have to be scrapped or have their data migrated into a new all-in-one platform.

When we see companies choosing the Suite path, the most common explanation we hear is that the customer “[…] wants everything gathered in one solution,” which, as mentioned, does have its advantages. That said, it’s usually a bit more expensive because data from the old CMS or PIM must be migrated into the new platform that “does it all,” and that cost must be absorbed.

But let’s be honest—most end up using only about half of the features the new platform offers. That might be fine if you’re willing to pay for functionality you don’t use.

Instead of thinking of your solution as one big one-size-fits-all platform, we want to champion a more experimental approach, which we call the Minimum Viable Product mindset (yes, sorry for another buzzword).

This approach ensures that ONLY the functionality needed here and now is developed. On top of that, you always build further on your existing architecture and systems.

This aligns with the classic prioritization game between features that are “need-to-have” versus “nice-to-have.”

The purpose of the MVP method is to teach ourselves to say, “Let’s launch something that works first, and then we can continue improving the solution based on what we learn from the first iteration.”

If you already have a PIM and an ERP system, let’s simply build a “cart” and a checkout flow on top. Maybe it works initially. Maybe it fails miserably. Either way, we quickly gain experience based on a complete system.

This approach provides flexibility, freedom, and typically also lower costs related to expensive licenses. At the same time, it allows you to test your hypotheses. In other words, you confirm or refute whether your forecasts and requirements are truly reflected in actual use of the solution:

• Are we saving time in the expected processes?
• Did solution XYZ make things easier/more efficient?
• Could we sell X to Y, or were there breakdowns in the process?

By building only what you need with as small an investment as possible, resources are usually freed up. These resources can then be used for testing or adjusting new features.

If you only need a handful of simple features, our experience tells us that an MVP approach is both cheaper and more flexible.

The first steps in the process could therefore be:

1. Map your existing IT landscape — what do you have? What works? What doesn’t work well?
2. How much needs to be replaced? If everything needs replacing, consider the pros and cons of a suite. If your current solutions work, identify the biggest “gaps.”
3. Evaluate possible solution models — is a suite or a tailored platform the most obvious choice?
4. Sketch the new architecture and seek feedback on your vision and ambitions.

Whether you choose a pure Best of Breed solution or base your approach on a complete e-commerce suite that you customize, you should start by doing only just enough to test your most important hypotheses.

At PicoPublish, for example, we have good experience using “Proof of Concepts” as the engine behind an MVP approach. We select a handful of processes, categories, and systems deemed critical to the success of your new platform. Then we build a version of the platform with minimal effort, which we subsequently test. This provides valuable insights and saves you time and money in the long run.

Whether the starting point is a simple commerce solution or a complex multi-market setup, we recommend building the MVP on top of your current architecture.

The right architecture for you is necessarily the one that enables you to seize value-creating opportunities for your business with the fewest resources possible—without compromising your ability to embrace new opportunities that may arise tomorrow.

The risk of purchasing large and expensive standard solutions is that you end up compromising your flexibility, which ultimately hampers your ability to react to changes in the market.

The reality in 2022 is that you must handle more data, more complex data, and support more channels. For this reason, we often recommend an architecture built on MACH principles.

This makes you less vulnerable to competitors in the market who can quickly shift focus and features.

Several providers of suite solutions are, however, modernizing their platforms and have realized they need to enable, for example, toggling modules on and off within the platform. This means companies that have invested heavily in their suite solution won’t be forced to scrap their entire platform.

This discussion about architecture choices isn’t limited to selecting ecommerce platforms.

The exact same principles apply when choosing a CMS—whether you’re building a new customer portal, a new customer service center, or something entirely different. Especially when it comes to CMS, which remains a crucial tool for content editing, we strongly encourage that your editors and their workflows should be the key factor in deciding which CMS to pick.

Again:

The right architecture for you could be based on a free Umbraco CMS offering a user-friendly editor interface—or it could be a DynamicWeb solution where CMS functionality is extended with PIM and ecommerce features.

Once again, our recommendation is to build an MVP, so you don’t end up building the whole “rocket” on the wrong foundation. With an MVP or Proof of Concept, together we get the opportunity to find out:

• How a new solution can improve on the current setup
• What budget is necessary to achieve your goals
• Where the biggest risks (and opportunities) in the project lie
• Which parts of your existing infrastructure should possibly be retained

Choosing a new ecommerce platform isn’t as simple as finding a “one size fits all” solution. When selecting new technology and IT systems, you need to be laser-focused on mapping your needs as precisely as possible so you know exactly what the new solution must be able to do and which features are most important.

First and foremost, be cautious about taking suite providers’ promises at face value—that all their hundreds of features will bring you success. Especially if you actually only need five of those features.

The suite may claim to be “future-proof” because, should the need arise, you can just activate the other 95 features. Unfortunately, we rarely find that it’s that easy.

If you want to future-proof your ecommerce platform, our best advice is to invest in a flexible setup that allows you to add new functionality on your own terms—that is, when you need it, without having to change the entire platform or compromise on functionality. This way, you avoid waiting for major releases from the suite provider you might otherwise be locked into.

In some cases, however, an ecommerce suite can be a good choice. If you have a clear expectation that your needs will remain fairly stable and can accept being less digitally agile, then a suite can be a solid starting point. You get to keep costs low and receive ongoing new features as the suite provider updates their platform.