哪怕你在一個所有軟件都用一套標準的技術和模式構建的環境中工作，在軟件架構圖中包括技術選擇都可以消除歧義。想像你在設計一個軟件系統。你真的不思考到底要如何實現它？你真的是根據概念化的框和功能分解來思考？如果這些問題的答案是「不」，那麼為什麼不在圖上增加這個額外的信息層。這樣做為對話提供了一個更好的起點，特別當你有一個可用的技術選擇時。強迫人們在他們的軟件架構圖中包括技術選擇往往還能引發更豐富、深入、腳踏實地的交流。一個膚淺和概念化的圖往往會造成許多假設，但分解技術使我們不得不問下面這類問題：
- 「這個組件如何與運行在單獨進程中的另一個組件溝通？」
- 「這個組件如何初始化，職責又是什麼？」
- 「為什麼這個進程需要和另一個進程溝通？」
- 「為什麼這個組件要用X技術而不是Y技術實現？」
- 其他。
至於技術決策把圖搞亂的問題，有多種處理策略，包括使用容器圖 來單獨展示主要技術決策。
在交流大局的整體而不只是其中一部分時，技術選擇有助於把其他理想化和概念化的軟件設計帶回現實，再次腳踏實地。當然，把技術選擇加入圖中的其他副作用，特別是在軟件設計過程中，就是它有助於確保讓合適的人 來畫圖。