There is a famous anecdote about Sinan, the architect: when he was building the Selimiye Mosque, a child pointed at the minarets and claimed one of them was leaning. Sinan reacted immediately, instructing the workers to attach ropes to the minaret and pull until the child confirmed the minaret was now straight. The minaret wasn’t actually leaning, and the workers didn’t change anything by pulling. The perception of the minarets was at risk, and Sinan addressed that.

In software architecture, we face a similar, if not bigger, issue. Software architecture is essentially just paper; real architecture lives in the code and is hard to see. Architectural drift is a constant risk. Under these circumstances it is unavoidable that at some point in time, some corner of the organization will have a negative perception about a certain weakness of the architecture: it is too complex, too simple, too slow, too technology-dependent… It might come in the form of too general and abstract feedback, it might come for the right or wrong reasons, it might be a correct or incorrect perception.

Thankfully, new tools are available to continuously analyze the architecture of the code (evolutionary architecture with its fitness functions is worth mentioning). However, architects cannot rely solely on technical solutions.

The issue becomes more difficult at the system architecture and enterprise architecture levels. The architecture is much less tangible at these levels, many more people are involved, the time to discuss it is shorter, and the stakes are higher. We can’t just hope a tool will solve it for us. It is mainly a people issue, and the proper tool an architect can use is their communication skills:

• A well-written and up-to-date architecture documentation as a foundation and reference point.
• Realistically, most people won’t read the architecture documentation cover-to-cover, so concise (one-page!) architecture guidelines and principles are also necessary.
• Presentations to different stakeholder groups: higher management, development teams, suppliers and clients, fellow architects, and architecture reviewers.
• 1:1 conversations about the architecture.
• A general awareness of organizational politics and market conditions.
• An open mindset listening to people raising their concerns, working with them to get their specific feedback and courage to accept and work on found issues.

Only a combination of these methods can effectively achieve the job of communicating the architecture, avoiding misunderstandings, defusing false perceptions, and preventing architecture drift. Be aware that communication should be bidirectional: it is not about writing a 100-page architecture document and throwing it over the fence. Feedback is essential. Sometimes reversing roles and having other stakeholders provide parts of the communication is very useful for checking the understanding, ensuring higher acceptance of the architecture, and distributing the architecture workload more evenly in the organization.

Sinan’s insight was to not argue with the child, or trying to prove with tools and instruments that the minaret wasn’t in fact leaning. He aimed to correct the perception, not the minaret.