人們經常錯誤地將系統設計等同於簡單地繪製軟體架構圖。另一個誤解是將其僅與 BDUF（預先進行大型設計）、UML（統一建模語言）、TOGAF 等特定架構框架或各種文件型別（例如 HLD（高階設計）、SAD（軟體架構文件）、KDD（關鍵設計決策）、ARD（架構需求文件）、LLD（低階設計）和 ADR（架構決策記錄））聯絡起來。
系統設計超越任何特定工具或文件；它是一個持續的過程，概述了複雜系統的高階概念結構（系統架構），並定義了其重要元件和互動。它涵蓋了系統的所有方面（即軟體、硬體、資料、介面和使用者互動），以確保它們有效、高效地協同工作，以滿足應用程式的要求。
該過程的輸出可能包括：
- 系統需求文件（即詳細說明功能性和非功能性需求。）
- 系統架構文件（即描述所選架構背後的目標、約束和原理。）
- 系統架構圖（即提供元件、服務及其互動和關係的視覺化表示。）
然而，系統設計應注重前期和持續的系統設計評審，不斷記錄和重新審視系統要求、決策、權衡和妥協。評估系統的技術可行性、功能和效能並識別依賴關係和風險以做出明智決策是軟體開發中必不可少的一步。
傳統圖表工具的侷限性
隨著系統規模和團隊需求的發展，傳統圖表工具的侷限性變得更加明顯：
- 缺乏實時更新：圖表提供靜態表示，不能自動反映現代系統的動態特性。
- 笨重的使用者介面：更新圖表可能很麻煩，需要花費大量時間進行格式化和排列元件。
- 版本控制問題：跨團隊維護更新版本具有挑戰性。
- 有限的協作能力：實時協作和反饋通常需要更好的支援。
- 沒有單一的事實來源。圖表很少包含有關需求、權衡、設計決策等的資訊。通常使用設計文件。
- 無法管理雲資源：圖表無法控制或生成基礎設施程式碼（例如，CloudFormation、Terraform）。
這些侷限性凸顯了圖表工具並非設計用於處理現代軟體系統及其架構演變的複雜性。
這類似於瞭解汽車的工作原理：您不需要知道每個細節，但您應該能夠檢查引擎蓋下方以診斷問題，尤其是無需每次都將汽車送回經銷商處。因此，我們需要能夠將抽象與深入研究技術堆疊的能力相結合的複雜工具。這些工具應提供有關任何元件、結構或關係的最新資訊，並促進協作解決問題。
隨著現代軟體系統的複雜性不斷增加，越來越多的團隊將面臨傳統圖表工具的侷限性。這些工具曾經是展示想法和設計的必備工具，但仍需要改進才能捕捉到系統的全部複雜性，從而阻礙開發人員全面理解、設計、開發和管理系統。