Herve Lourdin‘s tweet wasn’t aimed at modeling, but the image nicely illustrates a critical deficiency in modeling languages – showing evolution of a system over time. Structure and behavior are captured, but only for a given point in time. Systems and their ecosystems, however, are not static. A map of the destination without reference to the point of origin or rationale for choices is of limited use in communicating the what, how, and why behind architectural decisions.
“The Road Ahead for Architectural Languages” on InfoQ (re-published from IEEE Software) recently noted the following reasons for not using an architectural language (emphasis added):
- formal ALs’ need for specialized competencies with insufficient perceived return on investment,
- overspecification as well as the inability to model design decisions explicitly in the AL, and
- lack of integration in the software life cycle, lack of mature tools, and usability issues.
All of the items in bold above represent usability and value issues; a failure to communicate. As Simon Brown observed in “Simple Sketches for Diagramming Your Software Architecture”:
In today’s world of agile delivery and lean startups, some software teams have lost the ability to communicate what it is they are building and it’s no surprise that these teams often seem to lack technical leadership, direction and consistency. If you want to ensure that everybody is contributing to the same end-goal, you need to be able to effectively communicate the vision of what it is you’re building. And if you want agility and the ability to move fast, you need to be able to communicate that vision efficiently too.
Simon is a proponent of a sketching technique that answers many of these communication failures:
The goal with these sketches is to help teams communicate their software designs in an effective and efficient way rather than creating another comprehensive modelling notation. UML provides both a common set of abstractions and a common notation to describe them, but I rarely find teams that are using either effectively. I’d rather see teams able to discuss their software systems with a common set of abstractions in mind rather than struggling to understand what the various notational elements are trying to show.
Simon’s colleague, Robert Annett, recently posted “Diagrams for System Evolution”, which proposes using the color-coding scheme from diff tools to indicate change: red = remove, blue = change, green = new. Simon followed this up with two posts of his own, “Diff’ing software architecture diagrams” and “Diff’ing software architecture diagrams again”, which dealt with applying Robert’s ideas to Simon’s structurizr.com tool.
Simon’s work, coupled with Robert’s ideas, addresses many of the highlighted deficiencies listed above (it even touches on the third bullet that I didn’t emphasize). Ruth Malan’s work also contains some ideas that are vital (in my opinion) to being able to visualize and communicate important design considerations – explicit quality of service and rationale elements along with organizational context elements. A further enhancement might be incorporating these into a platform that can tie elements of software architecture together with elements of solution and enterprise architecture, such as the one proposed by Tom Graves.
Given the need for agility, it might seem strange to be talking about modeling, design documentation, and architectural languages. The fact is, however, that many of us deal with inherently complex systems in inherently complex ecosystems. Without the ability to visualize a design in its context, we run the risk of either slowing down or going down. Not everyone can afford to “move fast and break things”.
Form Follows Function 
Interesting.
Since this is an article on Architecture, I wanted to check what definition of architecture is used. I found no reference to (or citation of) “ISO / IEEE” definition of “architecture”” http://www.iso-architecture.org/ieee-1471/
It evolved after decades of very narrow and misleading definitions. If that definition of architecture is applied to software architecture the wisdom of evolving the definition of architecture can be utilized beneficially.
While sketching and coloring are intuitively appealing they could be misleading when the concepts to be presented are “NOT spatial and visual” as in the case of software and software architecture. Software concepts and relations are NOT spatial and visual. This must be well recognized and users must be advised to avoid interpretations and inferences based on unintended spatial and visual implications of sketches and colors. This apart many crucial concepts in software cannot be precisely represented by simple graphics.
IMO this is the reason why UML is NOT used by many software professionals and Architecture Description Languages evolved to meet the specific needs of software concepts more effectively.
Now it seems that even ADLs are not useful!
Seeing this it appears that software architecture has NOT evolved for widespread effective use. We need something radically new, perhaps.
01JUL15
LikeLike
What the hell kind of statement is “”software concepts are NOT spatial and visible”? What do you think they are then? Invisible and temporal?
LikeLiked by 2 people
I do not think Bulldozer00 really wants to know but “software concepts are NOT spatial (of or relating to space) or visible (perceptible to the eye).
This can be checked out by taking any software concept and examining if any of its “inherent characteristics” are spatial or visible.
:
LikeLike
Please pass me some of what you’re smoking. What color is the sky in your world?
LikeLike
Gene:
You probably did not pay attention to a part of what I posted, “While sketching and coloring are intuitively appealing they could be misleading when the concepts to be presented are “NOT spatial and visual”
I have no objection for the use of graphic / visual or other representations of concepts but one has to be careful in interpreting the representations (models). If the concepts themselves do not have “spatial and visible” characteristics, many spatial or visual attributes do not apply and could be misleading.
Many good tools are designed to avoid possible misuse and unsafe consequences, irrespective of the capability of user.
LikeLike
Putcha,
If your point is that not all aspects of a design can be conveyed via graphics, I agree. That is a pretty obvious point. Even graphical languages like UML include text elements for just that reason. That being said, spatial relationships can be effective communications tools (e.g. heat maps for dependencies). Visualization, like writing, is a tool. Use and misuse of a tool is more a function of the user than the tool.
LikeLiked by 1 person
Putcha,
Of course one has to be careful in the interpretation, but that holds true whether the language is graphic, textual, or some combination. It also holds true whether the concepts expressed are spatial and visual or not (e.g. the use of a heat map, which is spatial, works well to convey quantity of dependencies, which is not spatial). The whole point of visualization is to be able to see concepts that are not visual in and of themselves.
LikeLike
What you say is covered in my post and subsequent responses. It is NOT about general caution about interpretation. If certain representations are liable for serious misinterpretation, such representations should be avoided or specific notes must be added to avoid misinterpretation.
With specific reference to “software architecture” the use of vertical and horizontal boxes (which are often used) has not be helpful. This apart a satisfactory definition of “software architecture” did not emerge till recently.
I would be interested to see representations in different forms and their effectiveness to precisely convey the crucial concepts involved.
06JUL15
LikeLike
“…the use of vertical and horizontal boxes (which are often used) has not be helpful”
How so and compared to what?
“I would be interested to see representations in different forms and their effectiveness to precisely convey the crucial concepts involved.”
As would I, but it’s not something I have the bandwidth for.
LikeLike
For me, to get your Dev community really rockin’ you need to provide consistency and most of all repeatability in your approaches to both system decomposition (decomp) and runtime modeling.
Have you ever checked out The IDesign Method (www.idesign.net)?
It’s both a straightforward methodology for decomposing a service-oriented (SO) problem space and a clear, lightweight modeling notation for capturing key SO design decisions that allows you to express runtime behavior in a way that Devs can actually build against. The last part is priceless.
The approach also defines a terse, tech-agnostic SO taxonomy that is perfect for building microservice-based systems and allows your Dev community to settle in on a simple pattern-based architectural language they can grok and use to communicate their ideas effectively and efficiently.
This all combines into a tight ‘just enough’ decomp approach and modeling style that allows you, your architecture and your teams to BE agile, instead of just ‘doing’ agile.
I’ve found that providing your Dev community a firm foundation upon which to build does not stifle creativity. Just the opposite. It acts as a springboard to unlock their ideas by getting rid of the drudgery and day-to-day turbulence caused by the impedance mismatch between design and code.
Cheers!
-Mont
LikeLiked by 1 person
Gene:
Alternatives and comparisons did not arise. The significance of “vertical and horizontal boxes” in software is not defined and so was not helpful. Some experts suggested the use of Design Structure Matrix which I found to be more helpful.
I will continue to look for good clear representations of software and other concepts which do not inherently have spatial or visual characteristics. I welcome inputs from those (including you) who have similar interests.
06JUL15
LikeLike
Putchavn,
I hear what you’re saying. From the macro to the micro the notion of ‘software architecture’ and how you should capture your design decisions to communicate effectively is completely ambiguous.
I’m primarily a ‘Software Architect’, which means I’m concerned with succinctly conveying the structure and intent of a system’s design so that Devs accurately express my designs in code.
In this context, to communicate efficiently and effectively, we have to go for the visual cortex. And while software is not tangible, good software is well-structured. For the runtime portion at least, this structure provides an abstraction through which we can graphically model it.
You’re right, in-of-themselves the boxes in a diagram provide no meaning or visual relevance on their own. For that you must make each diagram contextual, provide a succinct and terse taxonomy of elements and establish a straightforward set of roles, rules and relations that delineate their runtime composition. These then allow your diagrams to clearly convey significance, relevance and meaning for translation into code. Your diagrams then become explicit blueprints for the structure of your code.
You may find as I have that establishing a succinct taxonomy is the secret to establishing significance. It is the taxonomy that gives each box a specific role and constrains the type of code that a developer should place within each box. But you’re right. There is a point where software requires a detail beyond which graphical representation is inappropriate and completely unreadable. Code or what you might call ‘detailed design’ is still best expressed using, well, code. In this way design for me is a spectrum from diagram to code. The diagrams express the structure and the code express the intent.
Against the backdrop if its runtime behavior captured in diagrams, you then apply the cross-cutting aspects of your software such as identity, authentication, authorization, transactions, isolation boundaries, etc. Each with its own diagram.
I suggest you look again more deeply at the IDesign Method. There is a wealth of visual significance there to be reaped that your Devs can convey directly into code.
-Mont
LikeLike
Thanks Mont for joining the discussion. My point was that any representation (graphic / visual in this case) must have close correlation with the finer aspects of the concepts represented for meaningful use of such representations.
If it is feasible I have no reservation against using graphics (I had used Venn diagrams for understanding set theory basics through the set theory concepts do not have graphic attributes) but I want to know how far to carry the analogy without making wrong inferences. In such circumstances I am exploring if (and how) other methods of representation can be combined for representation / analysis / communication.
For personal / human understanding I do convert matrix notations into visuals but the reliance is still on more rigorous / precise non-graphic representations. In my learning my weakness of wanting visual representation impaired the depth of learning understanding and application. So, I will use graphics / visuals as long as they are valid.
I will take a look at IDesign Method. I am also involved with taxonomies, ontologies etc. So I want to know how they are used in combination with graphics.
PVN 06JUL15 3 PM.
LikeLike
“My point was that any representation (graphic / visual in this case) must have close correlation with the finer aspects of the concepts represented for meaningful use of such representations.”
Sorry, no. The little glyphs that you see on this page have no close correlation to the concepts they represent, yet we manage to communicate via text – it’s called symbolism. Definition, consistency, rules are all important. Visual correlation, not so much.
LikeLike
Gene: I see no relation between “My point was ….” and different glyphs of quote marks. Anyway there was nothing left for discussion.
LikeLike
Pingback: Designing Communication, Communicating Design | Form Follows Function