6 min read

Deploying Composable Architecture: The Smooth Shift

Traditional monolithic software was once the backbone of tech but has grown very rigid in the face of today's rapid pace of change. Even if your system  is fully functioning and chugging along, the support for this software is either gone or about to disappear into the digital abyss. On top of that, you've got years, maybe even decades, of tangled business logic and technical debt to crush even the mightiest elephants in the room. And finding and keeping good staff is starting to feel like staffing for a mission to Mars. 

composable architecture 1

In order to stay competitive and thrive, it’s time to modernize your setup. After all, you can't stop the business folks from constantly requesting changes to the system to keep up with the ever-shifting market demands. So, what do you do? 

Introducing the Composable Stack

Composable software stacks have been one of the biggest game-changers in recent years, promising all sorts of benefits. Imagine your eCommerce infrastructure made of building blocks like Legos. Composable architecture for ecommerce is like having these blocks that you can easily assemble and reassemble to create a tailored and flexible system. It means your online platform can swiftly adapt to market changes, customer preferences, and new technologies as they emerge. This agility is vital for today’s companies to thrive in this fast-paced digital landscape. As a result, there has been a huge upsurge in both the adopters and the choices available in the market.  It's all about ensuring that your ecommerce operations are nimble, scalable, and finely tuned to support your growth strategies.  

composable architecture 2

If this all sounds great, you might be wondering how can you make this shift without causing major disruptions to your business? Is it even possible? Yes, the answer is… 

An Iterative Approach

What if there was a way to reach your goals incrementally, all while eliminating disruption and retaining valuable customers you've spent decades nurturing? The secret lies in adopting a systematic, step-by-step approach to breaking apart your monolithic system and rebuilding it a better way. In this approach, each intermediate stage is still a valid functioning platform that allows you to conduct your normal business. Here’s the strategy:  

Planning

Planning is the cornerstone of a successful migration to a composable architecture. It begins with a thorough examination of current pain points with the intent of clearly identifying and defining the goals for the tech and business teams. For example, if many times during the month, you cannot fulfill your orders because inventory is low, your goals should have near real time inventory available to sales reps while placing their orders. And as a process, store personnel should mark inventory as allocated if they are holding it for a customer. 

It’s important to establish key performance indicators (KPIs) to track progress, timelines and budgets to ensure the migration stays on track.  

Architecture

Before diving into the migration towards a composable platform, it's essential to chart a thoughtful architectural roadmap. Imagine it as the blueprints for constructing a new building. It's a collaborative effort where all stakeholders must reach a consensus on various questions regarding the system. Start by selecting the flavor of modern architecture that your team can effectively manage. What is the backend language of choice? What is the front end made of? 

Next, decide on the right size of the software components, which is very crucial as well. Do you want to design a component that handles the warehouse as a single unit, or should you perhaps break that into inventory control, picking and put-away, order management, etc.? The right size will give you the flexibility you need to adapt quickly without too much of the overhead. 

A decision on build vs. buy and tweak needs to be made for each component. For example, will you buy and tweak the warehouse system since there is a composable option available in the market that meets your needs? Or is your business unique enough to merit building it? Who would be the cloud provider hosting these built pieces? 

Once you've got that sorted, it's time for the blueprint. This is where you outline how your new system will be structured, what the different parts will be, and how they'll work together. You should also address specific needs of your business, from scalability and performance to security and data management. It's about creating a clear vision of how your new architecture will align with your business objectives and support future growth. 

Organizational Readiness

Just as important as the architecture itself is the readiness of your organization when you are making the shift to composable platforms as it shapes the entire process. Conway’s law, which states that organizations design systems that mirror their communication structures, underscores this point.  

To illustrate, if you break up your monolith into 5 separate systems, you end up with five systems – increased complexity without the benefits. To truly embrace the benefits, businesses must align their teams, communication channels, and workflows accordingly – breaking down silos and fostering a culture of collaboration. By doing so, individual teams can focus on addressing their specific pain points while collaborating effectively with the rest of the organization. Without this vital organizational readiness, even the most advanced technological solutions may not reach their full potential. 

Reference Implementation

Now that you have all the answers, it’s time to put them to a test. The best practice is to create a small reference implementation or a proof of concept (POC), incorporating all the choices you've made so far - the programming language, tools, component sizes, and more. Your team takes this mini-application from design all the way to production, just like they would for a real application.  

When this is done, it's time to review the experience and incorporate the learning into your process. What worked and what didn't? What decisions do you want to revisit. Even if the POC ends up being a throw-away because of a change in direction, the learnings would be invaluable. It's all about that "fail fast, learn faster" mindset. 

Minimum "Lovable" Project (MVP)

Alright, so you've made the decisions, validated some, tweaked others, and even tossed a few aside in favor of new ones based on lessons learned from the POC. Now, it's time to kick off the real project. It’s important to tackle enough to make a difference but keep it manageable for your team. We call this the Minimum Lovable Project or Minimum Viable Project (MVP).  

Deciding what should be part of the MVP requires careful consideration. You should weigh the business problems the MVP addresses against the complexity of the implementation. This will be the first of many towards your final picture. Based on the results, you can evolve (fix this). The choice may also depend on which part of your organization is ready to take on this challenge. 

Keep in mind that the MVP implementation not only involves the selected functionality but also impacts other interconnected systems. You'll need to set up APIs between these systems first. This approach leaves your system in a functional state once the MVP goes live, ensuring minimal disruption to business operations and continuity. 

Let's break it down with a real-world example. Imagine your first MVP involves swapping out your search engine. Maybe the old search engine was bundled with your eCommerce system (a common scenario). Here's how you might go about launching the new search engine successfully: 

composable architecture 3

  • Create an Abstraction Layer: Start by building an abstraction layer that connects to your legacy search engine's functionality. Expose this through an API gateway. 
  • Update eCommerce UI: Next, update your older eCommerce user interface to make use of this new API abstraction layer. 
  • Select a New Search Provider: Now, it's time to pick a new search provider. You might be considering a cloud-based provider that uses machine learning to adapt to users' preferences. 
  • Implement the API Layer: Develop the API abstraction layer to bridge between your existing search engine and the new cloud-based one. 
  • Testing, Testing, Testing: Test rigorously. Test thoroughly. Make sure everything works as expected. 
  • Go-Live Switch: When you're confident everything's working smoothly, go live by switching from the old search engine to the new cloud-based one in the API gateway. 
  • Emergency Back-Up: If the unexpected happens, don't worry. You can always switch back to the old search engine. 

Think of it as replacing a leaky garden hose – you check the connectors, grab a new one, make the switch, and hang on to the old one until you're absolutely certain the new hose works flawlessly. Simple, isn't it? 

Rinse and Repeat

It's time to reap the benefits by embarking on a continuous journey of improvements. After successfully launching your MVP, you've tasted the advantages of composable architecture. It's worthwhile to conduct a retrospective analysis of the implementation to identify any necessary course corrections. 

The next step is for your team to build upon this foundation, gradually peeling away layers of functionality from the legacy system. You can prioritize these changes based on importance and complexity, ensuring a strategic approach to transformation. Your team can do it all while making sure the transition is as smooth as butter, and they can hit reverse if needed. 

This iterative process allows the system to evolve, adapt, and grow while harnessing the power of composable architecture to its fullest potential. 

The exact sequence of what you want to switch out may depend on how well each system is working in your eCommerce. The various components at a macro-level you might want to consider are: 

  • Identity and access management 
  • Communication - Emails, Texts, etc.  
  • Product Catalog 
  • Shopping Cart
  • Checkout
  • My Account and Orders

Conclusion

The journey from a monolithic architecture to a composable one may appear daunting, but it's a strategic move that can empower your business for long-term success. By adopting a systematic, phased approach, and adhering to best practices, you can modernize your infrastructure while preserving the trust of your valued customers.  

Following a phased and iterative approach and learning from each step, this transformation can be achieved with minimal to no business disruption, incrementally delivering superior user experience to your customers and greater control and agility to your business users. 

At AAXIS, we've helped pilot and driven the transformative power of this strategy in action, and we're here to guide you on your journey to a more resilient, scalable, and adaptable ecommerce platform. The future is composable, and it's within your reach. 

Book an appointment today. 

This article was co-authored by our highly talented and soon to be Chief Technology Officer, Rajeev Hans and our articulate and prolific Chief Science Officer, Naresh Ram. 

From Orders to Satisfaction: The Kibo OMS Advantage

From Orders to Satisfaction: The Kibo OMS Advantage

Modern Order Management Systems (OMS) can make order fulfillment easier, deliver seamless customer experiences, increase profits, reduce costs and...

Read More
Evolving Your Application Architecture to Cloud Platforms

Evolving Your Application Architecture to Cloud Platforms

A lot has changed with respect to software infrastructure in the 13 years since I started working with it professionally. I was hired right out of...

Read More
Empowering Efficiency: Self-Service User Management In B2B Commerce

Empowering Efficiency: Self-Service User Management In B2B Commerce

Today's B2B customers prefer platform self-service over speaking to a sales rep on the phone. And honestly, who can blame them? It's akin to wanting...

Read More