设计企业系统要求框架先行
构建动态业务应用说起来简单，做起来难。工程，包括软件工程，都采用了有百年历史的框架优先方法。设计一座桥梁、一架飞机或者甚至是一个软件应用都使用相同的方法：一个设计团队先收集需求，然后使用一组定义良好的框架步骤来设计和构建系统。在设计桥梁和其他工程系统时，现有框架已被证明非常成功。但在使用它来为业务系统开发软件时，却碰了壁。这两类系统之间有一个根本区别。在设计桥梁和飞机时，最终结果总是一个拥有静态架构的系统：当变更发生时，如增加桥梁负重或飞机速度，整个系统可能就要重头重新设计。不幸的是，软件也常常使用一个静态架构进行设计：每当一个非预期的变更被引入到运营中时，很可能所有事情都停了下来，使用包含新增功能的系统替代现有系统。因为业务运营在一个不断变化的环境中，而且比以往更依赖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架构和层次、有状态、动态、分布式业务的现实世界之间的脱节。我们还讨论了传统工程方法为什么不能支撑能支持动态业务的自适应系统的开发。我们展示这两个问题的可能解决方案可以用一种新的模型驱动架构方法来找到。
本文的第二部分将描述动态业务应用的可能架构，并给出一个案例研究，介绍我们概念的实际实现。
参考文献
[1] Yourdon Systems Method —— Model Driven Systems Development —— Yourdon Press, 1993
[2] Eric D. Beinhocker —— “The Origin of Wealth”, HBS Press Book,2006 —— 在他的新书“The Origin of Wealth”中，麦肯锡公司高级顾问Eric D. Beinhocker声称，将经济视为一种静态、平衡的系统的传统观点正在经受一场彻底的反思，包括为数众多的原则。新的中心是：“复杂经济学”，其中经济被视为一种高度动态的、不断演变、几乎无法预测的系统。这个摘录涉及在未来未知时公司如何来制定战略。
网友评论