哪怕你在一个所有软件都用一套标准的技术和模式构建的环境中工作，在软件架构图中包括技术选择都可以消除歧义。想象你在设计一个软件系统。你真的不思考到底要如何实现它？你真的是根据概念化的框和功能分解来思考？如果这些问题的答案是“不”，那么为什么不在图上增加这个额外的信息层。这样做为对话提供了一个更好的起点，特别当你有一个可用的技术选择时。强迫人们在他们的软件架构图中包括技术选择往往还能引发更丰富、深入、脚踏实地的交流。一个肤浅和概念化的图往往会造成许多假设，但分解技术使我们不得不问下面这类问题：
- “这个组件如何与运行在单独进程中的另一个组件沟通？”
- “这个组件如何初始化，职责又是什么？”
- “为什么这个进程需要和另一个进程沟通？”
- “为什么这个组件要用X技术而不是Y技术实现？”
- 其他。
至于技术决策把图搞乱的问题，有多种处理策略，包括使用容器图 来单独展示主要技术决策。
在交流大局的整体而不只是其中一部分时，技术选择有助于把其他理想化和概念化的软件设计带回现实，再次脚踏实地。当然，把技术选择加入图中的其他副作用，特别是在软件设计过程中，就是它有助于确保让合适的人 来画图。