Architecture and Communication

My post today is going to talk about how software architecture can be a vehicle of communication.

What is Architecture?

Wikipedia defines architecture as the structure or structures of system, which comprise software components, the relationships among those components, and the relationships between them.

When software engineers think architecture, they primarily think of architecture and documentation and diagrams of the above-mentioned structure. And the popular “architecture” sites support such notions.

For example, Wikipedia lists the Common language infrastructure architecture as this:

The documentation suggests that all the code of the different languages get compiled to Common Intermediate Language. However, it does not say some significant things: Does the compilation support the full-fledged language or does it apply restrictions on the languages for compilation? Can the languages communicate with one another? And most importantly, what quality attributes does this architecture support, and why?

Any such diagram can raise these questions, and it is important that the development team is knowledgeable about the answers. Without architectural knowledge, the team may not have a good big picture view of the system.

This "lack of big-picture view" happens in both small and big companies. Roni Burd, a program manager at Microsoft, discovered this issue with his Bing development team. He had to take action to raise the architectural awareness of the team. I have noticed this also at my new job, where the software is too large to comprehend without proper architectural perspectives. Without good architecture documents, the team members each get familiar with parts of the system, but no one can really talk about the system as a whole.

It is the architect's job to ensure that the development team is adequately knowledgeable about the answers to these questions. S/he can share this knowledge through documentation or architecture workshops or through any other means.

We used the following activities in Spring and Summer to raise architectural awareness:

ACDM architecture reviews:

We conducted architecture reviews throughout Spring. In these reviews, the architect would present a partitioning of the system, and explain the rationale for that partitioning. Then the team would raise and record issues with that partitioning.

What we could have done better:

We should have been more upfront about giving feedback on architecture. We all had different ideas and impressions on the architecture, and we could have done a better job at harmonizing those differences. We could not relate how the pictures and diagrams of the architecture related to the actual product. If we implemented parts of the application, that would have given us a concrete mental model of how the architecture and the actual software were connected. With that mental model, we could have been better at communicating our differences of opinion about the architecture.

Architectural documentation:

Architecture documentation was our key way to communicate in Spring and Summer. These were up-to-date diagrams of the system, with design rationale relating them to the quality attributes.

What we could have done better:

Since we were implementing the product in summer, we could have improved architectural communication by printing out the architectural diagrams and posting them in the cubicle. This would have allowed the team to question and verify the architecture as they were implementing the system.

Topic of the week:

We did have some verification of the architecture at our 'topic of the week' sessions. 'Topic of the week' was our way of addressing misconceptions. Each week, at the status meetings, we budgeted some time to talk about a topic that we needed to communicate across the team.

At the architecture sessions, we addressed the following questions: how the architecture decomposition related to the implementation, and how were the quality attributes supported.

What we could have done better:
We could have addressed more architectural topics. There were questions on how did our package structure relate to our static architecture, and why were packages decomposed the way they were. These could have been better addressed early in the project to clarify the responsibilities of each package. That would have reduced some architectural refactoring work.