How modularity enables Agility

Modularity

Broadly speaking, in software design, modularity refers to a logical partitioning of the sysem that allows complex software to be manageable for the purpose of implementation and maintenance. In other word when we speak about modularity we already assume (logical) some sort of partitioniong of the entire system into components components or *modules. Those modules are in best case loosely coupled and highly cohesive.

A good example of a loosely coupled, highly cohesive architecture is s.c. Unix philosophy, which is summarized as by McIlroy¹ as follows:

This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

Todays Microservices trend pushed that idea again in the foreground so people begin reasoning about such things again. But what that have to do with Agility? Let’s remember some of the 12 principles behind the agile manifesto first.

Principles from the Agile Manifesto (excerpt)

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.

Let me summarize that as:

The ability to deliver software systems constantly, every day, several times a day, or if you need, at any time it is needed - is a agile thing at it’s core!

Having such speed and flexibility in the delivery to the customers needs, is the current maximum of the Feedback Loop you can theoretically get! But to achive that you need to start with organizational change, people miondset etc. I’m fully aware of that, and you should start wirh that! But this article is nor about that, i’m assuming we’re thinking about next step. And the second steps that experinced agile Engineers/Architects are dealing with is the quiestion: How to enable our teams to move fast and not to be blocked by system design, engineering processes and tooling created in a different paradigms? And this is agaain broad topic, so let’s focus on Software Architecture Style and Technical decisions you and your organization make.

Modularity is agile

Speaking of technical design, we need to think about which type of systems are more suitable for frequent delivery. It’s obvious to me, that modularity helps here a lot. Theoretically, a modularized software project will be more easily assembled, since no team members are creating the whole system, or even need to know about the system as a whole (less cognitive load). Design in modules allows the developer to confine his changes to one or a few modules and drasticaly speed up the dev and testing efforts of the chaged parts. Of course, this is not an automatism and you need to follow some guidelines. What might play a role:

• Your test strategy. Are you aware of the principleas of the tes Test Pyramid*²?
• Are you ware of the logical boundaries of your system. Some stratetuig Domain Driven design migth help here a lot.
• Can your infrastrucrure deal with more services? Are you ready for centraliszed logging, monitoring
• etc.

However broadly speaking modularity in your systems can improve stability and availability. Consider a system that designed and changes according to prominent and commonly accepted rules like loose coupling, stable API etc. If changes are made to a few modules not violating public API and interfaces, the risk of constant releas of internal services, that are well decoupeld by well-crafted internal APIs and routines should be very much in controll.

In the best case, system modularity is taken to the level of microservices, important here is the definition of microservice as separate deployable (independent) process with own and widely independent build and deployment cycle! Having that, a (Micro) Service can be seen as a run-time unit of modularization and thus adding to you’re delivery speed. Well technically there are still a lot things that can be done wrong so unwanted dependencies will arise unconscious or even negligent. This article is not about thechnical pitfalls. I’ll try to come back to such details in one of the next.

Finally, to resolve all doubts, I think that agile companies/teams become agile not because of tools or architectures they use in a first place. Agility starts with a mindset, communication, and organizational issues. But at some point, you need to find architectures and tools that support you’re doing that successfully. Prepare your’ mind for new strategies, tools and practices.