Challenge & selection

I am a software architect, so my job includes designing solutions and presenting them to stakeholders.  Presentation can be really difficult part of the job, because the job’s outcome describes hypothetical  software components which are non-tangible and can hardly be mapped to any well-recognized real- world abstractions. Visualization is a great tool here, because it helps to shape thoughts into visible  images and removes some tension of using technology-specific language. It also allows clearly drawing  boundaries of solution scope and then selecting appropriate level of detailing inside of selected scope.

Application

Recently one of my development teams decided to review an architecture of its application. At the  starting point, the application was fairly monolithic. It included terribly intertwined ML-modules and  business logic components. We decided to make a move towards microservice approach. This decision  produced long discussions about target architecture. Every team member had their own approach to  decompose the system into modules. Evidently, each approach led to unique outcome.

I think that establishing common understanding of microservices’ boundaries is one of the most difficult  communication problems in software industry. In order to produce clear common vision and predictable  outcome my team and I drew a set of diagrams to visualize system’s behavior. I used principles of  domain-driven design as a canvas. Firstly, we drew flow of business events through the system. It helped  to understand which functions we needed to implement to process these events. Then we depicted  bounded contexts and their nested aggregates, so we could see interrelationships between them.

Insight

Process of visualization encouraged an active discussion between team members. Many of them  proposed valuable ideas, and these ideas could be well-understood by others thanks to visual  representation. When we had diagrams on hand, the team obtained clear understanding which  microservices we need, what will they do and how will they interact with each other. It allowed us to  make infrastructural decisions, split works between developers and build a plan of iterations.

Approach

Visualization shows to be a great tool in many areas due to its impact on presentation’s visibility and  simplicity. It allows finding common language among people with various backgrounds. I personally  heavily rely on visualization in my work and encourage team members to use it.


Challenge & selection I am a software architect , so my job includes designing solutions and presenting them to stakeholders . Presentation can be really difficult part of the job , because the job ’s outcome describes hypothetical software components which are non - tangible and can hardly be mapped to any well - recognized real- world abstractions . Visualization is a great tool here , because it helps to shape thoughts into visible images and removes some tension of using technology - specific language . It also allows clearly drawing boundaries of solution scope and then selecting appropriate level of detailing inside of selected scope . Application Recently one of my development teams decided to review an architecture of its application . At the starting point , the application was fairly monolithic . It included terribly intertwined ML - modules and business logic components . We decided to make a move towards microservice approach . This decision produced long discussions about target architecture . Every team member had their own approach to decompose the system into modules . Evidently , each approach led to unique outcome . I think that establishing common understanding of microservices ’ boundaries is one of the most difficult communication problems in software industry . In order to produce clear common vision and predictable outcome my team and I drew a set of diagrams to visualize system ’s behavior . I used principles of domain - driven design as a canvas . Firstly , we drew flow of business events through the system . It helped to understand which functions we needed to implement to process these events . Then we depicted bounded contexts and their nested aggregates , so we could see interrelationships between them . Insight Process of visualization encouraged an active discussion between team members . Many of them proposed valuable ideas , and these ideas could be well - understood by others thanks to visual representation . When we had diagrams on hand , the team obtained clear understanding which microservices we need , what will they do and how will they interact with each other . It allowed us to make infrastructural decisions , split works between developers and build a plan of iterations . Approach Visualization shows to be a great tool in many areas due to its impact on presentation ’s visibility and simplicity . It allows finding common language among people with various backgrounds . I personally heavily rely on visualization in my work and encourage team members to use it .