回想一下，結構化流程給軟件設計流程和表達最終設計都提供了參考點。廣為人知的例子包括Rational統一過程（RUP）和結構化系統分析與設計方法（SSADM）。軟件開發行業在很多方面已經發生改變，但我們似乎忘了這些老方法留給我們的一些好東西。
作為一個行業，我們有統一建模語言（UML），一種用來表達軟件系統設計的正規的標準化符號。然而，就UML對軟件設計溝通是否有效的辯駁，通常是無關緊要的，因為很多團隊已經不再使用UML，甚至根本不知道它是什麼。這樣的團隊通常會畫些不正規的框線草圖，但是這些圖往往沒有太大意義，除非再勞神費力加上詳盡的敘述。下回再有人圍繞那些不正規的草圖給你展示軟件設計時，你就問問你自己，他們展示的東西到底是在草圖上的，還是在他們的腦子裡的。
框線草圖可以工作得很好，但也會為軟件架構的溝通帶來很多隱患
拋棄UML沒什麼問題，但在敏捷比賽中，很多軟件開發團隊都失去了視覺化的溝通能力。上圖是軟件架構草圖的例子，說明了一些軟件架構溝通的典型方法，都存在如下問題：
- 顏色標注通常意義不明或不統一；
- 圖表元素（比如，不同樣式的框和線）的作用不明；
- 圖表元素之間的重要關係有時是缺失或含混的；
- 頻繁使用如「業務邏輯」之類的術語；
- 技術選擇（或可選項）通常被忽略了；
- 抽像層次混亂；
- 圖表常常包含過多的細節；
- 圖表常常缺少語境或邏輯起點。
框線草圖可以工作得很好，但也會為軟件架構的溝通帶來很多隱患。我的方法是用一套簡單圖表 ，各自只展示整個故事的一部分，不使用UML時要密切關注圖表元素 。