Today I had a call with a developer of a library we are using in one of our applications. We have discussed our use case: workaround we implemented to overcome limitations and an alternative solution from his side. The call was useful as I got additional inputs which I’m going to apply. That made me think about how multifaceted communication can be during the process of architecture development:

• collect functional and non-functional requirements to the platform;
• present research results to the team;
• plan implementation steps;
• collect feedback from the team;
• contact the infrastructure team;
• discuss alternative approaches;
• resolving conflicts of interests;
• contact dependencies development teams;
• provide dedicated requirements to the team’s area of responsibility;
• support the team.

The items might be not exactly in such order and probably I’ve missed some of them. Each round can be repeated several times during changes in the platform and depending on the development stage. Different rounds of communication involve different numbers of participants with different roles, and can go occasionally or on a scheduled basis.

Sometimes people can communicate on a topic without sharing results or agree on something not corresponding to the initial concepts, which causes conflicts of interests between participants. The more people in a group, the more difficult it is to keep track of discussions. Thanks to the scrum master role the whole process can be organized in a comfortable manner.