How many organizations really appreciate that digital transformation should be business-driven and not technology-driven? Can you build and operate a great platform without a large team? Does your business model always have to be based on the capabilities of your platform? These are top-of-mind questions among business leaders. 81% of global IT decision-makers plan to add MACH elements to their architecture soon. MACH technologies – Microservices, API-first, Cloud-native, and Headless – marks a shift away from rigid, monolithic technology to modern composable platforms. In this 4-part article series, we’ll focus on how MACH enables a well-organized digital structure for business capabilities for current and future use cases. In the first installment, we look at how microservices architectures help businesses holistically develop platforms and features.
Focus on Individual Business Capabilities
Digital leaders need software professionals who solve business problems. Organizations 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 need systems that break down your business goals into several smaller independent services.
This approach doesn’t tie you into a specific collection of practices, technology, process, or tools. Instead, each packaged business capability runs its process 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. By this, we mean that you can plan for individual flows in your platform, like search, catalog, product pricing, inventory, shipping, delivery, customer account, promotions, cart, etc. These business packages can be updated, deployed, and scaled independently. This domain-driven-design defines limiting use cases, understanding the business by abstracting the technology. The first question should be – What is unique about a particular domain? What are the use cases, and how do you design them? And more.
Individual microservices or multiple microservices are deployed together 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
The microservice architecture fits into the agile development model, as it brings together development, infrastructure, DevOps, and cloud teams. 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 like 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 have to 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 we’ve 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 code goes to production much faster.
Loosely Coupled Systems, Selectively Changed or Scaled
Microservices help scale business domains separately and independently, giving a lot more flexibility to businesses. Digital transformation doesn’t have to be technology-driven. Systems are loosely coupled, so they can be built quickly and selectively changed or scaled to accommodate new business models without having to change the backend. The entire system does not need to be upgraded to enable a new business capability. You can add new features, upgrades, data sources, frameworks, and more quickly and without much resources. Also, it is very easy to try out POCs with different suppliers 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.
Additionally, frequent changes are possible due to systems being containerized into multiple microservices. This makes it easier for the team to 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 the Git flow or Gitlab flow, but we have found that lightweight trunk-based development to be the best in our projects. Microservices architecture provides better agility in deploying features and upgrades as and when needed. Deployment cycles also have a shorter build time and testing phase. These releases can be tied to realizing 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 important. 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, and 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. What helps is to give teams guidance on microservices onboarding, system governance, and baked-in security.
Businesses benefit from the agility to quickly deliver new products, functions, and features, the reusable architecture covering most business use cases, and the independently deployable components for piloting and prototyping. If you’d like to explore how microservices architecture can create an impact for 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. In the next installment of the MACH Powered Innovation series, we’ll take a look at the business value of API-first development.
Senior Solutions Architect