架构决策作为可复用设计资产
本文最初发表在IEEE软件杂志，现在由 InfoQ & IEEE 计算机协会为您呈现。
软件架构师在设计时需要作出很多决策。作出正确的关键架构决策，其重要性不言自明。1-3但是，要总结出什么是关键决策绝非易事，更不用说何时以及如何作这样的决策。早先，架构决策作为设计决策的一部分已被定性为做起来很难4，改起来又费劲。5为了澄清这些问题，我们在下面给出的架构决策定义中增加了一些条件逻辑6：
架构决策要识别出关键设计难点和隐藏在所选方案中的原理。它们是慎重的设计决策，这些决策将软件密集型系统视作一个整体或将该系统的一个或多个核心组件及组件间的关联关系归于任意既定的视图。架构决策产生的结果影响系统的非功能性特征和软件质量指标。
根据上述定义，无论是选择一门编程语言、架构模式、应用容器技术或中间件资产都算作架构决策。比如，Broker这样的集成模式描述了分布式系统会遇到的阻力，包括位置独立性和网络问题7 。这些阻力适合作为决策的驱动力，所以是否将Broker模式添加到架构中来就是一种需要慎重判断的架构决策。一些顶尖的软件工程方法，比如IBM统一方法框架（Unified Method Framework），需要将架构决策记录成文并且在统一的地方对这些关键决策进行论证8。
在把各个功能分散对应到各系统模块时，记录日志可以保证设计的完整性。通过确保架构的可扩展性，这些日志支持渐进式系统。它们也为新加入项目的人员提供了参考，以避免对已经确定了的问题重复考量。日志可以在事后捕获架构决策。创建这种日志是一种短期受益很少但长期受益颇多的文档活动9。如果我们对某个特定的项目放松文档要求，并假设同一应用类型的多个项目遵照同样的架构样式——共享同样的原则和模式——那么我们可以考虑将架构决策从文档工件升级为设计指导。
这些设计指导可以帮助那些习惯了某一特殊类型的应用和架构风格的架构师们理解做决策的需求和可选方案，而这些方案往往基于成功应用于类似情况下的相同知识。这样的话，重现的架构决策就成为可复用资产，就像方法和模式那样。这会衍生出新的使用场景。比如，重现的问题可以用作审核检查列表，帮助划分设计和开发工作项的优先级，促进企业和项目架构师之间的沟通。
SOA决策——建模框架
在设计过程中将重现的架构决策提升到指导角色的高度，首先需要有效地捕获和总结相关的项目经验。这是知识工程的行为。面向服务架构（SOA）决策建模（SOAD）提供了支撑该行为的一种知识管理框架10 。 当SOA风格应用于某一特定类型的应用，如企业应用，SOAD可提供一种技术以系统地识别这些应用中重现的那些决策。SOAD对已有的元模型和模板进行了增强8,11 ，具体说来就是将决策需求从决策制定中区分出来。它建立了多层次的知识组织可以将平台独立的决策从平台特定的决策中区分出来。在概念层次，设计备选参考架构模式，比如Martin Fowler定义的那些12 或其它的7,13,14。
SOAD框架使得知识工程师以及软件架构师能够管理决策依赖，这样他们可以检查模型一致性并删除不相干的决策。一个条理清晰的问题集可以指导决策过程。有了框架提供的支持，架构师能够根据决策更新设计工件，而决策是通过将决策产出件注入模型转换中而实现的6。
为了支持复用，SOAD元模型定义了两种类型的模型：
- 指导模型用以识别必需的决策。
- 决策模型用以记录决策制定。
图1展现了这些模型之间的关系和内部结构。6
图1. 面向服务架构（SOA）决策模型（SOAD）框架。SOAD元模型被实例化到一个指导模型内，该指导模型可识别某一特定架构风格（如SOA）所必需的决策。架构师对指导模型做裁剪以创建针对某一项目的决策模型雏形。
指导模型是一种可复用的资产，它包括在某类特定应用类型中使用某一架构风格时所必需的架构决策的知识。该模型基于已完成的、采用同一类架构风格的项目中获得知识。如图1所示，每个问题都提示架构师：这是一类特定的设计问题，需要作出架构决策。问题反映了决策驱动各种类型，比如质量指标、根据其优点和缺点确定的参考潜在备选方案以及在之前应用中的已知用法。知识工程师将这些问题和备选方案写成文档，编写文档时采用将来时态，其口吻就像技术导师在交谈时所使用的口吻一样。
通过裁剪不相干项、改进增强相关项、增加新问题项，指导模型可为具体项目提供指导。决策模型作为架构文档工件不仅包含需要做的架构决策，还包含已做完的架构决策。其输出件是项目中实际所做决策的日志记录，并附带决策依据。在SOAD中，产出件代表软件架构师现在（或过去）在项目中获取的设计研讨纪要。一个决策模型可以重用一个/多个指导模型。它可以为已作出的决策提供信息使其在项目结束后通过资产总结活动（可能包括所有从以往经验中得到的正式或非正式评论）将信息反馈给指导模型。在SOA设计中，比如，一个保险公司的业务流程模型可能描述了某个后台系统必须实现和集成的三个不同的业务活动（客户索赔、理赔审核和风险评估）以及相应的服务操作。
架构师必须要为项目选择一种集成风格，比如由Gregor Hohpe和Bobby Woolf针对此问题识别出的四大可选模式之一：文件传输、共享数据库、RPC或消息传输13。架构师也必须选择一种集成技术，如HTTP和Java消息服务（JMS），以使不同业务活动之间相互交互。问题陈述（“在业务流程中的业务活动及服务操作和其他模块——比如遗留系统——交互时，将会用哪种技术？”）以及决策驱动（“互操作性、可靠性和工具支持”）对所有三种服务操作同样适用。
与具体项目相关的决策成果，比如备选方案及理由，取决于每个操作各自的需求。比如，“对于客户索赔来说，我们选择RPC和HTTP的理由是Java和C#模块必须以一种简单并可交互的方式来集成，所以我们看重可用Web services工具的支持。”可是，“对于风险评估来说，我们选择消息传输和JMS的理由是需要集成的一些后台系统可用性较差，我们一定要保证消息的可靠性。”
从一般性问题到SOA指导模型
我将使用保险公司的例子来做总结，然后扩展出两个必需的决策——集成风格和集成技术的问题。首先需要把那些CS架构中出现的普遍问题加入到一张通用的模块及连接器的图中，如图2所示，模块和连接器都是服务消费者（客户）和服务提供者（服务）在分层系统中的一种概括。
图2. 通用的模块及连接器架构中普遍存在的问题。每个模块和连接器产生的问题是普遍问题的具体化。该层次可向下一实现层转变，譬如从概念模型组件模型，到细化组件模型，再到实现组件模型。
举例来说，层次n可能被实例化为表现层、业务逻辑层和持久层之类的面向服务的企业应用12。 从这样的实例化来看，保险公司示例中的三个业务活动（客户索赔，理赔审核和风险评估）和服务操作都属于架构中业务逻辑这一层。在优化设计使之成为具体架构时，图中每一小块（比如，图2，“接口签名？”）都应该看作一个普遍问题，需要仔细研究。接下来需要将普遍问题和SOA模式结合起来。有些作者已经对该SOA模式进行了描述——比如Uwe Zdun和他的同事们14。 SOAD框架将使用如下SOA定义6：
从架构设计的视角来看，SOA引入了一个服务消费者（请求方），一个服务提供者和一份服务契约。这些模式促进了架构模块化和平台透明性原则。组合架构模式，如企业服务总线（ESB），管理服务消费者与服务提供方之间的交互和物理分布，以此来支持诸如协议透明性和消息格式透明之类的原则。服务组合模式将各种处理逻辑组合起来，参照逻辑分层原则和流程独立性。而服务注册模式定义了如何查找服务提供者等相关原则，如位置透明和服务虚拟。
图3描述了将通用的CS组件实例化成功能架构概览图中，解释了这些模式机器构建模块在SOA中是怎么交互的6。
如图3所示，SOA风格的本质是通过服务契约、ESB消息传输和服务注册达到服务消费者和服务提供者之间的解耦。ESB模式由另外三种模式组成：中介器模式、路由器模式和适配器模式。为了将平台特定设计从平台独立设计中区分开，SOA基于模式的特征淡化了Web Service等技术。将图2中的普遍问题和图3中的SOA模式结合起可以引出具体问题的重现。识别这些问题及备选方案可以使技术专家们从使用这些模式的项目经验中获得决策驱动因素、优点、缺点以及建议。
图3.SOA模式及其协作和功能性分解。服务消费者和提供者通过ESB模式进行交互。服务注册罗列出服务消费者可用的所有服务契约和服务提供者。
执行层决策
认定SOA为首选架构风格，这本身就是一种管理决策，因此选择特定的SOA参考架构就是执行层的决策。这需要在名词术语上达成一致，比如层次和模块的名称，相关模式语言的识别。架构原则也可能采用执行层决策的形式，比如，选择开源资产还是某软件厂商和服务器基础设施？这对应到图2中的通用问题就是“整体的层次间组织结构？（Overall layer organization）”
概念性的、平台独立的设计问题
服务设计者必须根据操作签名中的请求和响应消息参数来决定服务契约的粒度。这些签名指定了服务调用的语法和消息载体的结构。这一问题关心服务契约的设计。根据图3所示的SOA模式，服务契约是SOA接口的实例化；因此，根据图2，通用问题“接口签名是什么？（Interface signature）” 适用于该设计上下文。详细的ESB设计和配置又引起另一类问题。架构师们必须选择消息交互模式，比如单向操作及请求——应答（异步与同步通讯）。他们也必须要详述路由器、中介器和适配器模式的具体用法，描述如何将消息从服务消费者转移到服务提供者（路由器）、如何当消息在ESB（中介器）中传输时进行消息内容的转换、如何与非SOA的系统和模块（适配器）进行集成13。
遵循SOA风格的架构师也必须细化服务组合设计（如果他们选择了这种SOA模式）。选择某个集中式流程管理器13，如工作流引擎（与之相对的是在各个应用或模块中的分布式状态管理），就业务逻辑层的内部结构而言，是一项重要的架构决策。至于服务注册，设计时和运行时的注册查询是设计问题的一个例子。“组件的生命周期管理（Component life-cycle management）”是对应的通用问题（如图2）。
平台相关的设计问题
概要设计问题不会涉及到任何技术标准或其具体实现。然而，选择一种或多种SOA模式的架构师也必须负责解决平台相关的问题——比如说，选择并勾画诸如WS* Web Service作为集成技术的具体实现技术。一旦选择了某种技术，架构师就必须选择和配置实现平台。许多SOA模式都有商用和开源中间件的实现。架构师必须决定是否需要购买该中间件以及，如果购买了，如何进行安装和配置。
可复用的设计资产：SOA指导模型
根据前文摘要中的定义，我描述的所有SOA设计问题都适合作为架构决策。比如，服务操作的签名将会对性能和互操作性等质量属性产生影响。而且，这些问题会重复出现。只要一个项目应用了SOA模式，那它就必须一而再再而三的解决类似的问题。因此，我们期待知识的重复利用。
我在SOA指导模型中收集了500个经常重现的问题6,10。
SOAD案例研究报告
实践架构师已经在十多个项目中成功地应用了SOAD和SOA指导模型。这些项目包括为欧洲某国社会保障部开发的养老金计划管理应用、为某电信公司开发的客户和订单管理方案以及为某多渠道零售商开发的B2B电子商务应用。这些案例研究确定了很多重现的问题。参与项目的架构师对SOA指导模型中知识的相关性和可行性方面做了评估。评估结果表明在设计活动方面速度和质量都有改进，并且SOAD视角和方法也广受赞赏6,9。
SOAD框架反馈
在案例研究项目过程中，我和几百位架构师就SOAD的价值和可用性等方面进行了交流，听取了他们的反馈意见。只有一位架构师公开不同意SOAD的基本假设 ——即当在同一类型的项目上使用相同的架构风格时，会出现相同的架构决策，而这一反对最终发现实际上是误会一场。SOAD并没有声明某个决策始终会产生相同的成果；它只是表明那种对决策所需要的问题，会重现。
案例研究参与者们发现SOAD元模型是能够被直观理解的、包含有用且充分的信息，这些属性都有助于做关键决策。他们还建议添加一些别的属性。他们还建议采用不同的方式来构造指导模型——包括由企业架构框架定义的组织机构的维度。
参与者将决策的依赖管理视作决策模型的一项重要优势，因为用文本形式的决策日志来管理这些决策的依赖是很困难的。他们还指出，当一种成熟的决策方法已经存在时，任何其他的方法都必须与其保持一致。他们将SOAD视作一种支撑资产——一项内置在通用目标方法中的决策制定技术——而不是一种孤立的方法。
SOA指导模型的反馈
案例研究的参与者都很认同指导模型的内容和各细节层次。他们认为它不夸张很合适、与SOA行业项目相关、而且归档清晰，总之是恰如其分。
他们对主动决策模型和回顾市决策模型有一些疑惑。有一个用户通过决策日志简单地从指导模型中拷贝问题的描述和建议属性，由此生产决策依据。这在部门内部技术质量评估审核会上，这一做法引起了高级架构师的批判。总之，必须要对使用SOAD的期望进行管理。SOAD的不鼓励孤立地执行架构思考。
使用场景和讨论
SOAD是以决策为中心的方法指导设计工作的。它的一大优势是目标受众、软件架构师能从不同的使用场景中理解架构决策的核心概念——架构文档。这使SOAD在其他场景中的的应用得以简化：
- IT用户可以通过要求提供方交付标准的、与其软件方案或产品一致的决策日志来维护对他们应用的控制。用户可以根据SOAD元模型使决策日志结构化，并从共享指导模型中生成这些日志。
- 那些开发多种软件密集型产品（线）的公司可以要求其企业架构师创建一个公司范围的指导模型。通过采用公司指定的SOAD元模型、方法和工具组能够对指导模型活动提供支持。这种方法可以缩短产品近入市场的时间，还能使不同产品的架构保持一致。
- 指导模型中加注了最佳实践建议，通过共享其中的技术知识，提供复杂商业套件的厂商可以减少培训、客户化定义和技术支持。
- 在专业服务中，实践群体重视明晰的知识管理，可复用资产能够创建指导模型用以支持基于劳动力的交付模型向基于资产的交付模型（战略再利用）转变。
- 培训师可以将指导模型作为一种系统化的方法来教授模式和各种技术最佳实践。
- 那些想要以一种可复用的、高效的方法来评估中间件和企业应用分析师和受众可以把标准化的、领域相关的问卷建立在可复现的设计问题上。他们可以根据SOAD元模型来为这些问题建模。
SOAD 假设多数问题都会重复发生。如果不是这样的话，那指导模型资产不能为其产出物带来足够的价值。如果多个项目采用相同的架构风格，那么问题发生的假设很有可能成立。然而，使用SOAD描述问题和备选方案还包括对知识工程的承诺。指导模型必须比具体项目的决策日志具有更高的编辑标准，所以创建这样模型的决策必须支持知识管理策略。它需要一个基本的模型、一个审核、批准和维护流程。使用SOAD三年，我的经验告诉我，平均来看，专业工程师完全可以在一个人天内完成对一个问题的建模。
架构师已经能够从不完整的建模知识中获益，比如以问题的形式清晰地描述的问题检查清单。除此之外，工具能够部分地自动化生成资产 ——比如，从项目工件中提取出架构知识的挖掘工具。从工具设计的角度来看，展示信息的多少、上下文相关的过滤和排序能力是成功的关键。架构师一般都会花时间和企业（组织）内外的干系人进行沟通，所以他们不一定愿意从头到尾阅读指导模型（虽然我一些同事已经这样做了）。工具可以将指导模型裁剪到和某个给定设计上下文相关的问题和备选方案，要先裁剪然后才能在项目中全面施行。SOAD的元模型能偶这样的工具开发，比如，为问题设定范围属性，指出问题一般应在那个项目解决得到解决。
结论
最初创建SOAD 的原因是支持企业应用和SOA设计，而指导模型的使用则是作为可重用资产也适用于其他应用系统和架构风格。它支持的应用场景包括教育、知识交换、设计方法和治理。下一步对它的扩展包括，将其扩展到其他的业务和技术领域以及目标受众，如除软件架构师之外的业务人员。其他解决指导模型所面临的挑战的计划，比如知识可视化和维护性15 。
指导模型编制了重复出现的问题和选项，通过这种方式来推进架构知识的重复使用，自此，SOAD使得架构师能够在某个问题的求解上下文中分享最佳实践。我们可能从错误中能够得到最好的学习，谁规定了所有的错误都必须要自己犯过才行呢？
关于作者
Olaf Zimmermann是IBM苏黎世研究院的一名研究专员。他的研究兴趣关注于应用和集成架构、SOA设计、架构决策以及各种服务和知识管理的框架。Zimmerman拥有斯图加特大学计算机科学专业博士学位。他也是开源组织的杰出IT架构师、IBM执行IT架构师并著有Web Services展望（Springer, 2003）一书。你可以通olz@zurich.ibm.com和他取得联系。
参考文献
1. L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, 2nd ed., Addison-Wesley, 2003.
2. N. Rozanski and E. Woods, Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives, Addison- Wesley, 2005.
3. P. Eeles and P. Cripps, The Process of Soft- ware Architecting, Addison-Wesley, 2010.
4. M. Fowler, "Who Needs an Architect?" IEEE Software, vol. 20, no. 5, 2003, pp. 2-4.
5. G. Booch, internal conference presentation to IBM Academy of Technology, 27 Apr., 2009.
6. O. Zimmermann, "An Architectural Decision Modeling Framework for Service-Oriented Architecture Design," PhD thesis, Univ. of Stuttgart, 2009.
7. F. Buschmann, K. Henney, and D. Schmidt, Pattern-Oriented Software Architecture, Vol. 4 - A Pattern Language for Distributed Computing, Wiley, 2007.
8. IBM Unifi ed Method Framework, work product description (ARC 0513), IBM, 2009.
9. M. Ali Babar et al., eds., Software Architecture Knowledge Management: Theory and Practice, Springer, 2009.
10. O. Zimmermann et al., "Managing Architectural Decision Models with Dependency Relations, Integrity Constraints, and Production Rules," J. Systems and Software and Services, vol. 82, no. 8, 2009, pp. 1246-1267.
11. J. Tyree and A. Ackerman, "Architecture Decisions: Demystifying Architecture," IEEE Software, vol. 22, no. 2, 2005, pp. 19-27.
12. M. Fowler, Patterns of Enterprise Application Architecture, Addison-Wesley, 2003.
13. G. Hohpe and B. Woolf, Enterprise Integration Patterns, Addison-Wesley, 2004.
14. U. Zdun, C. Hentrich, and S. Dustdar, "Modeling Process-Driven and Service-Oriented Architectures Using Patterns and Pattern Primitives," ACM Trans. Web, vol. 1, no. 3, 2007, article no. 3; doi.10.1145/1281480.1281484.
15. M. Nowak, C. Pautasso, and O. Zimmermann, "Architectural Decision Modeling with Reuse: Challenges and Opportunities," Proc. 2010 ICSE Workshop Sharing and Reusing Architectural Knowledge (SHARK 10), ACM Press, 2010, pp. 13-20.
本文最初出现IEEE软件杂志（双月刊）2011年第一期，64页到69页。IEEE软件杂志致力于为那些紧跟快速技术变更的软件从业者提供创新性思想、专家分析和各种真知灼见。
