In our third and final piece on composable architecture, we look at how composable architecture increases your development speed and throughput. We also explore how teams can work more efficiently with composable architecture.
Check out Part 1 and Part 2 of this blog post series.
The Platform-Based Approach in the Modern Digital Age
When you consider modern retail, your digital presence is much more than just an ecommerce site. The full journey contains many touchpoints, such as self-service, point of sale (POS), in-store displays, click & collect, mobile apps, customer support, after-sales service, and more. Each one of these systems grows more sophisticated by the day. A challenge emerges when one system supports too many dependencies, such as your ERP system or your ecommerce platform.
For our context, the platform-based approach refers to an ecommerce solution centered around an established platform with a large set of out-of-the-box features that can be tailored to meet business needs.
Technically, all solutions can be delivered from a single commerce platform. But with the growing complexity and needs of a modern ecommerce store, the platform-based approach faces several obstacles:
- The platform may become bloated when it takes on tasks that are no longer strictly related to commerce.
- Changing a touchpoint always requires a change to the ecommerce platform, which adds extra steps and complexity to the workflow.
- You may need to route information via the ecommerce platform that it doesn’t otherwise need, which robs processing power from what your ecommerce system should be doing – taking orders.
- The ecommerce platform becomes the single point of failure. If it’s down, none of your other systems will work. However, please note that even in the case of microservices architecture, you must plan and design for “partial failure” and ensure your system can still provide a meaningful experience to your customers when some functionality is not accessible.
Microservices Architecture and the Modern Ecommerce Solution
We refer to “composable architecture” and “microservices architecture” interchangeably. To reiterate, composable architecture is based on a microservices concept, wherein the different services and features are divided into agnostic building blocks that can operate independently from each other.
The composable approach allows you to work on various elements independently from one another and scale better. For example, a project to improve in-store displays may call for specialized tools. If your solution is platform-based, you may face a challenge if your ecommerce platform doesn’t support the tools required.
However, with a microservices approach, the in-store display scenario plays out differently. Your commerce engine provides only transactional capabilities to your in-store displays while the rest remains uncoupled. This means content could move to the in-store displays directly without having to go through your commerce platform, and you’re free to implement new tools and features.
Let’s take a look at different areas of the modern ecommerce ecosystem where microservices architecture provides benefits.
1. Microservices Architecture: Trends
Many business opportunities today are more experimental in nature, such as “magic mirrors” that help customers visualize themselves wearing products via smart displays, or augmented reality (AR) technology that allows customers to “project” products into their surroundings.
Some of these trends turn into long-term features, while others pass as a fad or don’t resonate with your customers. What’s certain is that digital commerce trends will keep popping up, as technology becomes more advanced every day. Large corporations like Amazon set the standard for ease of usage, and customers quickly come to expect the latest features from their favorite retailers and brands.
However, don’t invest in an ecommerce platform simply to support trends that won’t stick around. Microservices architecture allows for easy experimentation and keeps components lightweight and discardable. Above all, the microservices approach gives your solution room to grow, scale, and develop further in the future. No one can predict what three ecommerce features customers will love the most in a decade, but microservices architecture ensures you can pivot your solution to meet the needs of your customers.
2. Microservices Architecture: PIM, POS, and the Commerce Engine
A traditional platform-based approach usually has the commerce engine at the “heart” of the solution, with all other systems and components, such as the product information management (PIM) system and the point of sale (POS) system connected to it. Apart from putting unwarranted stress on the commerce engine, this approach also locks all systems into a tight-knit integration that’s difficult to “untangle” when the time comes to swap out a component.
Microservices architecture allows for a lightweight integration and avoids placing extra load on the commerce platform. Your PIM system could feed product information directly into your POS without ever having to pass through the commerce engine. This method also allows for more flexibility. If you want to switch out your PIM, POS, or commerce engine, each component can be replaced more easily without having to rebuild every integration.
3. Microservices Architecture: Pricing Logic
Many ecommerce vendors understand that pricing logic only goes so far before complications become a hindrance. When different systems require pricing information, reimplementing price rules can be complex, expensive, and error-prone, due to details such as rounding, discounts, taxes, and more. In short, it may not be feasible to store all complex price combinations.
With microservices architecture, pricing logic can be a dedicated service that all other systems consume, thus avoiding the reimplementation of logic, duplication of data, or inconsistencies between systems.
Teamwork: Microservices vs Platform-based
Now that we’ve reviewed the benefits of microservices architecture within your ecommerce solution, let’s take a look at how the approach can positively impact teamwork and lead to a boost in development speed and throughput.
How Teams Work on Platform-Based Architecture
With classic platform-based architecture, there’s generally one team working on the platform, across all functionalities. While this creates clear accountability and a good overview of the system, it can also have drawbacks since the whole system is intertwined with dependencies.
Let’s use a single development team working on a single platform as an example.
In such a scenario, a generalist team works across the entire solution and coordinates the backlog, with features being sequenced across different areas. Because the workstream is often not owned by the development team, they prioritize the incoming “tickets,” and not the business domain and outcome. This constant reprioritization due to the endless demand on businesses to adapt can result in significant unfinished work in the system, resulting in wasted effort.
In very small organizations, the “team” might own the outcome, but usually, as soon as organizations start to grow, the business outcome and technical delivery receive separate ownership. An organization may choose to have multiple, cross-functional teams delivering to a single platform. This concept allows for less broad experience across all the areas of the platform, with each team specializing in one area.
But while each team holds more control over their backlog, this model still requires strong coordination and dependency between teams due to the release to a single system. The release process encourages sequencing or batching of work, which again encourages unfinished work to pile up.
Additionally, as to-be-released work is rearranged several times before launch, the testing effort often increases. Unfortunately, the required testing is often not performed. This all culminates in wasted time, effort, and money for companies.
How Teams Work on Microservices Architecture
In contrast, microservices architecture allows you to divide members into multiple teams, or even work with multiple partners, with a clear separation of responsibilities. Digital giants like Facebook and Amazon were built using similar concepts because it allowed them to scale development throughput. Amazon famously called their teams “two-pizza teams,” in reference to how small or big they made their teams.
With microservices architecture, multiple teams each deliver their own component. The teams remain independent of each other, and each team has its own release process and cadence. Every team delivers to separate systems in the overall solution, without the need to coordinate releases with one another, because no one else delivers to a given team’s component.
Teams may “consume” the services of each other’s components; for example, the content team may want to link content to promotions. They may need information about ongoing promotions from the promotions service, to carry out their objective. The frontend can then pick relevant content based on a promotion that applies to a given page.
While multiple release processes will likely not be “cheaper” in the short term, they will result in higher development speed and throughput, and less unfinished work in the system. The benefit outweighs the cost and brings savings with it. A fast er time-to-market for new functionality and services is certainly a win-win for all!
Microservices Architecture Team Possibility: Autonomous Product Teams
Lastly, let’s examine one way of working with teams within microservices architecture.
To build on the concept of multiple teams, microservices architecture allows for “autonomous product teams.” Please note that this is just an example and not the only way of working with microservices architecture.
Autonomous product teams don’t have strictly software or IT teams that work on various business goals. Rather, each team represents one business goal. In most cases, a team is formed by people who identified a specific business opportunity.
These teams are entirely autonomous, with all the roles they need to achieve their intended outcome, both technical and non-technical. They don’t report to someone else for direction and they are not dependent on anyone else, including approval on what to work on or how to achieve their objectives. They are primarily measured by their outcome.
Autonomous teams are:
- Cross-functional in a broader sense than what we often see in IT teams. They are not just in tech roles but tax lawyers, logistics experts, supply-chain experts, product designers, and more. The teams contain everyone that is needed to make that business area a success.
- Specialized and they work on specific features, like last-mile fulfillment, promotions, personalization, loyalty program, in-store tech, and more.
- Domain experts. Historically most software development thought leaders were domain experts first. Software was “just” the tool. Solving a domain problem was the end goal. In the IT industry today, we mostly do not know the domain. We learn as much as is needed but it comes second to tech and software development. Building teams based on domain expertise and composing their work together brings us closer to the customer and the problem. Even technical roles, who may not be domain experts to start with, have a strong incentive to become experts in the specific domain because such teams tend to be long-lived around that specific domain. Of course, the team is measured on the outcome within that domain (rather than by technical achievements). In long-lived engagements, it makes sense to take ownership. In teams that often change what they focus on, it’s harder to take ownership.
Key Takeaways
To sum it up, microservices architecture offers much more than simply the ability to scale and use best-of-breed tools. The approach allows for efficiency within teams, and in the ways that teams work together. Autonomous teams are minimally dependent on other teams, and therefore, result in fast, concurrent work being executed with low or no coordination overhead. Again, this method may not cost less with extra administrative overhead, but it’s worth it due to the extra speed and throughput.
While it’s a big commitment to make the switch to microservices architecture, working with experts can help you decide if the switch is worth it. The right partner can ensure you have experts to help guide you through the process and select the best way forward and the best tools for your business.
If you need expert advice on microservices architecture, don’t hesitate to book a time with our experts today. With over 14 years of experience in driving success in digital commerce solutions and creating brilliant customer experiences, we have a deep understanding of ecommerce. We’ve already helped numerous clients implement a headless and microservices architecture to scale their business and meet their customers with the best possible customer experiences across the board.
Let’s talk about how we can take your digital commerce business to the next level!
