Tuesday the 10th of November I attended a public lecture at Swiss Java User Group in Zürich. Topic of the pretension was to describe and address challenges any project manager can encounter, when reflexion switches from perspective of software architecture to real coding implementation.
Presentation was essentially based on Java language, but in fact applicable to any other language.
So first, presenter shared project experiences he has got with some customers, and pointed weaknesses of their architecture diagrams in comparison with their implementation.
To give you an example, we can consider having a layered model eventually a Model/View/Controller approach, for several parallel services. Be careful, I am not saying this approach could no longer be applicable to a project, but as long as the scope remains relatively restricted, architectural design will not be so hard to represent.
However, when we start having bigger problems to address, with dependencies between components in same or across these layers, architecture diagram could more look like a spider web. Moreover, by doing abstraction in this manner, it becomes also painful to navigate between one layer and/or dependent sub-services to understand and recover the “big-picture” of a business requirement. On the other hand, same challenge happens for finding the linked code representation.
Presenter also argued by saying that traditional modeling patterns could also lead to miss-understandings between customers, software designers and developers. Indeed by keeping such abstraction vocabulary, same word could have several meanings depending on position of the person involved inside the project. He just invited us to avoid, as far as possible to use generic terms, like “Service”, “Layer” or “Component” when sharing knowledge or doing synchronization between involved teams.
After this introduction, presenter then gave us some keys and best practices for improving software architecture representations, and make them closer to code representation as well.
Main proposition is to represent a software architecture more by “containers”. A container could be understood as an aggregate set of (micro)services that answers a particular need rather than “view” or “controller” layers, which are involved by multiple services. He convinced us to represent our software more by “utilities” modules, rather than abstracted -unnamed- layers (unnamed meaning not representing any functional activity of the software solution).
He also invited us to formalize this architecture in several abstracted representation, up to 4 depending on perspective we want to have regarding finality of a question. The first, very high level, close to a use-case diagram but with third party dependences. Here, software is only represented by a black-box at the center. Then he described how we could zoom into this “box”, and into next subsequent “boxes” etc. up to a traditional class diagram.
By experience, and knowing I am more coming from “coding” world, I also experienced same challenges than he described during coordination with people coming with an “architectural” point of view. We had altogether to found out solutions to better understood ourselves. And to say the least, outcome was something close to presenter conclusions.
In case you would like to continue getting more details about this original software architecture approach, I invite you to follow Simon’s Brown presentations and news.
I also want to thanks him and Swiss Java User Group for organizing such very interesting lectures.