Modularity in Software Systems means composing a system from a set of loosely coupled and highly cohesive components. Good example of a loosely coupled, highly cohesive architecture is Unix philosophy, which is summarized as by McIlroy1 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.
Microservices trend pushed that again in foreground. But what that has to do with Agility? Let's remember some of the 12 principles behind the agile manifesto first.
Principles behind 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 to 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's needed - is agile!
Modularity is agile
Speaking of technical design, we need to think which systems are more suitable for this. It's obvious 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. Design in modules allows developer to confine his changes to one or few modules and speed up the build and testing of changed parts. Of course this is not an automatism and you need follow some guides. For example if your tests do follow the Mike Cohn's Test Pyramid2 pattern, then you probably profit already automatically here. But even without speaking about testing (which can be a very long topic) modularity reduces risks of bugs in production. Consider a system that designed and changed according to prominent and commonly accepted rules like loose coupling, stable API's etc. If changes where made to only few modules not violating API and interfaces, risk of going live should be reduced.
In best case modularity is taken to the level of microservices, important here is definition of microservice as separate deployable (independent) proccess. In this case you are able to deploy only that microservice (process), that was changed in the last coding iteration.
I hope to convince you at this point, that modularity and microservices are going along with agile software development as all good Software Architectures do ;)
Finally to resolve all doubt, I think that agile companies/teams become agile not because of tools or architectures they use in a first place. Agility starts with mindset, communication and organizational issues. But at some point you need to find architectures and tools that support your doing that successful.