I recently had a chat with one of my junior developers. He was just less than 3 months in our company and I wanted to know how his experience was so far. This guy came from a company where every developer was a heroic developer, given the freedom to choose the technology he see’s fit to use in his software project. With our company, he had to follow certain ways of doing things, which was totally different to what he’s used to. He said he’s already getting the hang of it and he now understands why we have that culture, the culture of having a well defined architecture.
Having an architecture means that we put constraints on some of our technology and design choices in order to achieve some system properties that we value most. We’ve been reaping the benefits of this architecture and each time it gets me thinking about reasons why an architecture is a good thing. There are probably an thousand and one reasons but I’ll put forward 3 which has benefited my team immensely.
Economies of Scale
Several months ago, we realised we needed to redesign the user experience in order to make our product more usable in the enterprise context. This was a good time to revisit parts of our architecture but we only had one month to do it. We had to build 5 big modules and giving one module to one developer seems a daunting task. Not only that, since there were many functionalities that were common across all modules, we were sure that a lot of code duplication will happen. Luckily, we were using a technology that allowed us to define re-usable components. By encapsulating common functionalities as components, this allowed us build components that do one specific thing and do them well. Instead of developing a module, developers now build components which make development simpler and tracking progress more fine-grained. Since components make up a module, it became more evident right from the start that everyone is cooperating in building a module. And since each component is used in more than one module, this accelerated our development drastically allowing us to meet our target.
The above diagram describes the mapping of 10 components to 5 modules. Each row represents a module. A green box indicates that the component(vertical) is a part of that module. For example, module 1 is composed of components 1, 4, 8, 9, and 10. After building and integrating the said components, we say that module 1 is done. The same is true for the other modules.
Now assume that in the first time period, the developers finish module 1. No surprises here. The velocity of the development is as expected. They will then proceed to build module 2. After building module 2, you can see that all the components of module 3 and 4 are also built and only need to be integrated. This means that by the second time period, you already built 4 of the 5 modules. By the 3rd time period, you only need to build the last two components of module 5. The graph below shows how the development is accelerated by the component approach.
In fact, in this illustration, given any 5 modules that is composed of 5 components, there will always be a component that is shared by at least 3 modules. The power of Economies of Scale!
Our application captures events happening in the system. Creation, deletion, update or reading of business objects trigger event handlers that do a multitude of things. For example, some of these events are captured by the application’s Social module. When some user comments or likes a certain update, that event will be captured and sent to interested users. By following the architecture, any new module developed will automatically benefit from the event infrastructure and the developer need not worry about it.
Not only does the business object benefit from Social module, it also benefits from other modules automatically as shown in the diagram above.
Better Maintainability and More Solid Code
The UNIX philosophy advocates writing programs that do one thing and do it well; programs that work together to solve complex tasks. By following the same philosophy in our architecture, we are able to minimise duplication of code. What this means is that when we identify a bug in the code, we are confident that that is the only place we need to fix the bug, making our application more solid as time goes by. All components using that particular component automatically enjoys the benefit of a solid code and on any new features of that component.
What I described is architecture in the small. But the same benefit applies to architecture in the large. That is why architecture is very important from the government we run, the cities we build, the buildings we live in, down to the software we use.