Many time we face situation were productivity of a software team is impaired by initial flaws in system design. These initial flaws require too much time to be completely removed (the effort of complete rewrite is only marginally touched here and is normally and indication of other problems in your software project )
So, in order for a software team to be able to work at its maximum, good design is a must. Design is much more responsible for productivity than any single coder, scrum master, product manager or development methodology/language in the sense that bad design can take an all-star team using top tools/methodology to perform badly.
There were times when it was taken for granted that before building a system, it was necessary to design it. That time looks gone (even though Agile does not explicitly prohibit making good design). The general idea seems to be that there is “never enough time to do something right, but there’s always enough time to do it over” again.
But what is design in software ?
That kind of intellectual activity which creates a whole from its diverse parts may be called the design of a system
Melvin E. Conway, How Do Committees Invent?
So you compose parts to make the whole system. How you do this ?
It is basically decomposition to generate single parts that acting together will generate the goal. The 2 tools you will need as a designer are :
- decomposition
- composition
But first of all you need :
- understanding of the system boundaries : the borders of the nation your system lives in
- understanding the global scenario of what your system is going to do. Designing subsystems without knowing the whole picture is not a good idea.
Why decomposition of a system into smaller components (services) is good for you :
- information hiding : well identified interfaces create a contract that the component has to provide, hiding any network/system implementation details. This will make the component implementation completely free to be modified/enhanced as long as the new implementation is compliant with the contract.
- less development time : separate components/services can be developed in parallel since they don’t require (or require little) external dependencies, so less contention between engineers. Every component is independent on integration and performance test that can be developed autonomously.
- scalability : with little effort in design every component might be deployed in a way to be one of many instances that will make that service scalable when traffic increases.
- clarity : the system could be studied a component (service) at a time with the result that the whole system could be better designed because it was better understood
We could go on here and analyze what are the criteria to be used in decomposing a system into services. I’ll leave this to another moment and you can find some interesting notes here :
https://blog.acolyer.org/2016/09/05/on-the-criteria-to-be-used-in-decomposing-systems-into-modules/
What I would like to stress is that design is a fundamental phase in software engineering. You can’t just skip it and pretend that since you have a good team you’ll get a good job done.
Thanks to the following for inspiring me on this post :
https://en.wikipedia.org/wiki/Melvin_Conway
https://blog.acolyer.org/2019/12/13/how-do-committees-invent/
https://blog.acolyer.org/2016/09/05/on-the-criteria-to-be-used-in-decomposing-systems-into-modules/