介绍
作者：Vasile Buciuman-Coman, Michael Chervenic
原文：http://www.infoq.com/articles/dynamic-business-applications
第一部分——即使拥有全部需求和最佳设计，你的架构仍然很可能失败，原因在于……
目前的管理学校，教育培养的是公司经营者。设计公司几乎没有引起重视……几乎从来没有任何人为了取得计划的增长和稳定性，有意识和有思想地设计一个组织。
—— 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的最有效的技术方法。
网友评论