On Modular Architectures
What they are and why you should care.
What is software architecture?
Wiki article on this topic starts with this sentence — “The word software architecture intuitively denotes the high level structures of a software system.”
For me, the keyword here is structure. I belong to the group of people who see software architecture as these three things — the structure of a system, process of creating such structure and finally, documentation of the structure.
There are many styles of indicating this structure. Some of the common ones are Service-Oriented, Message-Driven, Client/Server, N-Tier, Object-Oriented, Layered (e.g. MVC), and Domain-Driven Design architectures. They can be categorized by their communication style, deployment model, physical layout and design principle.
It’s very common for a solution to use many styles of architectures. A style, after all, is how we view the system and not what it actually is.
What is modular architecture?
Modular Architecture is exactly what you think it is — a way to manage the complexity of a problem by breaking them down to smaller manageable modules. The difference is, as a software architecture style, it has some guidelines, principles and patterns.
To have a better understanding of a modular architecture, lets take a look at two common architecture styles and compare it with a modular system.
Layered architecture styles focuses on distributing the roles and responsibilities around a broader technical function. For example, in a typical web application, you may be able to see it as a composition of presentation layer on the very top, followed by business logic layer and at the bottom, a data or external services layer. It usually looks like an inverted pyramid with preceding layer accessing more focused lower level layers.
Layered architecture style highlights physical and often times, logical layout of an application.
A typical layered architecture diagram looks like this —
Service-oriented architecture (SOA) architectural style focus on how different business functions of a system work with each other. They are created, exposed and consumed as a set of services. SOA at its core implies that you have bunch of services that can perform some business function and your users can talk to these services to get their work done.
Systems have been talking to each other all along. But SOA supposedly codifies how we can publish, consume and discover these services across various technical and functional boundaries.
SOA architecture style highlights communication style of an application.
This is how an SOA architecture diagram typically is —
Modular Architecture, as a style, helps us view the system, not just in layers or services, but goes one level below as composition of smaller, physical modules.
They keyword here is module. Kirkk defines module as a “deployable, manageable, natively reusable, composable, stateless unit of software that provides a concise interface to consumers”. In Java, a JAR file represents the essence of a module.
These modules have clear business context, confines them to enclosing physical layer, works within the context that they are provided and express their scope through a public interface. They help us in understanding, extending and managing the system during design and during run time, that is, design time modularity and run time modularity.
The focus of modular architecture is how you design the physical composition of the application.
Many people have worked on this subject — John Lakos on C++, Kirkk Knoerchild on Java, Nicholas Zakas and Addy Osmani on JavaScript, to name a few. Platforms also supports it at various levels — MEF on .Net 4 and OSGi / Jigsaw on Java.
You say — “Thanks. But I believe my system is already modular.”
Agreed. Every application, no matter how small or large it is, has some amount of modularity in it. If you write code, no matter what your official title is, would have considered some level of modularity. It may be at the technical level, business function level or for the sake of reuse.
Developers have constantly chased this holy grail of comprehension, cohesiveness and reuse. If this sounds like a mouthful, well, it really is. Basically, simple, elegant and effective way to understand, extend and use it elsewhere. This is what drives us to create modularize solutions.
If that is the case, what I am complaining about?
In recent times, though, I fear, we somehow have convinced ourselves that using a tool, a framework or a new programming language will address the problem of complexity, comprehension, reuse and make the code automagically adopt to business changes. This is where I have a problem.
Agility, comprehension and cohesiveness are and will always remain a function of design. Tools and processes may make it easier to manage but can’t make the code magically clean, simple and reusable.
Understanding the code in terms of logical grouping is not going to help us. The focus has to be physical design. And it seems like we seem to be doing less and less of it.
Modularity, the way I see it, puts people at the center of software evolution and underlines that the business agility can be enabled through physical design.
Why would you choose to modularize your application?
Lets consider a software application that was created, say, 3 years ago. Throughout this period, the application would have evolved to adjust to changing business context. I am positive that these changes wouldn’t have come in large chunks. It would have come in multiple episodes of small and quick ones.
All these changes, if not done properly, results in a distributed, duplicated, chaotic, fragile and complex codebase, making them difficult to understand and hard to maintain.
Your application survived, that means you have honored all these changes. But while doing so, you may have complicated your codebase so much that the you are already thinking about rewriting it in a new framework or language.
Also, just because business functions are exposed as SOA services, it does not make the code comprehensive, modular and, extensible. Behind every functioning service, you may have a rotten codebase.
The root cause may not be that you have chosen wrong technology or framework. It may not the case that you have an incompetent team or demanding management. It may very well be the case that you application is not designed right. It may not be as modular as you think it is.
To be truly modular, as Kirkk puts it, you have to go “all the way” in. You have to focus on physical design of the application.
Why does is it matter now?
Software applications are embracing distributed, decentralized, real time and on-the-cloud as the new norm. They are focused on providing real service than just obsessed on list of features.
Apart from changes in business context, there is a radical change in expectation from users as well. The landscape of applications is completely changed by touch based, socially aware and experience driven consumer applications. The same is expected from business applications well.
You will now, if not already, be asked to add a “mobile” skin, support touch devices, move them over to cloud, make your service available as APIs, change the UI to be responsive and, worst of all, align your product to acronyms that are currently in vogue. What’s your poison — SAAS, PAAS or IAAS? I have no idea what will be the craze tomorrow.
Given all these demands, every one of existing software application will need a 2.0. That’s why modularity matters now, more than ever. No matter where the future takes you, having a good modular design will be of tremendous help. It can give you the confidence that you can pivot your design choice anytime without paying high cost.
I highly recommend that before you commit to a major exercise, like providing APIs or revamping your UI, please consider a release to specifically address modularity and have the right physical design.
Is it going to be easy? I will be damned if it is.
This is the first article in the series on “Modular Architectures”. Part II can be found here.
If this topic interests you and have more questions, I would be happy to discuss further. Please reach out to me.
