Key takeaways
- Sustainable business growth requires to successfully adapt the architecture with continuous speed and efficiency
- Organizations need to isolate business complexity with minimal modularity to maximize current maintainability and future flexibility.
- MMA (Minimal Modular Architecture) enables the right compromise of modularity between business needs and organizational capabilities.
- Incremental services distribution helps managing complexity and limits over-engineering by breaking down components only when necessary.
- MMA defines a model of services granularity and the related impacts to help teams articulate transversal trade-offs from design to operations.
Technology-driven approaches often prioritize the latest trends over practicality and business needs, leading to complex and unnecessary architectures. Microservices, for example, have become a buzzword that many adopt without fully understanding their implications.
Businesses need efficient software architecture that maximizes current and future flexibility to remain competitive in our fast-paced and uncertain ecosystem. While modularity alone isolates complexity, Minimal Modular Architecture (MMA) makes it just-in-time.
MMA introduces a defined, structured, and incremental services distribution model that considers the business complexity, architecture implications, and organizational capabilities to enable sustainable business growth.
The approach allows for a more strategic adoption of modular architectures compatible with the concepts of Minimum Viable Architecture and MACH, making the difference between Software Engineering and Quality Engineering.
Defining Minimal Modular Architecture
At its core, MMA is a model that defines the minimal architecture distribution required to isolate the business complexity of a given software service while also taking into account organizational and technical capabilities as well as limitations.
MMA aims to balance the need for modularity with the costs and complexities associated with building and maintaining services. The model does not advocate for a single modularity model for a given organization, but for an incremental distribution based on the services complexity evolution and the availability of the supporting software production systems.
One building block of MMA is to require functional and code modularity independently from downstream technical implementation layers like deployment or infrastructure concerns. A software component with poor design or structure will fail to support the business even with the best in-class technologies.
The MMA framework provides a shared definition of modularity models including for the so-called “Microservices” with multiple interpretations within our industry. For some, a Microservice is an independent function; for others, a service that “fits in your head”, and for others, a collection of independent services for a given application. This ambiguity adds complexity to the already complex subject of architecture.
MMA defines 5 levels of complexity distribution through modularity grains:
- Functions: small and simple pieces of code that perform a specific task or function isolating narrowed complexity.
- Modules: larger pieces of software that can be easily plugged in or removed from the system abstracting functions with a single data store.
- Macroservices: a combination of multiple modules that can be deployed and scaled as a single unit of services and data, usually representing a key domain facet.
- Miniservices: smaller focused services that perform specific business functions and communicate with other services through well-defined interfaces.
- Microservices: small and independently deployable services that work together to form a larger system where defining application boundaries is critical.
Each service distribution model has different impacts on the end-to-end architecture. More granular solutions may seem attractive at first to separate concerns early on, but they require more industrialization and data reconciliation. The MMA model recognizes that microservices are not a one-size-fits-all solution and that the optimal level of modularity varies depending on the specific needs and capabilities of each organization.
The challenge is to pick the most adapted modular architecture that will best isolate the complexity and can be well-supported by the organization. The choice of MMA depends on multiple factors that are found by connecting end-to-end dots within organizations.
The choice of an MMA level requires to clearly articulate:
- Business complexity from customer needs to company’s goals.
- Architecture impacts through end-to-end layers from design to operations.
- Organizational capabilities to build and operate given service distribution levels.
Each of these areas consolidated the enterprise considerations to build and evolve valuable services that will support sustainable business growth.
MMA isolates Business Complexity
The ever-increasing business complexity and uncertainty poses significant challenges for modern software engineering. The need to contain and manage complexity is acute in some parts of the system and not in others, leading to a growing demand for a flexible and adaptable architecture.
The challenge is to reduce the business complexity of specific system areas while keeping it manageable and scalable as a whole. Teams can move quickly and more efficiently if they only need to work on specific modules rather than the entire system.
The key to a successful MMA is to achieve functional decoupling with minimal services distribution.
Functional decoupling is a design approach that emphasizes the separation of concerns, i.e., breaking down complex systems into smaller, independent components that can be developed, tested, and deployed individually. This approach has already gained widespread acceptance in software engineering to reduce complexity, increase flexibility, and improve maintainability.
In the MMA model, focusing first on functional decoupling is a critical component that enables the development of independent, reusable services. These services are designed to work together seamlessly, but they can also be swapped out or replaced without affecting the overall functionality of the system.
MMA articulates Architecture Impacts
One crucial aspect of MMA is to provide the end-to-end perspective when considering service distribution and granularity levels. While a few architects or leaders may have a clearer vision of the entire system, most people have only partial views, and must still consider the big picture in order to make informed decisions.
MMA provides a services distribution model that considers modularity through all the layers of architecture (enterprise, functional to infrastructure) and the software pipeline (design, coding, testing, deployment, operations, observability, security, maintainability, and other “ities.). More than words, the value of MMA is to allow a shared understanding of Microservices that incorporates the different angles.
This big picture enables to correctly assess the implications of adopting a more granular level. An architecture evolving from Modules to Macroservices would have to correctly plan for services communication, data distribution, and deployment industrialization to succeed with the new model and gradually expand it to the most valuable services.
Equipped with a clarity of business drivers with end-to-end architecture impacts, organizations can identify the most suitable MMA. A start-up, for example, would benefit from a Functions or Modules level to support fast iteration with minimal commitment while structuring their core product as the value proposition evolves fast.
But we are still missing one piece of information. The organizational system necessary to build and maintain services in each MMA level is a critical decision criteria to avoid for businesses to rush into the implementation of the Microservices level like Netflix. Most of us can’t afford the same capabilities, and most importantly, we do not need them.
MMA aligns Organizational Capabilities
The success of MMA largely depends on the capability of the organization to implement and maintain it over time. To assess the organizational capability for MMA, we can use the MAMOS model of Quality Engineering, which consists of five key elements: Methods, Architecture, Management, Organization, and Skills.
The model structures five levels of software socio-technological ecosystems which better support different types of business needs and architecture-styles. MAMOS is not a maturity model as the different levels enable it to achieve different objectives. The goal is not to achieve the maximum level but to implement the most adequate level on the 5 axis of the software production system.
MAMOS defines each system area:
- Methods refer to the development and testing practices that support MMA, including shift-left practices starting from the requirements up to the operational ones like retrospective.
- Architecture represents the end-to-end layers of software supporting the business, from functional to infrastructure concerns. It includes the technological choices and organization that as a whole enables the business to serve its users.
- Management aligns the shared vision and the actors to effectively enable the company transformation through leadership, managerial, and change management practices to deliver business goals with the adequate MMA.
- Organization structures the organizational boundaries, roles, and interactions on the target architecture that best support the business needs and enables the adoption of a MMA. It clarifies how different departments and teams should collaborate.
- Skills refers to the strategy of competencies acquisition, retention, and development to best support the socio-technological ecosystem. A mix of internal, external resources at different times and durations is necessary.
MMA benefits from MAMOS by getting a blueprint of the software production system that best supports specific architecture-styles. An MMA based on Macroservices is for example well supported by MAMOS III, and can also be started with MAMOS II and extended with more advanced elements of MAMOS IV.
The choice of MAMOS blueprint must follow the MMA framework order to effectively support the business. A technology-driven approach starting with the driver to implement Microservices would recommend specific MAMOS levels, while if the organization only needs Modules, a lighter and more effective MAMOS system would be sufficient.
MMA for Sustainable Business Growth
The recent case of one AWS team moving back to a modular architecture to achieve its architectural goals is making noise in the industry. More than an individual case, the objective is to take the best decisions in a given context with a clarity of trade-offs.
MMA provides a framework for businesses to balance business needs, complexity, and capabilities for sustainable growth depending on the organization. The defined model also enables to focus the teams’ energy on implementing the best solutions rather than losing time in debates on vocabulary and misunderstandings.
Following the process of the framework is essential to ensure value creation. First, functional decoupling isolates the business complexity, then modularity models clarify the end-to-end impacts, and finally, MAMOS structures and clarifies the software production system necessary for given architectures.
MMA should be used as a model to guide decision making and articulate trade-offs of architecture-styles. The objective is to maximize value creation with the minimalist software production system aligning business and technology drivers.
MMA requires a shift in mindset to thrive in today’s high-paced business environment aligning business and socio-technological systems for sustainable growth. That mindset change is moving from Software Engineering to Quality Engineering.
References
Antoine Craske (2022), Zalando Quality Engineering’s Journey—From Monolith to Microservices. QE Unit.
Uwe Friedrichsen (2021), The microservices fallacy – Part 9. Ufried.