定義軟件架構的10個屬性
軟件架構是一套流程；一系列將規格和業務目標映射為架構設計和具體產出的策略性設計決策；一套在區分不同利益相關者的過程中產出的視圖， Michael Stal 陳述了 怎樣定義一個軟件架構 .
Stal是一個軟件工程系教授，西門子的首席工程師，對他來說，架構的目標是建立實現的支柱。他相信早期提出的定義常常會與專注于組件協作混淆。他覺得應該思考一下屬性，所以他添加了9個額外的屬性到他的列表中。
任何 軟 件密集型系 統 都展 現 出一個系 統 架構 。Stal聲稱系統必然存在一個架構，即使是那些基于臨時決策開發的系統。對他來說需要的是一個由明確定義、已確定優先順序與相關性的需求及風險所驅動的系統化架構設計。
有兩 類 架構 品質 。外部品質定義了品質屬性所需的可視行為，而內部品質定義了被開發者所采納的如簡化和富表現力的屬性。
一套 統 一的指 導 方 針 和工具必 須 能指 導 架構 設計 。對Stal來說這是達成高品質必不可少的條件。指導方針能幫助避免架構在各種設計模式和技術中變得臃腫而減低內部品質。
軟 件架構作 為具體產 出就是 設計 決策溝通的 結 果 。所有架構決策必須是明確的且根據不同的利益相關角色責任而描述出來。架構是初始代碼框架設計和定義的基礎。
軟 件架構必 須 包含 問題 域和解決方案域 。Stal注意到這個屬性推理出多層設計不是一個架構。他同時注意到要避免龐大的設計，兩個領域都應該構建子領域，且軟件架構活動行為的組織由這些子領域所驅動，而不是組織本身去驅動，可以參考 Conway’s law 。
Stal的最后4個屬性主要是針對架構設計在整個系統生命周期中如何跨度，架構設計如何遵循測試驅動方法，為此架構必須與其環境保持分離，它在特定領域內定義了由多個系統所組成的系統。
在與InfoQ的一次訪談中， Stefan Tilkov 認為Stal的文章寫得很好但Tilkov注意到他可以不將架構視為一套獨立于開發的流程，他將架構看作是項目的一個功能和組織的大小。他也提到與將架構看成“系統的描述或系統想要的形式”不同，他覺得架構是“系統所擁有的某種東西”，無論架構是如何被創建的。