December 8th, 2021
6 min
Daniel MüllerInnovating with MACH (Part 1): Business Models with Microservices
Should digital transformation be business-driven or tech-driven? Can I build and operate a great platform without a large team? Should my business model be based on the capabilities of the platform? We’ve all pondered these questions! 81% of global IT decision-makers plan to add MACH elements to their architecture soon. But is it for the right reasons?
Microservices architectures enable holistic business models and platform features. Let’s see how.
Focus on Individual Business Capabilities
Digital leaders need software professionals who solve business problems. Organisations need a constantly evolving platform to run their business. This top-down thinking, where business goals align with the development, is possible with Microservices. You can systematically break down your business goals into several smaller independent services.
This approach doesn’t tie into a specific collection of practices, technology, process, or tools. Instead, each packaged business capability runs its operation and has separate logic, scopes, databases, a shared data source, and specific functions.
Businesses can shape their domains and processes, focus on testing business features, and make them available quickly. In other words, individual capabilities of a platform, like search, catalogue, product pricing, inventory, shipping, delivery, customer account, promotions, cart, etc., can be updated, deployed, and scaled independently. This domain-driven design defines limiting use cases based on business needs. This helps prioritise the business use case over the available technology.
The first set of questions should be – What is unique about a particular domain? What are the use cases, and how do you design them?
MACH technologies – Microservices, API-first, Cloud-native, and Headless – mark a shift away from rigid, monolithic technology to modern composable platforms. Individual or multiple microservices are deployed to form the foundation of packaged business capabilities in a MACH platform. Teams can be more creative and focus on developing business functionality instead of creating logic and writing lengthy code. Have a look at this utility submetering use case from one of our projects:
Top-Down-Approach to Submetering Packaged Business Capability
- The business defines the requirements in the submetering domain as Packaged Business Capabilities (PBCs) based on real-world consumptions, costs, calculations, and other benchmarks.
- This flows into the technical architecture of the PBCs, where individual microservices and functions access shared data. We used the CQRS pattern to implement this sub-metering use case.
- Future capabilities for the business can also be included and can be refined for technical and non-functional requirements. For example, increasing availability and performance via CQRS.
Individual or Overlapping teams Yet Independent Deliveries
Microservices lets you define many domains for your platform and give ownership to the right groups, yet each domain doesn’t need a separate team. One team can work on multiple domains and shift their focus sprint-wise to different domains in the platform.
Not every business expects to be a ‘Netflix’, which is out to build the best platform in the history of platforms. They might not have the budget for it, nor the need. They are not leaders in tech but need tech to support their business model. They mostly work around limited resources and focus on features step by step instead of multiple stages together. We’ve done this with many of our projects and had good results. Even if it’s just one team, each service can be built using the most appropriate technology/language/framework without compromising its ability to communicate with another service. This way, many business initiatives can run in parallel.
Changes to a microservice don’t depend on other teams, and the code goes to production much faster.
Loosely Coupled Systems, Selectively Changed or Scaled
Microservices help scale business domains separately and independently, giving a lot of flexibility to businesses. Since systems are loosely coupled, incorporating new business models becomes easy as capabilities can be built quickly and selectively changed or scaled. The entire system doesn’t need to be updated. You can add new features, upgrades, data sources, and frameworks more quickly and without many resources.
Trying out POCs with different suppliers is easy to evaluate the best option for a good MVP. This reduces overall cost in the future, as you’re already selecting the best UX upfront.
Frequent changes are possible since systems are containerised into microservices. The team can quickly adapt to new business requirements, change existing functionalities quickly, and onboard new resources. Test cases for these individual business-focused use cases can be defined and automated. This agility boost creates trust in the development team, giving them the liberty to fail fast and change fast.
Frequent Releases without Affecting the Existing System
How are you releasing your platform features and upgrades? The answer to this question will likely reveal if you’re doing mature microservices.
You could use branching strategies like Git flow or Gitlab flow, but we have found lightweight trunk-based development to be the best in our projects. Microservices architecture provides better agility in deploying features and upgrades when needed. Deployment cycles also have a shorter build time and testing phase. These releases can be tied to realising business goals since individual business features are built as independent microservices.
Every commit should ideally result in a production deployment. This needs a shift in the developer mindset. It will be hard at first for developers who are used to classical flows, like Git flow, as every commit must be production-ready, making Test Driven Development all the more critical. Additionally, every developer must complete at least one commit every day.
New features can be toggled on/off, but it’s essential to toggle business features and not simply technical components. For example, you could show (or not show) a new part of a page without worrying about the backend systems. Selectively enable features for some beta users without taking the entire platform offline. Get early feedback from your closest customers to get an even better product by the time it reaches the rest of your customers. We have seen both approaches, where each team could define their release independently and where teams have looked to a centrally defined release structure. Guidance on microservices onboarding, system governance, and baked-in security always helps teams.
If you’d like to explore how microservices architecture can impact your business, feel free to get in touch. You don’t have to start from scratch if you use the B2B Accelerator+, with its pre-built use cases and standard features built as microservices and a Kubernetes accelerator to take you to market faster.
