The Power of the Software Architect in Shaping Productive Communication

The Power of the Software Architect in Shaping Productive Communication

Architecture, 06 May 2017

I used to underestimate the use of precise technical terms in order to describe my technical world. Instead of taking the time to find the correct terminology, I would just explain what is it that I wanted to do. For example, I would say, “I want the system to cope with erroneous input" instead of using the term "robustness."

Fast forward to a few years later. One of the first things I noticed in one of the companies I worked for was the flow of conversations. It really seemed like everybody "spoke the same language." When someone said something, the other person would immediately understand their meaning and intent, and vise versa, which produced very productive sessions. I decided to explore how effective communication works using a well-defined common terminology.

Why Go the Extra Mile Finding the Precise Technical Terminology

I came to understand that the company, through its chief architect, actually invests time in developing a common technical language and encourages the use of industry standards in order to describe its software.

The book "Domain-driven Design: Tackling Complexity in the Heart of Software" explains this precisely: "The overhead cost of all translations, plus the risk of misunderstanding is just too high. A project needs a common language that is more robust than the lowest common denominator. With a conscious effort by the team, the domain model can provide the backbone for that common language, while connecting team communication to the software implementation."

The Power of the Software Architect in Shaping Productive CommunicationClick To Tweet

I learned that the software architect has the power to shape productive communication by constructing a well defined technical language. Creating a common technical language enables productive discussions both inside and outside of the organization.

The power of a well defined technical language is even greater when communicating outside the organization. Almost every job interview starts with, "Tell me about the previous software project you worked on." It’s a lot easier and more professional to describe job experience using the correct terms instead of trying to translate each concept into a group of explainable actions.

A well defined technical language can be achieved by using industry standard terms and concepts to describe the software implementation. A few examples:

  • - The actions customers are able to do in the UI are customer contracts.
  • - A Flexible application which easily supports additional changes is extensible.
  • - A relational database system is RDBMS.
  • - Meaningful names for systems and services: Events processing system should be called "EventsProcessor" instead of "EventsNinga".

Presenting the domain model using a diagram with proper names for each phase is another way of reinforcing the technical language and encouraging productive communication. In the below example the "presentation tier", "logic tier" and "data tier" shape the technical language of the sales application.

Overview of 3 tire application Overview of three tire application. Source: Wikipedia

In summary, shaping a common technical language in the organization requires continuous effort. That common language can be achieved by using industry standard terms and concepts to describe the software implementation, and by using the domain model as a backbone for that common language. The common technical language encourages productive communication in the organization.