Moving Fast Requires Good Communication
But we've lost the ability to visualize our software
If you're working on an agile software development team at the moment, take a look around at your environment. Whether it's physical or virtual, there's likely to be a story wall or Kanban board in order to visualize the work remaining to be started, in progress and done.
We're adept at visualizing our software development process
Why? Put simply, it's a fantastic way of introducing transparency into software projects because anybody can see, at a glance, a snapshot of the current progress at a high-level. Couple this with value stream mapping and you can start to design some pretty fancy looking Kanban boards to reflect that way that your team works. In a nutshell, we've become pretty adept at visualising our software development process.
But we've forgotten how to visualize the software that we're building
However, it seems we may have forgotten how to visualize the actual software that we're building. I'm not talking about post-project documentation here (that's a story for another day), I'm talking about communicating "the big picture". Why is this important? Well, if you want to ensure that everybody is contributing to the same end-goal, you need to be able to communicate the vision of what it is you're building. And if you want agility and the ability to move fast, you need to do this effectively and efficiently. You can argue about whether notations such as UML offer an effective way to communicate software architecture or not, but that's often irrelevant as a starting point because many teams have already thrown out UML or simply don't know it. What's the result? Usually boxes and lines diagrams like the sketches below.
Boxes and lines diagrams *can* work very well, but there are many pitfalls associated with sketching software architecture in this way. My approach is to use a collection of simple diagrams, each showing a different level of abstraction.
All of my guidance around doing this is going to be enhanced and included in my software architecture e-book
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)