過去的幾年中，我發現很多軟件開發團隊都努力地對他們所構建系統的軟件架構進行可視化和交流。我認為主要有三個原因。
1.在很多軟件團隊加快採用敏捷方法的過程中，都把精華和糟粕一起潑掉了：建模和文檔隨著傳統的計劃驅動的過程和方法論一起被扔掉了。
2.看不到文檔和圖表的價值的團隊，往往也拋棄了統一建模語言（UML，當然，假設他們一開始也在用），轉而使用更輕量和務實的方法。基於與上千名軟件開發者的會議和交談，我掌握的證據顯示，多達九成的軟件開發者都不使用UML。
3.很少有人教軟件團隊如何有效地可視化、建模和交流軟件架構。並且，從我為一些計算機科學的學生舉辦的培訓班來看，大學也是如此。
如果在大多數軟件開發團隊的辦公室裡晃悠足夠長的時間，你一定能找到一些草圖，不是畫在白板上，就是辦公桌上的廢紙上。草圖 是捕捉和呈現軟件架構的好方法，但它們通常缺少UML圖的正規和嚴謹。這未必是一件壞事，但圖表確實需要能被理解，這也是事情開始變得棘手的地方。過去幾年我為上千人舉辦過軟件架構草圖專題研討會，可以毫無疑問地說大多數人都覺得這件事很難。下面選出了一小部分來自這些專題研討的照片，各組人嘗試交流他們對金融風險系統案例 的軟件解決方案。挨個看看，問問你自己，他們是不是在以有效的方式交流解決方案的軟件架構。有些圖表使用了顏色，如果你在黑白的電子書閱讀器上閱讀本書，我向你表示歉意。