定义软件架构的10个属性
软件架构是一套流程；一系列将规格和业务目标映射为架构设计和具体产出的策略性设计决策；一套在区分不同利益相关者的过程中产出的视图， Michael Stal 陈述了 怎样定义一个软件架构 .
Stal是一个软件工程系教授，西门子的首席工程师，对他来说，架构的目标是建立实现的支柱。他相信早期提出的定义常常会与专注于组件协作混淆。他觉得应该思考一下属性，所以他添加了9个额外的属性到他的列表中。
任何 软 件密集型系 统 都展 现 出一个系 统 架构 。Stal声称系统必然存在一个架构，即使是那些基于临时决策开发的系统。对他来说需要的是一个由明确定义、已确定优先顺序与相关性的需求及风险所驱动的系统化架构设计。
有两 类 架构 品质 。外部品质定义了品质属性所需的可视行为，而内部品质定义了被开发者所采纳的如简化和富表现力的属性。
一套 统 一的指 导 方 针 和工具必 须 能指 导 架构 设计 。对Stal来说这是达成高品质必不可少的条件。指导方针能帮助避免架构在各种设计模式和技术中变得臃肿而减低内部品质。
软 件架构作 为具体产 出就是 设计 决策沟通的 结 果 。所有架构决策必须是明确的且根据不同的利益相关角色责任而描述出来。架构是初始代码框架设计和定义的基础。
软 件架构必 须 包含 问题 域和解决方案域 。Stal注意到这个属性推理出多层设计不是一个架构。他同时注意到要避免庞大的设计，两个领域都应该构建子领域，且软件架构活动行为的组织由这些子领域所驱动，而不是组织本身去驱动，可以参考 Conway’s law 。
Stal的最后4个属性主要是针对架构设计在整个系统生命周期中如何跨度，架构设计如何遵循测试驱动方法，为此架构必须与其环境保持分离，它在特定领域内定义了由多个系统所组成的系统。
在与InfoQ的一次访谈中， Stefan Tilkov 认为Stal的文章写得很好但Tilkov注意到他可以不将架构视为一套独立于开发的流程，他将架构看作是项目的一个功能和组织的大小。他也提到与将架构看成“系统的描述或系统想要的形式”不同，他觉得架构是“系统所拥有的某种东西”，无论架构是如何被创建的。