It is common practice
to communicate software architectures using diagrams, but most
diagrams, in my experience are at best rough analogies of the architecture rather than faithful representations of it.
All analogies
break down at some point. That is why we call them “analogies”.
It is a good idea to understand where your analogies break down and
find ways to compensate.
In my own architecture
work, the main breakdown point for diagrams is that architectures in my head are more like movies than static pictures. In my minds eye, I tend to see data
flowing. I tend to see behaviors – both human and algorithmic –
as animated actors buzzing around a 3D space, doing things, producing and
consuming new data. I see data flowing, data flowing out, data
staying put but changing shape over time, I see feedback loops where
data flows out but then comes back in again. I see the impact of time
in a number of different dimensions. I see how it relates to the
execution paths of the system. I see how it impacts the evolution of
the system as requirements change. I see how it impacts the
dependencies of the system that are outside of my control e.g.
operating systems etc.
Any static two
dimensional picture or set of pictures, that I take of this architecture
necessarily leaves a lot of information behind. I liken it to taking
a photo of a large city at 40,000 feet and then trying to explain all
that is going on in that city, through that static photograph. I can
take photos from different angles and that will help but, at the end
of the day, what I would really like is a movable camera and the
ability to walk/fly around the “city” as a way of communicating
what is going on in it, and how it is architected to function. Some
day...
A useful rule of thumb
is that most boxes, arrows, straight lines and layered constructions
in software architecture diagrams are just rough analogies. Boxes separating
say, organizations in a diagram, or software modules or business
processes are rarely so clean in reality. A one way arrow from X to Y
is probably in reality a two way data flow and it probably has a
non-zero failure rate. A straight line separating, say “valid”
from “invalid” data records probably has a sizable grey area in
the middle for data records that fuzzily sit in between validity and
invalidity. And so on.
None of this is in any
way meant to suggest that we stop using diagrams to communicate and think about architectures. Rather, my goal
here is just to suggest that until we have better tools for
communicating what architectures really are, we all bear in mind the
limited ability of static 2D diagrams to accurately reflect them.