回想一下，结构化流程给软件设计流程和表达最终设计都提供了参考点。广为人知的例子包括Rational统一过程（RUP）和结构化系统分析与设计方法（SSADM）。软件开发行业在很多方面已经发生改变，但我们似乎忘了这些老方法留给我们的一些好东西。
作为一个行业，我们有统一建模语言（UML），一种用来表达软件系统设计的正规的标准化符号。然而，就UML对软件设计沟通是否有效的辩驳，通常是无关紧要的，因为很多团队已经不再使用UML，甚至根本不知道它是什么。这样的团队通常会画些不正规的框线草图，但是这些图往往没有太大意义，除非再劳神费力加上详尽的叙述。下回再有人围绕那些不正规的草图给你展示软件设计时，你就问问你自己，他们展示的东西到底是在草图上的，还是在他们的脑子里的。
框线草图可以工作得很好，但也会为软件架构的沟通带来很多隐患
抛弃UML没什么问题，但在敏捷比赛中，很多软件开发团队都失去了视觉化的沟通能力。上图是软件架构草图的例子，说明了一些软件架构沟通的典型方法，都存在如下问题：
- 颜色标注通常意义不明或不统一；
- 图表元素（比如，不同样式的框和线）的作用不明；
- 图表元素之间的重要关系有时是缺失或含混的；
- 频繁使用如“业务逻辑”之类的术语；
- 技术选择（或可选项）通常被忽略了；
- 抽象层次混乱；
- 图表常常包含过多的细节；
- 图表常常缺少语境或逻辑起点。
框线草图可以工作得很好，但也会为软件架构的沟通带来很多隐患。我的方法是用一套简单图表 ，各自只展示整个故事的一部分，不使用UML时要密切关注图表元素 。