第一部分——即使拥有全部需求和最佳设计，你的架构仍然很可能失败，原因在于……

目前的管理学校，教育培养的是公司经营者。设计公司几乎没有引起重视……几乎从来没有任何人为了取得计划的增长和稳定性，有意识和有思想地设计一个组织。

——  Jay W. Forrester，设计未来（1998）

介绍

在一篇名为《动态业务应用势在必行（The Dynamic Business Applications Imperative）》的论文中，Forrester的高级分析师John R. Rymer指出了当今应用的一个致命缺陷：

当今应用迫使人们去寻找一种将孤立的信息和功能组映射到他们任务和过程的方法，它们强迫IT人员花高额预算来跟踪不断变化的市场、策略、规章制度和业务模型。

在下一个5年内，IT的主要目标应该是发明新一代企业软件，适应业务和业务工作，同时能随业务演变而演变。

Forrester称这个新生代为动态业务应用，强调了和业务过程及工作（为人而设计）的紧密配合，对业务变化的自适应（为变化而构建）。在这个阶段，动态业务应用的需求比创建它们所需的设计实践更清晰。工具都是现成的：面向服务架构（SOA）、业务过程管理（BPM）和业务规则领域中的先驱——包括独立软件开发商（ISV）——已经开始向我们展示了这种方法。现在就是开始这段旅程的时候。

在这篇由两部分组成的文章中，我们会从架构和方法论的角度，采用历史的观点来看待这些动态业务应用（DBA）的发展。我们的目标是获得一种能使应用容易适应业务变化和其他必要修改的构建方法。随着企业在21世纪关注灵活性，DBA是使业务和IT在未来几十年内成功的关键。

图 1. 灵活性和效率——21世纪企业的两个主要驱动力

动态性对我们意味着什么？

在软件工程领域，许多框架或产品都声称具有自适应性。在我们设法理解一个解决方案在适应变化方面究竟有多好之前，需要给系统是如何变化的——它们的动态性——下一个可靠的定义。

早期的面向对象方法论认识到[1]：为了使系统分析中立，它必须基于两类现实世界的需求：

• 现实世界的实体 —— 收集现实世界实体的信息和它们间的关系，有助于分析师开始以一种系统的、结构的、客观的观点来看待需求，而非一种技术的、主观的观点
• 现实世界的事件 —— 系统行为只由改变现实世界实体状态的事件的出现来驱动

在这样的背景下，对于每一个被分析的系统，我们总能识别一个或多个最重要的实体。每个实体都又包含3个关联元素：事件、状态和生命周期。每个事件代表状态中的一个变化，所有普通实体状态的有序和代表了一个生命周期。但是，那些触发状态变化且是正常流程一部分的事件与那些触发状态变化但不是正常流程一部分的事件之间有明显的差异。例如，当一个产品订单被提交之后，一组可能发生的事件包括付费处理和订单交付。当一个用户变更订单或当企业改变价格时，我们不能认为这些动作是正常流程的一部分，因此它们与实体（如订单）的生命周期无关。核心实体实例的生命周期单独定义了在正常操作中系统最有可能处理的东西。所有其他事件类型，如变化或中间步骤，被区别对待。

这个场景对很多工程师都不陌生：一个系统模型包含一个核心实体结构，该实体具有一组事件，这些事件组成了实体的生命周期。这个系统模型对分析师和设计者都很清晰且易于理解。建模工具，如有限状态机、实体关系图、实体状态转换图和数据流图，为了帮助这种方法已经经过了快20年的完善。那些为复杂系统（如空客380或F-22，后者是世界上最高级的战斗机）服务、拥有数十亿行代码的软件就是这样被编写出来的。使用对象流图（它是捕获事件和状态转换的基础模型）虚拟化实体生命周期是这个模型的关键。在这个情况下，架构可以被认为是静态的，因为整个系统状态在时间轴上的任意一点都是确定的。

图 2. 事件模型、状态变化和生命周期是正常操作的核心

普通事件、状态、生命周期间的关系，以及从其他事件类型中分出的普通事件是理解所建议的动态操作框架的基础。正如James Martin 和James Odell很久以前在《面向对象分析设计》中所写的，分析师、设计师和实现者都应该使用同一系统模型。分析师使用数据流图思考，设计师使用结构图思考，程序员使用Java和SQL思考。在数据流上下文中，分析师识别对象类型，并思考改变对象状态的事件。最终用户也理解这个相同的认识。他们也应该按照对象类型、事件、对象状态的变化，以及触发和控制事件的业务规则进行思考。Martin和Odell强调了对象流图对系统设计师的重要性：“事件模式适合按照事件、触发器、条件和操作来描述过程。但是这种方式不适合描述大型复杂过程。一个系统领域常常太大或太复杂，无法表示成事件和触发器。此外，可能只有一个高级别的认识才是必要的。这对战略级别的规划尤其正确。在这样的情况下，一个对象流图是有用的。对象流图（OFD）与数据流图（DFD）类似，因为它们描述了活动和其他活动间的接口。在DFD中，这个接口传递数据。在对象技术中，我们不再限于数据传递。相反，图应该表示从一个活动传递到另一个活动的任何类型事物：不论它是报表、零部件、已完货物、设计、服务、硬件、软件——或数据。简而言之，OFD指的就是被产生的对象，以及产生和交换它们的活动。”

为了捕获与业务操作关联的信息流，业务分析师用价值流程图（Value Stream Mapping）对OO方法论进行了补充。价值流程图起源于丰田，与精益制造关系紧密。美国国家环境保护局将价值流程图定义为“用来认识那些产生产品或交付服务的活动序列与信息流程的精益过程映射方法。”此处的关键词是“产品”和“服务”。它们显现了合适的信息流程在整个企业中扮演的统一角色。

把过程流图和价值流程图两个概念结合在一起后，它产生了一个完全代表整个企业经营范围、可被方便翻译成OO（图2）概念的框架基础。

但是，许多系统并不是静态的，它们变化无常的行为无法被一组关系和事件捕获。事实上，它们发生在不可知的[2]未来，传统用来捕获它们动态特点的工具不起作用。所有的业务应用和绝大多数现实世界的系统都归于此类。这些系统，基于它们和其他外部系统的交互方式，处理3类变化：

• 正常工作 —— 组成主实体或实体们生命周期的正常事件序列。通过每个事件——实体改变其状态——通常可以方便地定义一个过程。在正常工作行为内部，有些操作上下文元素不期望被改变。例如，当一个客户订购一个产品时，在整个提取订单、准备订单和交付订单的过程中，诸如价格、组成和交付方式等是不期望被改变的。
• 内部变化 —— 如上所述，在整个核心实体生命周期内，某些上下文元素不期望被改变。在现实世界中，这并不总是真理，因为管理决策或其他因素会迫使上下文元素变化。我们称内部系统属性的变化是内部变化。
• 外部或环境变化 —— 不管一个企业如何相信他们“拥有”一个客户，但是这个客户总有保留改变他或她意志的自由。一个系统不太可能与外部系统（如客户或供应商）总是有一个“固定的”合同。然而，正常工作很可能围绕这个“固定的”规则集合进行设计。我们称系统外部引起的变化为外部变化。

要对现实世界系统建模，就必须处理好这所有3种变化类型。这种模型与静态架构模型相比，在管理复杂性上有了极大的提高。从正常工作的观点来看，内部和外部系统完全独立于主信息流运行。内部和外部系统甚至有它们自己的操作——管理有其自身的决策周期，客户有其自己的操作环境——由各自的信息流描述。就信息流而言，这3种系统分别运行在3个平行宇宙中。解决这3种非同步信息流的唯一办法就是为每个信息流实现一个独立全面的变更管理。这种复杂交互在图3（动态操作图）中表示。

邮轮公司给客户提供的服务可以作为解释动态操作的例子。在订购时，一个客户会决定在游览期间他计划参与的服务。但是，不仅客户可能在游览前和游览中改变主意，而且邮轮公司也可能会为了利用新机会或应对未知事件改变服务。按照当前方法设计的系统，大部分变更都以极高的运营成本人工处理。使用基于动态业务应用架构原则设计出的系统，来自客户和内部管理决策的变更由两个与正常工作完全集成的变更管理子系统负责。这不仅能降低成本，而且还提高了服务质量，甚至可以最优化运营来提高利润。因为是完全通用的，它还可以重用标准组件。最终结果对于参与的每个人、业务、IT和客户来说是多赢的。

图 3. 动态操作有3个维度——正常事件、内部控制和外部反馈

动态业务应用的目标之一就是使设计和软件实现变得简单，以支持对所有业务来说司空见惯的动态系统。以我们的经验，与一个框架优先的工程学相结合是构建一个DBA的最有效的技术方法。

设计企业系统要求框架先行

构建动态业务应用说起来简单，做起来难。工程，包括软件工程，都采用了有百年历史的框架优先方法。设计一座桥梁、一架飞机或者甚至是一个软件应用都使用相同的方法：一个设计团队先收集需求，然后使用一组定义良好的框架步骤来设计和构建系统。在设计桥梁和其他工程系统时，现有框架已被证明非常成功。但在使用它来为业务系统开发软件时，却碰了壁。这两类系统之间有一个根本区别。在设计桥梁和飞机时，最终结果总是一个拥有静态架构的系统：当变更发生时，如增加桥梁负重或飞机速度，整个系统可能就要重头重新设计。不幸的是，软件也常常使用一个静态架构进行设计：每当一个非预期的变更被引入到运营中时，很可能所有事情都停了下来，使用包含新增功能的系统替代现有系统。因为业务运营在一个不断变化的环境中，而且比以往更依赖IT系统，这种停——走式的解决方案是不可接受的。持续升级和在企业基础设施中集成系统的成本已经达到了无法支撑的地步。

依赖业务涉众作为我们全部需求的输入首先就是个问题。考虑到需求，目前还没有真正适合动态操作的“框架优先”软件设计方法。甚至卡内基梅隆软件工程学院也表示架构是由场景驱动的，场景以涉众输入为基础被创建出来：“诱导一个软件密集型系统的业务目标是标准架构设计和分析方法的一个组成部分。业务目标是驱动方法的引擎，通过将它们的实现作为场景……一个理想的设计方法或过程必须考虑众多涉众和众多影响。”

作为工程师，当我们收集系统需求时，我们怎能知道我们得到了正确的场景或是否遇上了正确的涉众？我们又如何能说明业务未来的变化，而这些变化通常连参与的涉众都不知道？

“企业经营者和企业设计师之间存在着根本区别。为了说明这点，考虑一下在一架飞机成功操作背后的两种最重要的人。一个是飞机设计师，另一个是这架飞机的飞行员。设计师创造的飞机连平庸的飞行员都可成功驾驶。一般情况下，经理更像是飞行员而非一个设计师。一个经理管理一个组织，这和一个飞行员驾驶飞机没什么两样。飞行员的成功依赖于那些创造了一架成功飞机的飞机设计师。另一方面，是谁来设计一家由管理者管理的公司呢？几乎从没有任何人有意识和有思想的去设计一个组织，以取得有计划的增长和稳定性。在当前的管理学校中，教育培养的是企业的经营者，而如何设计企业几乎不受重视。”

在几年前完成的报告“设计未来”中，MIT的教授和系统动态之父Jay Forrester，指出这个问题是我们为企业设计系统的基本限制：

Forrester的观察进一步使当前的企业架构方法失效。在我们需要设计一个企业系统架构时，作为知识主要来源的涉众甚至是错误的分类。他们是企业的“用户”，不是“设计师”。在设计飞机时，飞机设计师决不可能去询问飞行员或乘客关于飞机制造方面的事情。但是，在学校、工程或MBA课程中却没有企业设计这门课。

那么回到企业架构，其中有一个根本的断档。企业架构的“用户”是企业涉众，很可能是熟悉企业动态性的企业毕业生，但是他们不熟悉工程方法。企业系统的设计者和构建者——软件工程师——熟悉静态框架，但是对动态框架却很陌生。事实上，还没有说明业务动态的框架。根据企业架构框架，这是一个需要填补的缺口。这个框架只描述企业是如何“被设计的”，但是也会定义开发路线图和主要组件，使用它们来构建企业的支持系统。

图 4. 企业架构的业务和工程方法

我们建议根本改变我们架构和设计信息系统的方式，以一种不要求业务涉众作为主要输入的方式。我们推荐利用一个以业务实体生命周期和事件模型为中心的框架作为架构的主要输入来源。业务场景只被用来微调一个已完架构，而不是作为主要驱动力。

这种框架优先方法从一开始就说明了业务动态，而不是事后诸葛亮。它暗示被设计的企业应用是动态适应的，而不是像由今天的方法论所实现的那样是静态适应的。这种方法成数量级的减小了开发和维护软件的成本，并砍掉了与改变和维护现有系统直接相关的超过70%的IT开销。

Fig 5. 基于框架的软件解决方案开发方法

在我们建议的方法中，业务场景只被作为一个已完架构的微调，而不是主要驱动力。我们将我们的直觉、经验和技巧输入到设计过程中越晚，产生导致巨大损失的错误的可能性就越少。由涉众输入引起的需求变更会在已经建好的现有解决方案框架中处理，减少了风险和延迟。

一份Standish报告研究表明，超过1千万美元的项目，成功率只有3%。行业咨询和哈佛商学院教授Andrew McAfee表示，部署如此高成本技术（如ERP、CRM、供应链管理、电子商务和其他企业应用）组织的成功率在25% ~ 70%之间。McAfee总结说：“这些面临的问题并非是单独的，它们都是同一事情的不同例子，基本上都是使用IT改变业务过程的结果。”。最近，这些百分比有所提高，但是对于复杂系统IT仍缺乏清晰的路线。框架优先的方法能使业务变化集成到IT实现中，并提供了业务和技术之间更清晰的转换，可以将成功率提高接近100%。建构复杂系统的时间由几个月或几年缩短至几天。

动态操作的服务器架构 —— 忘记SOA，迎接信息装配线

90年代早期，事件几乎是每本面向对象方法论书籍中的核心角色。随着象Windows这样基于GUI操作系统的出现，GUI开发平台依靠复杂事件模型来设计和构建单个应用。但是，在客户机-服务器环境中，服务器端的事件处理总是基于一个简单得多的模型。

当基于Web的技术（如J2EE和.NET）开始替代传统的客户机-服务器应用，客户机和服务器都经历了根本的转变。客户端的富OS事件模型由Web浏览器和原始的脚本语言代替。在服务器端，事件处理由无状态、扁平的、静态架构所替代。其方式非常类似将网页传给Web浏览器的方式。

为了模拟现实世界的需求，需要一个有状态的、层次的、动态的和分布式的架构，设计必须严重依赖数据库来存储范围广泛的各种动态信息。但是根据其定义，关系数据库非常适合存储不常变化的数据间关系。保存动态、分布式、层次的和有状态信息要求一个不同的基础设施，它不是以关系数据库为中心的。

基于Web的技术为支持现实世界系统引入了其他挑战。当J2EE应用服务器在一个分布式环境被使用时，使用Java作为编程语言的一个最大优势完全没有了。Java虚拟机的垃圾回收从来没有被设计成能自动清除在多实例间交换的内存对象。在这种情况下，架构师和设计师必须编排整个对象生命周期，不考虑编程语言的能力。甚至在数据保存在数据库中时，这种相同的数据清除问题也变得非常困难。

正如我们已经看到的，一旦我们能从正常工作中分离变化，架构就能只依赖事件和生命周期进行设计和实现。围绕生命周期进行系统设计已经经历了一个世纪——它被称为装配线。

在装配线于20世纪早期引入之前，制造业的工作方式多多少少和今天面向服务架构（SOA）处理信息的方式一样。每个对于SOA服务的调用一般都被视为一个无状态调用。为了说明以前调用的历史，每个服务必须完全实现如何处理系统内部状态。一旦需求改变，几乎所有服务也需要以成本极高的方式重新编码来改变它们各自的实现。

图 6. 服务器架构是以事件模型为基础的

我们建议使用以事件模型和生命周期为中心的信息架构作为业务需求和系统架构的双向翻译平台。事件模型在下一级被扩展成四个基本模型：状态、分布式、层次和动态。所有这5个模型可被基础需求和架构模型中的业务或技术人员方便地解释：

• 事件模型/生命周期—— 它是构建其他模型的基础核心。对业务用户来说，它是价值流，反映产品/服务生命周期和为客户创造价值的过程序列。对技术人员来说，同一事件序列反映了代表业务实体对象的状态变化。最终结果是，事件模型扮演了解耦元素，大大简化了设计和实现。事件模型还扮演了另一个重要角色。因为其他四个模型是围绕事件模型而构建的，它还扮演一个集成平台。事实上，事件模型是创造实现变更、层次和分布式组件的唯一办法。
• 状态模型—— 对业务用户来说，这个模型扮演了企业的面板，捕获当前经营的整体状况。对技术人员来说，它是系统的整体状态，它是全部生命周期实例的当前状态，以及它们的变化之和。
• 分布式模型 —— 对业务用户来说，这个模型捕获了其生命周期内控制产品/服务的各种组织。对技术人员来说，主实体只能基于分布式模型来控制。
• 层次模型—— 所有业务都有代表管理层级的层次结构。所有系统设计应该在架构上反映这种控制层次。正如销售VP不能给CEO下命令一样，低层级的组件不能给高层级的组件发送执行“命令”。
• 动态模型—— 继事件模型之后最重要的模型。业务用户使用它来捕获平时必须被处理的全部变更。如前所述，有两种变化类型：外部，如客户输入；内部，如管理决策。对技术人员来说，动态模型被翻译成一个匹配各种事件、生命周期和变化类型的插件架构。

这5个模型不仅可以被用在初始设计，对贯穿整个系统生命周期的需求变更亦有裨益。它们一起形成了自适应系统设计所缺失的框架步骤。这5个模型排除了用例作为企业架构的主输入的必要性。它们可以被翻译成一个清晰和全面的工程问题集合，与在桥梁或飞机设计中使用的方法类似。

图 7. 自适应架构是以5个模型为基础的信息架构结果

这5个模型定义了以信息变化和装配线为中心的动态业务应用通用架构。最重要的子系统是：静态模型、变更管理、虚拟装配对象和事件处理。在下一个细化层级，还有两个子系统：系统命令和控制与持久化。

这个架构还解决了在寻求一个适用于事务型工作流隐喻的通用解决方案过程中长期存在的问题，它是由Jim Gray[3]在几十年前提出的。因为整个设计以单个事件的执行为中心，不仅可以实现“移动到下一个装配步骤”，而且也可实现“移动到前一个装配步骤”。实现需要根据用户的输入决定前往哪个“方向”。通过将多个步骤“链接”在一起，可以使用相同的架构实现一个事务型工作流的“撤销（Undo）”操作。

动态业务应用的一个关键元素是事件处理。使用新的自适应系统信息理论，可以使用一个通用组件结构来“执行”每个事件。这个组件使用声明性编程来内嵌业务逻辑、调用工作流引擎、调度器和业务规则引擎。这个实现不仅可以极大加速自适应系统开发，而且可以使后期改变非常容易处理，也减少了维护复杂集成的需要。

我们建议围绕事件（操作）和事件生命周期创建一个供给控制、运营和环境的物理模型。生命周期控制器为离散事件管理装配信息。变更管理功能指导标准事件模型和个体事件内外部变更的执行。

结论

我们已经讨论了扁平、无状态、静态、客户端——服务器、基于Web的解决方案的演变方式所带来的IT架构和层次、有状态、动态、分布式业务的现实世界之间的脱节。我们还讨论了传统工程方法为什么不能支撑能支持动态业务的自适应系统的开发。我们展示这两个问题的可能解决方案可以用一种新的模型驱动架构方法来找到。

本文转自infoQ中文站  作者 Vasile Buciuman-Coman, Michael Chervenic  译者 胡键