对于任何成功的模型驱动开发(MDD)计划,可见性和可追溯性是两个必不可少的部分,特别是在使用多种建模工具支持不同角色和模型类型的环境中。支持这些必要因素的方法很大程度上是基于一个输出/输入概念或一个全局存储库的概念。然而这两种方法在动态分布式环境中都有严重的管理问题。
早期的互联网和Web创始者面临一个类似的挑战,他们选择一个完全不同的方法实现可见性和可追溯性。今天的Web是基于这样一种概念,即通过轻量级、标准化的HTTP引用链接各类网页,且发现这类引用时常被破坏,以至于为避免过度复制或存储库僵化需要付出很大代价。
本文中,我们将介绍一种跨越不同建模域、工具和存储库的高效互联建模工件链接方法,以提供贯穿扩展MDD环境的一致可见性和可追溯性。
简介
随着诸如面向服务架构(SOA)、业务流程管理(BPM)、信息管理(IM)和企业架构(EA)之类模型驱动技术和规则的普及,许多企业自身面临着跨领域和角色管理数量不断增长的模型工件的挑战。模型工件之间关系密切、相互依赖,甚至本质相同的系统也有不同的表示。模型工件引用经常被通过复制或转变模型本身而解决,使其用于不同的工具或领域。这种方法可能造成大量的修改工作,并使跨越环境和工具的持久同步性需求制度化。更糟糕的是,复制模糊了所有权界线,没有考虑到不同类型模型工件的生命周期不同。
正如前面提到的,对于任何成功的MDD计划,特别是在使用多种建模工具支持不同角色和模型类型的环境中,可见性和可追溯性是两个至关重要的因素。创建可见性和可追溯性的一种方法是让所有的建模工具使用一个全局存储库。然而,很多情况下,因为相关工具或基础设施组合,或者只是因为不同角色需要不同用户经验,最终导致不同的模型管理需求,这都是不切实际的。
停止复制
跨建模域协作时,以往典型的做法是通过复制交换工件,很多情况下,甚至使用转换。使用这种方法有几个问题,包括:
- 点到点的专有整合。
- 转换造成信息丢失或概念不匹配。
- 跨领域界限无可见性。
- 由于所有权界线不是很明确,转换管理变得复杂,甚至不可能。
- 不支持工件生命周期管理。
诸如BPMN2.0和SoaML之类的行业标准的出现,组成准规范指南,减少转换和专有整合的需求。目前尚没有标准模式能对可管理性问题起到帮助,要真正解决这些问题,惟一的方法是停止复制工件。问题的根本是,当您复制一个工件时,突然出现同一事物的两个截然不同的副本。克隆一个相关但又截然不同的工件,其差别是微妙而严重的。以下例子有助于澄清区别:
- 复制:在服务建模工具和流程建模工具之间交换服务模型,是为了充分利用服务模型进行流程编排。
- 克隆:取出一个企业架构流程模块和并将其克隆,作为特定解决方案流程模块的一部分。
在第一个案例中,使用复制方法。不管您使用哪个工具改变服务模型,毫无疑问,您应该同步该改变到另一个工具中,因为两个副本事实上是同一个工件。
在第二个案例中,使用克隆方法,尽管克隆是逐步复制原型(或许是它的一个变形),克隆有自己鲜明的特征和独立的生命周期。即使您为某个解决方案修改了该流程模型,多数情况下,不意味着您需要修改企业标准。尽管如此,从克隆到原型保持一个链接,支持可见性、可追溯性和未来协作仍然很重要。
这仅仅是一个例子。它说明了这个事实,当跨越领域界限时,很难有好的理由通过复制进行交换。不管是一个足够提供可见性和可追溯性的简单链接,还是一个有自己独特特征且链接回原型的克隆,都是必需的。
开始链接
是否能通过简单链接处理一个既定状况,或者,是否需要克隆。在这两种情况下,都需要一个标准化中性方式来跨建模域链接工件。此标准化链接是Open Services for Lifecycle Collaboration (OSLC)计划 中解决的挑战之一:
- 链接必须是透明的。
- 链接必须是双向可见的。
- 链接必须是版本敏感的。
- 链接必须是受改变影响较小的。
比起复制,链接提供了一个更加无缝的体验,并提供更好的跨越角色和工具界线的可见性和可追溯性。流程模型能被直接链接到他们编排的服务模型中,相关性对业务分析人员和服务架构师都是可见的。服务可以被链接到它们依赖的信息工件上,且它们对服务架构师和数据架构师都是可见的。企业架构目标可被链接到他们导向和控制的解决方案模型,并且这种关系对企业架构师和任何使用该解决方案模型进行工作的人都是可见的。简而言之,我们需要在任何我们可以使用的工件之间使用透明链接,如图 1 所示。
图 1. 互联网式链接
甚至在真正需要 “复制” 的案例中,比如,散播一个带有EA模板的BPM解决方案,原始工件应以一种可追溯、可链接的方式被克隆,而不是通过复制交换。这提供了如下经验:
- 以人为中心,支持参与者协作,但尊重所有权。
- 透明的,以多对多的工件关系支持跨领域可见性。
- 可管理的,使用工具辅助工件链接管理。
- 协调的,用轻量级协调关注协作而不是尝试繁重的完全同步。
近来,行业已经将注意力放在实现灵活变化上,但是以可管理性为代价的敏捷不是很有用。事实上,现代企业必须面对的挑战是如何通过协作和整体规划实现持续的业务改进,并跨企业交付流程。规划和交付的合并是最强的,确切地说在链接方法中是最强的,因为它允许我们考虑生命周期、领域边界和所有权,甚至提供全部的可见性和协作。图 2 显示了如何链接BPM和EA的例子。
图 2. 通过灵活链接释放BPM和EA协作
规划与交付的结合不仅对IT是重要的,对扩展业务范围也很重要。没有适当的跨企业规划和交付流程的整合,业务发展将会是不透明和不协调的。跨建模域管理架构变更不严格,解决方案就会变得很脆弱。
支持链接方法的技术是快速发展的,已经有很多资产管理存储库支持库中资产间的任意点对点关系,并提供社会化协作的基本元素。下一步,链接需要标准化并跨存储库联合OSLC访问的各种属性。事实上,基本链接同MDD资源控制、工件管理和追踪这些传统元素的合并是未来工作的核心。
结束语
从本质上讲,模型驱动开发需要跨越多种不同建模和工程领域的协作和可见性。每个域都有自己的规范和价值主张,一个模型驱动企业需要确保每个领域同其他领域是相互促进的。在企业级利用此类协作需要建立适当的协作和管理流程。从组织的角度来看,企业需要利用健壮构架规划和敏捷业务优化的强大协作功能。从技术的角度来看,企业需要建立一个平台,通过跨越所有角色和工具,在目标和解决方案之间创建可见性、可追溯性和完整性来实现适当的协作。
经典的用于跨域协作的 “复制变换” 方法在较大的模型驱动企业中伸缩性不是很好。最好的情况是产生一个脆弱且难以维护的模型构架,最坏的是引起错误和不协调工作,这将极大地伤害一个新兴的建模文化。基于健壮的可维护模型构架的跨建模域高效协作,是成功企业实现持续业务性能和服务优化的一个关键分水岭。为此,此类企业需要停止复制,开始链接。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
作者
相关推荐
-
在iBPM和BPM间做选择 不一定非此即彼
大多数系统都有一样的能力,在很多人看来,除了BPM或者iBPM这两个标签以外,实际上它们之间并没有任何区别。
-
事件驱动框架和SOA在空军的应用
空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。
-
用BPM策略对遗留应用现代化
一些人提议把业务流程管理作为应用现代化的手段之一,但也有人对此提出质疑,但采用BPM策略可以成为现代化遗留应用的明智方式。Tom Nolle对此进行了解释。
-
RESTful API设计给开发人员带来怎样的未来?
在模块化应用世界里,最为持久的争论莫过于面向服务架构和表述性状态转移之争了。本文探讨这样的争论带来了什么及其背后的原因。