“Build today for tomorrow.”
That’s the challenge of architecting a business platform able to thrive in a digital ecosystem where opportunities must be rapidly captured and scaled.
Organizations must be able to continuously adapt their offerings and operations in an evolving environment where software becomes, if not already being, the business.
Businesses with legacy architectures where all parts are tied together have a critical problem: each adaptation is too costly, slow and painful to capture value on time.
Organizations require to structure the business in granular digital assets that can be much more easily adapted and connected to build a true modular business platform.
Follow the QE Unit for more Quality Engineering from the community.
What is a Modular Business Platform
A platform is an ecosystem that creates value through exchanges between two or more interdependent groups, usually consumers and producers, that become a business platform once these exchanges are monetized.
Building a platform requires to successfully create that network of collaboration through technology. But the starting point of many organizations is to be closed on themselves on their historical business models, connected with a predefined set of users and partners.
When these legacy organizations try to expose services or integrate with partners, they either fail or take too much time due to the mismatch between services contracts that were built for a “one-size-fits-all” process that is too rigid for creating new interactions.
That’s where modularity comes in.
Modularity enables the following advantages:
- Complexity is more manageable
- Ability to better parallel work
- Increased tolerance to uncertainty.
Organizations with a modular architecture structure the business around smaller architectural components that focus on specific functions and data. Each module becomes easier to integrate, simpler to evolve, and with a reduced complexity.
Modularity follows the “divide & conquer”, “separation of concerns” and “high cohesion, low coupling” principles to structure components that have clear functions, interfaces, and that evolve independently from the others.
That capability to change in size and behavior on localized components enable businesses to change with more speed their value proposition with accelerated cycles of learnings. And being a digital business, modular software is a requirement of Quality Engineering.
How Quality Engineering provides Modularity
Quality Engineering is the paradigm constraining the entire software lifecycle to Quality at Speed for continuous value delivery. Its implementation relies on the MAMOS framework where the domain of Architecture provides practices for Modularity.
Modular software starts by the business vision of the modular business platform. Then, the urbanization of domain-driven services comes from the QE Structure. Finally, modular services can be built within a modular monolith architecture and a Monorepo.
Modular services: the scalable granularity of software components
Modular services are software components responsible to perform specific functions on defined data and provide explicit interfaces contracts. What they perform is directly linked to the expected business behavior defined through functional specifications.
Defining the perimeter of modular services becomes more complex as more business functions are needed. The main decision to take is to either change an existing module or to create another one while containing complexity and costs.
Architecture is there to provide the necessary guiding criteria, and like a lot of themes in life, it is a question of equilibrium. An extreme approach to modularity can be beautiful for the design aspect but leading to overly complex and costly integrations.
The goal is to remain in the “region of minimum cost” following the principle of “high cohesion, low coupling”. When there is a hesitation between changing a component over creating a new one, favor reusing a component, to split it later on, only if needed.
It is much easier to decompose a module that became too large rather than incorporate services within the same module due to the costly rework of design. That’s also the reason to start organizing your modular services in a modular monolith architecture.
Modular monolith: the scalable organization of modular services
There are many types of software architecture to choose from when it comes to structuring code components. The legacy practice is to build a monolith that is easy to start with being a single coherent block, but that faces limitations when the complexity arises over time.
The extreme approach is to build a microservices architecture, where all modular services are deployed into independent units of deployment. This choice provides a high scalability at the cost of managing the inherent complexity of communication, automation, and deployment.
None of these choices seem like a satisfactory option especially for an organization that is not yet mature enough, but that still wants the ability to scale. An alternative, the modular monolith is the recommended architecture to implement in Quality Engineering.
A modular monolith consists in building independent software modules (i.e. the “modular” part) that will still be deployed as a single application (i.e. the “monolith”). It is the recommended way to start and scale a codebase.
The major advantage of a modular monolith is the scalability. It is a simple solution to start with, that keeps coding and runtime complexity low, that can grow in the same or to a microservices architecture thanks to the flexibility gained with modularity.
Monorepo: the scalable repository of modular services
Software modules can be stored inside a single repository or multiple repositories, respectively called a Monorepo or a Multirepo. Each model can work depending on its alignment with the architecture, team organization, and engineering maturity.
It can seem natural to store each software module in its own repository to be aligned with a modular architecture. But modularity can be achieved within a single repository with a proper software architecture, and multiple repositories come with significant integration costs.
Choosing a repository architecture can follow the same principle of module granularity: start with a Monorepo, and only later, split independent components if there is a true need identified, and a careful assessment of the associated tradeoffs.
The benefits of starting with a Monorepo is the simplicity that lets the team focus on components modularity. A single repository also enforces a shared visibility and governance to keep a global coherency when the codebase grows in size and complexity.
There are examples of successful organizations using either model. Google is still working with a Monorepo, and other first moved from a Mono to a Multirepo, and Amazon has a Multirepo. All these companies scaled with the common trait of modularity.
Modularity to thrive with Quality Engineering
The ultimate measure of success for a digital business platform is its capability to generate new revenue streams by creating valuable transactions leveraging the interconnectivity of different partners and users.
Digital businesses with modularity increase their capability to change the business in short cycles and to connect with multiple partners of today and tomorrow. That’s a first strong advantage in an ecosystem of uncertainty and low predictability.
Modularity also provides a way to manage the business and technology complexity that inevitably grows. As a result, organizations can keep iterating with speed in the long run while others are trying to understand how things work and fixing bugs.
The other significant advantage of modularity is to enable parallel changes in line with the organization’s capacity. Companies can progressively accelerate their rate of software delivery to progressively reach a state of Quality at Speed software.
That’s true scalability.
References
Design Rules, Volume 1 The Power of Modularity.
Software Engineering-Modularity, 1000sourcecodes.
Architecting for Reliable Scalability, AWS Architecture.
Tobias Martin, All You Need to Know About Modularization. Modular Management.
Oliver Schön, Business Model Modularity –A Way to Gain Strategic Flexibility? Springer.
Platforms and modularity: Setup for success, McKinsey & Company.
Craig Mathews, Building A Modular Business. Big Thinkin.