對於架構和設計的區別，格雷迪‧布奇（Grady Booch）有一個常被引用的定義，可以很好地回答這個問題。在On Design1 一文中，他說道：
1 原文給出的鏈接 http://www.handbookofsoftwarearchitecture.com/index.jsp?page=Blog&part=2006 已失效，可訪問 https://www.ibm.com/developerworks/community/blogs/gradybooch/entry/on_design?lang=en 閱讀文章。——譯者注
作為名詞，設計是指一個系統內命名的（儘管有時無法命名）結構或行為，解決或有助於解決該系統的一個或多個問題。因而設計代表了潛在的決策空間中的一個點。
思考任何一個需要解決的問題，可能都有101種方法。以你目前的軟件項目為例，要實現同一目標，可能有多種不同的技術、部署平台和設計方法可選。即使是設計軟件系統，你的團隊也只是從潛在決策空間裡的很多個點中選擇一個。
格雷迪還說：
所有架構都是設計，但並非所有設計都是架構。
這很有道理，因為創建一個解決方案本質上就是一次設計練習。然而，出於某些原因，有一個區別使得並非所有設計都是「架構」，對此他聲明：
架構反映了使一個系統成型的重要設計決策，而重要性則通過改變的成本來衡量。
從本質上講，格雷迪認為重要決策即「架構」，其他的都是「設計」。在現實世界中，架構和設計的區別並不明顯，但該定義確實為我們提供了一個基準，去思考在我們的軟件系統中哪些可能是重要的（或者說「架構的」）。比如說，這可能包括：
- 系統的形態（例如，客戶端-服務器、基於Web、原生移動客戶端、分佈式、異步，等等）；
- 軟件系統的結構（例如，組件、層、交互，等等）；
- 技術選擇（即編程語言、部署平台，等等）；
- 框架選擇（例如，Web MVC2 框架、持久性/ORM3 框架，等等）；
- 設計方法/模式選擇（例如，針對性能、可伸縮性、可用性等的方法）。
2 Model-View-Controller，模型-視圖-控制器。——譯者注
3 Object-Relational Mapping，對像關係映射。——譯者注
架構決策不可能輕易反悔，那會大費周章。或者說直白點，架構決策很難在一個下午就完成重構。