Composable Architecture Use Case / Healthcare B2B Marketplace

Composable architecture is often the “go to” suggestion for many businesses but… why is that? Instead of talking about the vague benefits of ‘composability’, let’s talk real world value. Specifically, this composability means that we can implement entirely new channels, using existing infrastructure and/or core necessities, while maintaining high performance.

For example… a company selling through its own platforms could take the leap to running their own marketplace, which in turn helps them establish a firmer presence in the market, expand their sales channels and even sell a wider range of products to existing customers. This is especially tempting when such dedication options don’t currently exist in the market… there’s a real chance to be a leader.

With the rising popularity of marketplaces – and the increasing awareness of industry-specific marketplaces – paired with the rapid digitalization of previously analogue industries, such as the healthcare sector, this is a growing area of business that is worth exploring in more detail.

To better show this, we wanted to explore a potential, real-life use case. Through this, we hope to demonstrate our thought processes, particularly regarding the technological options available, how we made our decisions and how we would implement the final choice.

Our Example: A Pharmaceutical Marketplace

There are many industries where companies need to purchase goods from dedicated providers, yet at the same time, still have to choose from a vast range of suppliers. We decided to focus on the Pharmaceutical sector, although this is by far not the only scenario that exists.

In this sector, there is a lot of activity:

• A typical pharmacy needs to buy hundreds, if not thousands, of medical-grade supplies from very specific vendors.
• These vendors, in turn, also need to sell to various pharmaceutical stores.
• Like any B2B sector, there is often a unique pricing strategy for each buyer, too, since the largest companies may get better deals due to the vendor determining where to offer better price margins at larger scales.

Because of this, the direct need for a centralized marketplace to facilitate all of these deals in one place – whilst still meeting the individual needs of each vendor and buyer – was clear.

Rather than a new business, we’re assuming that one pharmaceutical provider wishes to take the initiative. This is a common occurrence when it comes to marketplaces, as it offers a number of key benefits:

• As the marketplace owner, you can determine price margins, and make profits even on sales of products outside your own range.
• By bringing other suppliers, even competitors, to your marketplace, you increase overall visibility and market penetration.
• With a wider range of products, the marketplace has a broader appeal for potential customers, increasing visibility for all providers.
• This is supported by catalog specific assortment, which can also cater to non-medical products.
• Likewise, by expanding into non-medical areas, the marketplace owner can sell their existing goods to new industries. For example, by meeting the wider needs of non-pharmacy businesses, such as veterinarians, the company can expand the sales of its existing goods.
• Selling more products gives the marketplace a competitive advantage over singular-branded stores, putting the initial marketplace owner in a strategic position.

Project Aims

With the above scenario in mind, we assumed the following key goals and objectives:

• To create a platform that enabled pharmacists to buy non-pharmaceutical goods
• To develop a platform that can increase the sales range of pharmacies and become the core platform for the market.
• To keep the technology flexible and scalable, based on the additional, future objectives.

And in terms of features, we identified the following:

• Individual product and price catalogues as the customer level within the marketplace.
• Implemented logic that automatically calculates price margins. Pharmacies should be able to place orders in the marketplace panel with the assigned margin, rather than the initial price from the supplier.
• A secondary panel for suppliers to manage their product catalogue and orders.
• API access for both suppliers and purchasers, who many prefer to manage data in their own internal systems.

Of course, the client also has future goals as well. Likely, this will involve opening sales outside of the pharmaceutical market, through a couple of approaches:

• First, we are assuming that the marketplace itself can expand to include additional products that are not necessarily pharmaceutical or medical in nature, but are nonetheless purchased by pharmacies. This includes goods like tissues, gloves, masks and cleaning products, for instance. Whilst non-pharmaceutical in nature, they are nonetheless essential for the business to function.
• Secondly, we are assuming that such a marketplace could be include businesses that carry smaller assortments of pharmaceutical products, such as orthopaedic stores and veterinary practices. This helps to further expand sales opportunities.
• Finally, we also want to consider the possibility of taking the general architecture and applying it to other businesses completely. For this open ended approach, flexibility is essential to adapt to future business goals, or even new sales channels, without reducing performance or requiring extensive changes.

Design Challenges

Based on the above goals, we identified a number of key design challenges that need to be addressed:

• Individual product catalogue: Not all pharmacies see everything, especially in the context of pharmaceutical products, so this needs to be improved.
• Individual price catalogue: The company needs to be able to set individual prices per pharmacy, with logic that automatically calculates price margins from the ERP system.
• Flexible architecture: Any solution implemented needs to be flexible, supporting scaling and future growth.
• Quick time-to-market: A short lead time for the MVP version is preferable.
• Suppliers dashboard: The company’s suppliers needed a dashboard to manage products, prices, inventory and orders, all in one place. Ideally, such data should be accessible via API.
• Margin calculations: Although suppliers set the prices, the marketplace owner should be ablet to set margins on products of specific suppliers and/or specific pharmacies. This logic differs from that seen in traditional sales or even in most marketplace solutions. Because of this, most ready-made marketplace panels, such a Mirakl, do not work this way. They enable suppliers to set prices and for the panel/marketplace over to earn a % of sales in the traditional approach.

How to Achieve It

After this lengthy exploration of the needs and objectives, we then have to determine the best solution. When it comes to e-commerce platforms, there are a number of market-leading options to choose from, such a Spryker, Shopware, and Adobe Commerce. For these particular purposes, we focused on two potential directions. Magento is a more affordable option that has some key challenges, while commercetools provides a composable, modular approach more in line with scalable needs, albeit with a higher licensing cost.

With this in mind, we then considered the following 4 options, based on these two platforms plus some supporting tools, such as Mirakl (as a reliable marketplace panel for vendors) and Pimcore (as a reliable PIM).

As you will see, we’ve started to investigate possible architecture from the easiest and cheapest approach, with the assumptions that a potential business would accept the inherent limitations of such an option. But if a specific solution doesn’t meet the main goals, we continue find a more advance solution. And, in the end, we found a solution which meets both the business and technical requirements.

Option 1 / Standard Magento + Mirakl

In the first approach, we considered using Magento for both the frontend and backend, with Mirakl handling supplier management.  Magento, as an all-in-one monolith, had strong potential, so we wanted to consider it.

Pros

• Time: This offers the shortest time-to-market of all three scenarios
• Low license costs: With this approach, the investor only pays for Mirakl license, without the need to pay for Magento (assuming that we use the free, open source version).

Cons

• Lack of individual price catalogue + product catalogue: Neither Magento or Mirakl provide this.
• Lack of margin calculations: In this approach, the investor is not able to implement the logic necessary for individual margin calculations.

Overall, we felt this setup fell short in managing individualized product catalogues and pricing strategies. While the cheapest, it failed to meet any key objectives outside of time-to-market, and did not provide the investor with a future-proof or adaptable architecture.

Option 2 / Custom Magento + Mirakl

Next, we considered a more tailored approach, customizing Magento to meet more of the specific requirements for individual product catalogues.

Pros

• Individual catalogue: In this approach, we are able to meet some of the previous drawbacks of the first scenario.
• Low license costs: Assuming we once again use the open source version of Magento, the investor only pays for the Mirakl license.

Cons

• Lack of individual prices per pharmacy: Due to Mirakl’s limitations and adhering to strict integrations between Magento & Mirakl, it’s not possible to provide pharmacies with their own, tailored pricing.
• Higher implementation costs: Due to the increased customization, this scenario will take more time, and will thus cost more.
• Less flexible architecture: By overwriting Magento, we make the architecture much less adaptable for future developments.
• Lack of margin calculations: Once again, the investor will not be able to implement the logic necessary for individual margin calculations.

Overall, while this method would let us implement the catalogue, it still faced some significant limitations. What’s more, alongside a higher cost and a slower development time, this architecture is less flexible due to the extensive customization needed.

Option 3 / commercetools + Mirakl

After considering the potential of Magento, let’s not look at using a flexible, composable solution that might give us an advantage through headless modularity.

Pros

• Individual pricing catalogue: commercetools helps us to implement the necessary pricing catalogue.
• Greater architecture flexibility: Thanks to Commercetool’s microservice architecture, as well as the separation of the frontend and backend, we are able to ensure greater adaptability in the architecture.

Cons

• Lack of margin calculations: At a glance, this is once again not possible. It is possible to implement the margin logic outside of Mirakl, before the latter sends the order, but this would involve a complicated process of calculating prices, taxes and subsequent settlements with suppliers.
• Licensing costs: In this version, the investor pays not only for Mirakl, but also for commercetools.
• Higher implementation costs: With the inclusion of Commerce tools, the development costs are higher than the first two options.

The key advantage of commercetools is its modular, composable approach. This meant that we could start with the essential core, rather than trying to break a monolith, and add the micro applications and features we need in line with MACH principles. This would be scalable and significantly more future-proof.

Of course, the downside to this is that some key logic was not implemented out of the box. Rather than creating this from scratch, we can continue to use Mirakl, as it is built with many of our needs in mind.

Option 4 / commercetools + Pimcore

Finally, we considered using commercetools and Pimcore. The implementation of a Product Information Management (PIM) system, when paired with commercetools, would meet more of the objectives. Rolled out in a phased approach, it would keep the investor flexible, moving from an MVP to wider functionality over time.

Pros

• Licensing costs: In this option, particularly when compared to the previous, we’re only paying for the commercetools license. If we don’t use the Community Edition of Pimcore, we also need to add an additional license. However, our intended goals are achievable on the freemium license.
• Individual product catalogues & pricing catalogues: This is the only proposal that provides both individual product and pricing needs.
• Margin calculations: Thanks to the use of commercetools in the backend, we can finally calculate margins on an individual level. Suppliers have the ability to add specific prices in commercetools’ panel, but it is the marketplace logic microservices that will calculate the appropriate final prices based on the configured margin by the marketplace operator. Commercetools allows for the creation and management of flexible pricing rules, which enables the precise adjustment of margins for specific suppliers and customers, providing greater control and the ability to personalize the offer.
• Phased deployment: Because commercetools is composable, we do not need to implement an entire monolith. We can focus on MVP functionalities and then expand with additional features later, as necessary.

Cons

• High implementation costs: Due to the nature of this scenario, it has the highest development costs of all three options. However, this can be mitigated by dividing the implementation into stages, based on the priority of functionalities, to spread the costs over the wider process.
• Unique logic required: This approach requires us to write unique logic for the Suppler Panel at the level of different systems, as well as the settlement process between marketplace investors and suppliers.
• Providers work on 2 systems: Vendors will end up working on two systems, although we can always consider the option of embedding the panel of one system into the other, further utilizing Single Sign-On (SSO) functionality so suppliers can use the same credentials to access both systems.

In option 3, we concluded that commercetools and Mirakl would enable a fast implementation and meet the key MVP needs, but it would struggle to provide margin calculations, whilst also adding more license costs. The choice of Pimcore over the latter would help alleviate this: it’s open-source and can be used on a freemium tier.

We estimate that we can keep to Pimcore’s community edition, helping to avoid adding an additional license fee into the mix.

Commercetools in More Detail

After some consideration, we opted for the forth scenario, using commercetools and Pimcore.

Composable Architecture

One of the biggest benefits of commercetools, and the overall composable architecture approach, is that it lets us deliver the core architecture first, and then expand. This is in contrast to monolithic platforms, where we have to implement the entire platform all at once.

PIM

The Product Information Management (PIM) tool helps provide relevant product data where it needs to go. Because it uses API, it fits into our composable approach, allowing both the importing and exporting of required data. This provides a key benefit for merchants, as well as helping the client to have data on both the marketplace and their own e-commerce platform, without unnecessarily duplicating workloads.

As mentioned earlier, this 4^th scenario does come with some higher costs compared to earlier options. In order to reduce this, as well as provide a faster time-to-market and implement the unique logic effectively, we recommend dividing the project into 3 distinct phases. This will enable the marketplace to get up and running – and earning – faster, albeit with limited features, with the extended functionalities added progressively.

Phase 1

The first phase to deliver the basic implementation of the marketplace which, for the time being, would be fully managed on the client’s side. We would implement the e-commerce platform – commercetools – and connect it directly to the company’s existing ERP system. While this would require marketplace logic and API, we could effectively utilize existing data from the ERP, such as inventory, prices and orders, to get the marketplace functional.

This would mean that everything is run through the client’s side, so individual merchants can’t manage their own products, prices, stock levels or orders. The goal is to get a functional MVP and them quickly implement these features in the later phases. This is not as bad as it sounds: remember that we’re making a new marketplace here, so the marketplace creator can be selective in their choice of first vendors.

Because we are integrating the commercetools marketplace via API, the client’s existing e-commerce service is unaffected and continues to operate.

The benefits at this stage are:

• A quicker delivery of a functional marketplace in order to gain traction in the sector.
• Immediate benefits from the headless approach offered by commercetools.

Phase 2

In the second phase, we need to implement more of the required functionalities. We would do this by implementing Pimcore, which will take existing data from the ERP and, together with any new data, send it to the same, existing marketplace logic.

The key addition here is Pimcore, through which other merchants can manage their own products. Prices and stock levels, meanwhile, can be edited in the commercetools panel.

This way, more details are being sent to commercetools, where we can build a panel in the backend for suppliers. With this, merchants can also manage their stock, prices and orders, delivering more of the key functionalities.

The benefits at this stage are:

• Giving greater freedom and accessibility to merchants.
• Enabling all products on the marketplace to have accurate stock levels and details, regardless of merchant.
• We also have the marketplace features in place for vendors, the marketplace owner and the end user.

Phase 3

In the third and final step (not counting ongoing maintenance and future plans), we can integrate  the e-commerce platform and marketplace together. By doing this, the client’s own pharmacy products are directly implemented as marketplace provider, streamlining their own internal efforts.

This is done in such a way that the combined platform and marketplace gets information directly from commercetools, with a singular backend marketplace and panel, which is in turn derived from the same marketplace logic already established.

The benefits at this stage are:

• The client’s own e-commerce platform and marketplace are fully integrated, so they don’t need to maintain separate sets of products and associated data.
• As such, their team saves significant amounts of time, whilst still gaining all the advantages of the new marketplace platform.
• Now that we’ve moved from 2 separate platforms (the e-commerce and marketplace) to one platform meeting both needs, we’ve reduced ongoing costs.

Conclusions

We hope that, through this, you can gain a better understanding of how different technologies support your transformation goals. Both commercetools and Magento have strong advantages, and we could meet the most immediate needs with both.

However, when looking at the finer, long-term needs, in our opinion, one direction became much more suitable. When advising clients, we need to think about both the short term and long term goals, presenting all of the options. This is why the choice of technology is strategically crucial for any organization. Once such an advanced system is developed, this choice will realistically impact future growth. For example, choosing Magento in this case would meet immediate needs, but at the cost of future problems and a slower pace of growth due to its less flexible nature.

We believe in being honest at all times so, whilst it may seem like a strong sell, we’re trying to look after your long term perspectives. In an increasingly digital world, these foundations only become more vital. Better to invest now then have to rip these foundations out a few years down the line.

For example, in this use case, we could summarize the 4 potential options thusly.

Want to Know More?

Our exploration here is only a top level look at the different architecture options available. However, for the last option, we’ve included some more in-depth diagrams and information here.

If you have any questions – we’re here to help!