级别: 初级 Barry Snyder, 方法论规程经理, Noblestar
2007 年 4 月 16 日 本文来自于 Rational Edge:一个企业过程框架能为一个 IT 组织对关键业务运作进行显式的监控。通过本文看看如何采用 IBM Rational Method Composer 创建过程框架,并在组织范围内管理复杂性。
1960 年的软件工程用"软件危机" 来定义不断增长的复杂性、期望和软件工程的变更。超预算、超时的,不能够满足需求,难于维护的低质量产品的软件项目清楚地反映了这一危机。
1
沿着相同的线路,今天的 IT 产业正经历着相似的过程复杂性、期望和不断变化环境的挑战。IT 流程的不同与 IT 企业的复杂性阻碍了 IT 服务和产品的最优化。
IT 企业过程框架 (IT-EPF) 是一种协调过程的不同并管理相关复杂性的机制。它使用了五种架构视图:合作、过程依赖、治理、企业运作和过程追踪。这样就实现了关键过程失败点的透明性与可视性。
以下是由 IT-EPF 管理的常见过程失败点的例子:
-
具有冗余与重叠功能的过程集合实现 IT 企业的自治
-
过程间不同结构与成熟度的错误搭配
-
企业合作与行为转变的失败,例如:
-
软件开发周期与基础架构业务实践的同步
-
将的企业架构(Enterprise Architecture,EA ) 技术治理的融合到所采纳技术的所有方面(例如,软件开发工作与基础架构环境管理运作)
-
在项目组合管理中将基础设施或者软件项目的变更请求作为一个需求条目通过一个新的项目来批准。
-
机械的、官僚的治理造成了过程的无效性。
本文提供了 IT-EPF 的概述和策略大纲,指出了如何协调过程与治理的复杂性。之后将讨论如何使用 IBM Rational Method Composer (RMC) 实现这些特征。
IT 企业的过程现状
今天的 IT 环境的特点是 IT 领导者企图重新构建适合的运作方式。他们希望过程能够作为一种解决方案实现这一目标,但是他们将面对以下约束和限制
1
:
- 过程一般仅能表示所有 IT 运作的一部分。例如,IBM 的 Rational Unified Process (RUP) 关注于软件生存周期,而 IT Infrastructure Library ( ITIL ) 面向基础设施。
- 过程缺乏协调、对于策略的可追踪性,并且常常相互矛盾。例如, RUP 和 ITIL 都定义了配置与管理改变,却是以不同的角色、工作产品和任务实现的。
- 很多过程是庞大的,信息是极为复杂的,一知半解的人很难理解。例如,经典的 RUP 超过了 3000 篇网页, ITIL 由八本出版物组成,覆盖了十多种规程。
- 治理的主要工作和基于治理的过程是直觉的,点对点的,或是非现实存在的。
3
主要的原因是诸如 RUP 和 ITIL 的 IT 行业过程不能够以某种成熟的方式促进治理的集成。例如,RUP 并没有一种遵循治理集成的机制。
4
相似的是,ITIL 也是同样一种状态,它也没有任何一种可控过程元素促进治理的集成。
5
这些约束与限制阻碍了使得企业变得更加灵活的过程的应用。但如果克服了这一障碍,就会获得很高的效率与经济收益。效率来源于针对复杂性的协调与治理。去除竖井结构、有效治理不匹配、协调依赖关系和可持续的治理。
经济收益来源于在企业级的减少低效,管理治理集成框架的能力。例如,减少冗余或过程的不匹配能够降低成本。有效的治理能够增加经济收益,如下所示:
-
来自于有效治理过程的更高的 ROI: 调查显示 "81% 的 CEO 和 CIO 实现了更高的 ROI"
6
,因为 IT 企业执行了有效的基于治理的过程。
-
成熟的 IT 治理可以带来更好的收益:应用成熟 IT 治理的企业会比一般的企业获得多于25% 的收益。公司量身定制治理过程,根据性能和职责的监控来调整 IT 决策。
7
-
应用改进的治理增加市场价值:"一般来说,当从糟糕的企业治理转向较好的时,企业会期望增加 10% 至 12% 市场价值。 "
8
这些仅仅是 IT-EPF 能够带给一家企业的一部分功效和经济利益: 首先是质量最优性和 IT 运作的连贯性;其次是降低成本、提高利润以及增加市场价值。
什么是 IT 企业过程框架?
简单的说, IT-EPF 是一种抽象企业过程及其元素的机制。图 1 可视化的展现了一个 IT-EPF 关键元素的例子。这一框架包括了简单 IT 企业过程的过程定义(最外层),企业联合与治理(中间层),过程交集和依赖关系(连线),和同步元素的基础过程架构(最大的圆圈)。
图 1: 可视化的简单企业过程集合的企业过程框架表示
改进的五种视图
IT-EPF 将过程和相关元素结合入视图。视图抽象并模块化的展现了重要业务。这种与重要过程元素的退耦相关联的可视性实现了 IT 复杂性的协调与管理。这样就实现了连贯性、协作性和同步的业务。
对于这种观点的支持是一种基础性的联合和治理框架。使用框架的目的就是为了提供可持续的治理、平衡治理以改进 IT 花费,并且促进改进的企业联合。框架依靠可控联合和无缝整合的企业过程的治理过程元素实现了这些目标。
总的来说,五类 IT 企业视图
9
是:
-
策略过程联合。抓住企业策略中同步过程的内部和外部联合。
-
过程依赖。 在企业过程和管理职责、连贯性、协作性上映射过程依赖。
-
治理基础设施。IT 企业中的标准化调整机制和控制点;简化针对委托企业过程的透明治理的集成与实现。
-
可控过程集。抓住针对委托企业的完整的 IT 企业过程集合。由共享的过程基础设施统一起来,离散过程被单个的企业拥有并利用,但是这些过程能够通过这个视图进行跨越企业的协调和管理。
-
过程追踪链。在每天的任务中实现过程可控策略以映射策略、治理和标准。可追踪性实现了针对策略、联合的过程元素的鉴别,同时促进了过程改变的管理。
针对视图点、抽象和可控性的机制
IT-EPF 是一种协调与管理复杂度的方法,因为它提供了:
- 企业级的可控过程
- 企业过程元素的抽象
- IT 企业过程基础设施的总体观点
企业级的可控过程
IT-EPF 定义了目标、治理和联合策略作为可控过程元素。这样就实现了委托企业的扩展企业过程元素以满足特定需求,并将其整合。
例如,IT 企业定义了变更管理过程作为企业标准以控制技术变革。它将被定义为标准角色、任务、工作产品和一般性工作流的整合。软件工程企业将会使用企业变更过程以满足软件变更管理小粒度的需求。另一方面,基础设施团体将扩展相同的 IT 企业变化管理过程以适应 ITIL 的转型管理定义;关注于针对产品变更的控制而不是粒度细节。
每家企业都会以连贯的、无缝的方式应用可控过程。 IT-EPF 在企业级引入可控过程,并针对每家企业应用特定的实现方法。
标准企业过程元素的抽象
抽象就是过滤细节减少复杂度。 IT-EPF 抽象 IT 企业中一般性的和重要的过程元素,例如治理。抽象提供了对于普遍元素的可视化,并确保它们没有丢失在每天的工作中或由单个企业所包含的内容。而且, 抽象普遍元素能够由单个企业所扩展,用以将治理和企业标准整合入它们的过程,而不必阻碍企业需求。
例如, IT 通过使用已有的和新的技术实现了 EA 治理过程。这一过程定义了治理和标准。一家软件开发企业能够扩展 EA 治理规程以满足 Java 或 .NET 的内部软件开发标准。同时,基础设施团体能够遵循着产品硬件和操作系统扩展相同的 EA 治理规程。
对于每家企业,他们关于 EA 治理的标准的混合是透明的,但是他们的共性可追溯到 EA 中最初的源头。 这样实现了每家企业通过 EA 治理构建自身的需求的目的,同时也为对于企业技术的管理转型打下基础。
总体观点
企业中的改变如果没有各种重叠的,交叉的和结构化过程的协调将会是十分困难的。混合就是要任何企业流程的实现都需要某种水平的改变;尤其是很大的改变。而且, IT-EPF 通过优化 IT 企业所必需的改变促进了协调性。它指明了哪种过程可以实现 IT 企业目标,哪种过程与业务相关,哪里的过程协调了整合点,哪里的过程交叠在一起是冗余的,哪里是不匹配的。
例如,配置管理同时由软件开发和基础设施组完成,以满足他们的需求和目标。但是,与改变管理过程类似,配置管理也与其他的行为交叉在一起,尤其是当软件由一个软件开发团队转到另一个的时候。IT-EPF 实现了配置管理过程交叉,相关版本管理的交叉,识别映射配置管理的不同。这样就促进了协作和管理企业转型。
商业驱动力的影响
为了成功的实现 IT-EPF 的优势, 理解 IT 企业中的商业驱动的影响是十分重要的。作为一种实现机制, IT-EPF 对于委托 IT 企业过程来说是一种常见的业务间合作的方式。
图 2:IT 企业中的商业驱动力
图 2,IT 企业中的业务驱动力表示了业务影响 IT 企业的策略观点,从而产生了 IT-EPF。 这幅图表示了需要完全实现 IT-EPF 收益的业务驱动的例子。
IT 企业过程中的业务驱动的影响是十分复杂的,有时甚至是自相矛盾的。例如,针对业务灵活度的驱动将技术与技术解决方案结合起来,能够迅速占领市场。另一方面,对于质量与可靠技术服务的驱动使得基础设施过程更加有效,实现稳定性,可预测性,和有效性。这样阻碍了新技术的采纳和配置;而且,这种方法很自然的创造出了基础设施和软件团队的不同之处。最终的结果是过程和文化矛盾的复杂交集。
总会有重叠的业务驱动,但是某些驱动对于特定公司会有很大作用。例如基础设施公司会将稳定和可靠的产品环境放在首位。这样就不会过于关注类似于灵活技术的采纳和保持竞争性配置的业务驱动了。
在这种环境中,一段时间后过程要么开始变得协调了,要么变得更加松散。这种情况强调了企业过程元素或冗余和重叠过程间的冲突。 IT-EPF 实现了 IT 企业上升阶段时针对各类改变所做的协调,它是通过调整过程及管理固有的复杂度实现的。
将这一状况组合起来是近来实现企业治理比较疯狂的业务驱动;尤其是外部实体强行加入可调整标准的要求。 "风险评估调查报告说,违规的行政监管排行第二——在恐怖主义之上,仅仅落后于竞争。" 如果没有治理驱动过程的协调和管理,根据它们的官僚和迟缓的特性,它们将变为阻碍成功的因素之一。
企业过程框架和 RMC
为了实现过程的协调,需要应用业界的最佳实践,同时包括过程工程和企业变更管理。 对于大多数 IT 企业来说,固定且实效的方案不足以满足全部操作和过程协调所需交互的深度和复杂度。因此有必要使用工具管理无数的细节并将其抽象成更易使用的形式。
IBM Rational Method Composer (RMC) 对 IT-EPF 的支持能够提供协调管理 IT 企业过程复杂度的解决方案。RMC 除了是一种过程定义与发布的工具之外,还可以:
- 促进企业与文化复杂度的社会工程。
- 提供了实现策略可追踪性的结构。
- 统一了策略、治理和联合的标准。
- 通过工作流和依赖关系图表获取企业复杂度。
- 实现了标准化的工作产品的一致性应用。
使用 RMC 定义 IT 企业过程框架
RMC提供了根据多种原因定义 IT-EPF的方法。虽然很大部分原因都与工具功能相关 —— 例如发布Web站点内容,实现合作化创作,诸如 IBM Rational Portfolio Manager (RPM) 和 Microsoft Project 的工具集成 —— 很少可能是因为 Unified Method Arch IT ecture (UMA)。 UMA 是过程元模型;UMA 继承自 Object Management Group (OMG) 发布的 Software Process Engineering Meta-model (SPEM) 2.0。
SPEM 2.0
11
将元模型范围扩展到任何过程定义都可使用的工程过程视图; IT-EPF 模型用以将过程抽象放入五种视图中。事实上,SPEM 2.0 的特点完全适合 IT-EPF。除了将全部企业过程调整为产业标准之外,SPEM 2.0 还实现了面向方面的过程设计,封装了重用,动态派生全部过程的改变。
IBM 的 RMC 利用 UMA 作为它的基础架构,这种工具十分适合于按照产业标准格式定义 IT-EPF 的视图。这一特征可从 IBM 的 UMA 定义中发现。这种定义使得 RMC 实现了如下内容:
- 分离关注点:
- 在方法库中封装方法内容、过程和插件的配置。
- 从过程中的方法内容应用分离核心方法内容。
- 推荐方法和指导描述域的分离。
- 从过程图中的符号分离语义元素。
- 重用性和扩展性:
- 允许每个过程从通用方法内容池和过程模式中引用通用方法实现内容重用。
- 在过程定义的多种类型和生存期模型中支持多族系的过程。
- 提供不必直接修改最初内容就可以定制方法内容和过程的途径。
- 针对特定过程可满足特定业务需求的情况,实现了面向方面的解决方案。
- 复杂度管理:
- 针对大型方法与过程存储管理的可选择扩展机制的定义。
- 提供连贯有效管的理并维护所有相关过程的机制。
- 定义了多重和连贯的过程视图,当父过程改变时能够快速更新其子类过程。
- 建立邦定过程元素与过程模式的可变性,以便对于最初过程元素的改变能够派生至所有子类过程组件。
对于分离关注点、重用和复杂度管理的关注引发了在抽象、泛化、模块性和聚合方面基于对象观点的过程设计;每个都利用了 IT-EPF中的固有复杂度的重用和管理。以下部分列出了这种设计带来的 IT-EPF构建的好处。
抽象
抽象的关键之处是可以通过分析细节得出更高级别设计模式的方法,从而降低复杂度。细节是不断扩展的,而高层的设计是不会变的。RMC 通过使用了过程与过程扩展的组合方法库实现了这一功能。 Method Library 是 IT-EPF 重要的组件,因为它实现了类过程的分组。这样就实现了满足 IT 企业需求的过程的识别与联合,同时为每个企业提供了各自定义自己唯一过程的机制。图 3是针对使用IBM的 ITIL Tivoli Unified Process ( IT UP) 的基础设施企业的单个 Method Library 的例子。注意 Method Library 由包含了所有过程或过程扩展定义的插件所组成;抽象的另一层由 RMC 实现。这个例子还证明了对于企业过程的一层重用。在这个特殊例子中,针对公司遵从性 (corp_compliance)、 EA 治理 (corp_ea_goernance) 和公司过程标准 (corp_process_framework_standards) 的插件可以被所有企业使用。这一级别的重用促进了策略、治理和政策的一致性。
图 3: 样例方法库 —— Infrastructure
RMC 实现了 IT 企业详细定义过程和过程扩展集的功能,用以满足协调 IT 企业过程中的特定需求。这种抽象保证了企业级自顶至下的联合。
图 4, 对于 IT 企业内部联合的业务驱动力, 展示了业务驱动力和 IT 企业如何演进成为企业内部联合模型的例子。它展示了联合业务驱动力和 IT 企业各种组织的转型。
图 4: 对于 IT 企业内部联合的业务驱动力
通过使用根据 IT 企业委托组织的业务驱动力抽象结构,定义一个 IT 企业过程库的逻辑视图是可能的,如图 5 所示。 IT 企业过程库是企业重要业务的模块化的抽象模型。如图 6 所示,这些业务都保存在过程方法库内。
图 5: IT 企业对于 IT-EPF 过程结构逻辑模型的内部联合
如图 6所示, IT-EPF 方法库可由 IT-EPF 过程结构的逻辑模型RMC定义与实现。 IT-EPF逻辑模型是构建与组织 RMC Method Libraries的基础。
图 6:通过 IT-EPF RMC 方法库实现 IT-EPF 过程结构的逻辑模型
这种方法开始于一种企业业务驱动的理解。这时创建一个内部联合视图作为逻辑化的建模过程封装的基础。RMC实现了这一逻辑模型,并将其作为 Method Libraries 的集合。
图 7 表示了图 6 所示的最终产品的扩展视图; IT 企业 Method Library 由针对 IT Program & Portfolio, IT Infrastructure, 和 Enterprise Architecture 的 Method Libraries 组成。随着软件开发更加关注于组织结构,于是创建了企业 SDLC Method Library i以标准化实现 RUP、企业资源和软件标准。
有两种 Method Libraries 继承自 Corporate SDLC 。 Corporate SW Development Method Library 用以定制软件开发及其增强版本。同一层的 Corporate SW Services Support Method Library 专门用以维护所有的产品应用。Corporate SDLC Method Library 确保了由 SW Development 和 SW Services Support 组织使用的过程是一致的。 这一 RMC 级别的抽象实现了关键依赖关系的识别。
图 7: 展示了抽象依赖的企业方法库实例
通过RMC的抽象能力捕获了 IT-EPF 关于方法库的更高级的方面,方法库间依赖关系以及每个企业方法库的重要插件的。
泛化
泛化 —— 或者称为继承,提供了一种简化复杂度,制定通过子对象扩展普通过程标准的连贯性的方法。RMC 由各种不同的功能实现,同时可以由元素,所应用的元素,或替代元素扩展角色、任务、工作产品、指导或过程。 这要考虑到企业一直实行的流程标准的实现,还要考虑特定的风格、成熟度和每家企业的细节水平。这能够根据跨企业的一致性来协调过程,并允许在某处进行了关键的企业变更后,能够由特定的实现所继承,从而实现了复杂度的管理。
图 8 展示了一个简单的企业过程框架方法库的实例,其中描述了部分 Method libraries 间的关系。 PMO 部门维护插件使之成为 IT 企业的标准。在本例中,我们使用了过程框架标准、公司遵从性和项目组合管理插件。这种类型的依赖结构建立在一致性标准和治理上,作为执行已定义的规定框架的方法。图中所表示的另一种泛化类型是资产金融管理插件,它在 PMO 和 Infrastructure Method Libraries 间共享了资产管理的治理。
图 8: 展示泛化的企业过程框架方法库实例
模块性
插件的潜在架构化元模型,方法内容包和驱动RMC的过程包形成了过程与模块扩展过程的结构。它实现了分离的所有权归属且关注重要内容。每个方法库的插件可根据 IT 企业进行扩展与重用以实现一致的、无缝的集成。而且,模块化实现了过程成熟度、过程区分、项目 vs.业务过程,和过程所有权的业务分离。 最终,这种模块化设计简化了许多重要元素的复杂性。过程实现和路线图可以仅关注那些基于风险、优先度和价值的插件和/或方法库。
图 9 展示了一个模块性的企业过程库的实例;它描述了一个方法库形式的模块化的过程实例,以业务分离的视角关注企业架构(EA ),系统 & 公文管理 (PMO), 和基础设施。这钟模块化实现了区别对待过程成熟度,过程区分度,和单个过程的所有权。例如, EA 负责管理 EA 治理。 EA Method Library 包含了一种读/写格式的插件。这种插件仅能够读取自身企业的基本结构 和组织 SDLC 方法库。 这样就实现了流行的特定标准,因此所有 EA 治理都可以以相同方式使用。
图 9: 展示模块性的企业过程库实例
模块化的另一好处就是可以在不同企业间交换重要过程概念。这样就使得集成化关注于协作点与整体过程的关键点。本例中,RUP 和 ITIL 的集成由两种 Method Libraries 所共享的插件表示。
聚合
聚合是类似于过程元素的元素组。高级聚合的目标就是实现健壮的、可维护的、可靠的、可重复使用的过程结构;另一方面,低级别的聚合正好相反。RMC的聚合通过之前所述的,使用合理过程工程方法形成的分离关注所实现。 IT-EPF的概念封装了内聚的核心对象;过程结构用以协调各个过程并管理复杂度。这些由最佳的企业评估、投资者制定的需求定义,依据模型制定的过程工程和企业改变管理的产业实践所获得。
图 10 表示了基础设施方法库,它关注于所有与基础设施相关的元素。正如我们所见到的,存在有大量的关系都与由指导行为和基础设施部门操作的元素所组成的方法库有关。如果没有方法库的关注点分离,复杂度是成指数上升的。这是分离关注的主要原因;插件越多,依赖关系的复杂度越大。
图 10: 展示聚合的方法库实例
映射 RMC 和其他 IBM Rational 工具的视图
不可否认的是, RMC 仅是可实现 IT-EPF 众多工具中的一种,但是它是一种重要的工具,因为它实现了可控流程的格式化,当管理 IT 企业内在的各种复杂度时,这种格式是一致的、内聚的,且是可重复利用的。其中重要的特征就是在任务步骤水平上实现了顶端至细节步骤地简洁的职责,定义的工作产品和清晰的过程流。实现了作为企业操作所执行的可控性定义。以一种可控的格式将治理的定义完美的集成进了可控过程中,因此提供了对于过程元素的一致性实现。
任何工具都有其局限性。虽然与其他工具相比可实现完整的 IT-EPF 视图集。表 1 映射了 IT-EPF 视图与最初的 IBM 工具和他们实现 IT-EPF 的用法。
表 1: 实现 IT-EPF 所使用的工具与工作产品的映射
| 工具 | 联合 | 相互依赖关系 | 过程集 | 治理 | 追踪关系 |
|---|
| IBM Rational Method Composer |
- 定义、管理驱动过程内容和工作流的联合。
- IT 企业中扩展、重复使用策略过程元素。
- 发布 IT 企业间通讯的策略过程站点。
|
- 定义、管理企业过程间的交叉过程元素(角色、任务和工作产品)。
- 企业过程站点间的结构化交叉点。
|
- 捕获、定义、管理过程元素和过程工作流。
- 扩展、重复使用 IT 企业的常见过程元素。
- 发布企业过程、交叉内容和治理作为单一源站点。
- 表示过程工作流的工作流图。
|
- 定义、管理治理过程内容。
- 扩展、重复使用驱动内容和工作流的治理。
- 企业过程站点中结构化的 IT 企业治理。
- 发布作为参考源的 IT 企业治理。
- 表示特定治理管理过程工作流的工作流图。
|
- 定义、管理重复使用的实际路线、定义过程元素的扩展,针对策略联合、治理、过程工作产品任务转移的工作流。
- 捕获、定义企业使用的可重复使用的过程元素。
| | IBM Rational Requis IT e Pro |
- 捕获、管理策略投资者的需求。
- 捕获、管理来自企业政策的核心过程实现需求。
- 捕获业务用例规格说明,以定义 IT 企业业务和内部的组织化联合。
|
- 捕获、管理企业投资者需求。
- 捕获任务、角色和工作产品相互依赖关系的需求。
|
- 捕获、定义详细的工作投资者过程。
- 捕获过程用例规格说明,以定义企业工作流。
- 捕获针对企业过程实现的需求。
|
- 捕获针对企业解释和 IT 企业治理实现的需求。
- 捕获业务用例规格说明,以定义管理、监督和 IT 企业治理标准。
| | IBM Rational System Modeler |
- 业务用例模型表示企业联合。
- 业务对象模型以实现业务用例模型和相关时序图。
|
- 面向时序图的业务模型以显示过程元素流与责任、及企业组织治理。
- 逻辑框架模型用以定义方法库、插件,和优先于RMC实现的方法内容包的架构。
- 逻辑模型获取RMC中依赖于实现的过程元素。
|
- 过程用例模型表示企业过程。
- 时序模型捕获重要过程流的时序。
- 逻辑模型用以表示重要过程元素的结构。
|
- 业务模型表示治理的依赖关系及用途。
- 治理工作产品结构化模型用以表示失察与标准管理所必需信息的封装和编辑。
|
- 逻辑追踪模型描述了投资者逻辑定义的需求。
| | Text Ed IT or 或同等实现技术 |
- IT 企业策略。
- IT 企业和组织策略。
- IT 企业策略路线图。
- 战略涉众需要和需求。
- 业务用例用例规格说明。
- 过程标准和重用管理计划。。
|
- 企业和组织级涉众需要和需求。
- 定义了企业衔接点的 Organizational Interface Control 文档。
|
- 企业和组织级涉众需要和需求。
- 过程用例规格。
|
- 企业和组织级涉众需要和需求。
- 定义管理,监控和 IT 企业治理标准的业务用例规格。
|
- 可追踪性管理计划。
|
为什么没有其他的方法论?
有一些封装了 IT-EPF 的商业企业方法论,但是他们对于过程的观点与 IT-EPF 相比处在不同水平上。例如,Zachman 框架定义并构建了一个企业系统架构模型,但是它仅仅涉及了企业过程列表,对于企业系统的业务过程模型,和针对架构于企业系统的技术工作流。这些都不是 IT-EPF 所关注的细节 —— 更不必说实现、协调与管理可控过程了。 Zachman 视图仅仅简单的注意了影响企业架构和系统的流程和工作流,而没有关注实现 IT 对象的全部流程。IT-EPF 关注于协调流程,管理复杂度,实现可控与可描述的状态。
但这并不表示 Zachman 和 IT-EPF 不值得称赞。事实上,撰写本文时,我一直很赞赏他们的特性。IT-EPF 仅仅是封装了组成 IT 企业和业务的策略、运作和资源的一部分。 IT-EPF实现了Zachman框架中的过程的协调性。Zachman 框架具备了过程协调性与 IT-EPF 所实现的管理的观点。 Scott Ambler 的 Enterprise Unified Process 也具有相同的观点。
14
对于过程改进的方式与 IT-EPF 一致。
IT-EPF 的重要性就是它应用 UML 模型驱动过程工程和 IBM Suite工具实现了 IT 企业过程复杂度的协调与管理。它提供了一种统一重叠目标间的协作、策略与治理的一致性应用,以及业务联合的框架和结构。就像使用了一个村庄完成 IT 企业的操作,使用大量方法论和工具定义、优化 IT 企业一样。
总结
今天的 IT 企业环境是高度复杂的,对于客户需求是不断增加的,并且是时刻改变的。IT 企业领导者们意识到企业需要灵活、及时响应,动态的提供服务质量和产品。
随着 IBM 的 Rational Method Composer 和产业实践的发展,这种方案可以促进复杂过程的管理,实现了时效性和权威性。当应用于企业级时,RMC 实现了 IT 企业过程框架(IT-EPF)。
IT-EPF 是一种用以协调管理企业级过程框架的机制。它满足了 IT 企业对于内部与外部联合,无缝治理集成的需求。除此之外, IT-EPF 还是一种企业过程结构,巩固、建立、标准化了 IT 企业过程。这一框架提供了实现 IT 企业工作合作的基础。 因此建立了企业标准,使得所有委托组织得以保持一致性,同时实现了服务与产品的最佳质量和有效性。
当所有企业全部以相同方式执行过程时,能够扩大整体企业的能力。不必浪费任何行动, IT 企业能够完全转注于业务需求。在已定义的过程框架下(例如 IT-EPF)进行治理和调整标准是十分容易的。
使用针对过程工程和企业改变管理的最佳行业实践,在 IBM 的 Rational Method Composer (RMC) 帮助下,能够以一种可理解的形式定义、实现和维护一个过程框架。RMC 对于构建、编译、分发基于分离概念的,分布式的但相互连接的 IT-EPF 来说是十分适合的。对于关注的分离使得过程设计可以基于对象的抽象、泛化、模块化、内聚的工程观点实现。每个都可以管理 IT-EPF 内在的复杂度。
注释
1
Software Crisis, Wikipedia, Wikipedia Foundation Inc.,2006年12月
2Clearing the Clutter: Getting Value From IT Process and Best Practices, Corby James CTO, Noblestar Systems Corporation, 2004年 24月生。
3由 IT Governance Institute 委托所做的一项研究显示,总共695名CEOHE CIO中,有42% 具有一个成熟的 IT 治理流程,而有58% 没有,或只有特定的治理过程。
4RMC 发布了一款针对标准管理的测试插件,它可以用以表示如何使用 RUP 实现标准管理。
5IBM 所发布的 IBM Tivoli Unified Process (ITUP)捕获并定义了可控水平的 ITIL 。
6 "Findings of the IT Governance Global Status Report -- 2006,由 IT Governance Institute 进行委托。
7 " IT Governance: How top performers manage IT decision rights for superior results," Peter Weill 和 Jenny W Ross。Harvard Business School Press。
8 The McKinsey Quarterly。2002 Number
9请参阅本系列的第二部分以学习对于五种视图及其对 IT-EPF 适应性的更详细的细节。
10 "Lock out business risks," Amir Hartman with Craig LeGrande and Tom Goff, Optimize, Issue 50 (December 2005)
11 Software & Systems Process Engineering Meta Model (SPEM 2.0), Internal Version 1.7, Primary Contact: Peter Haumer, Object Management Group, http://www.omg.org/cgi-bin/doc?ad/06-11-03, September 2006.
12 模型驱动开发工程,Erwan Breton and Jean Bézivin, Societe Soft-Maint, Nantes, Computer Software and Applications Conference,2001。COMPSAC 2001。
13 Zachman Framework, The Zachman Institute for Framework Advancement, http://www.zifa.com。
14 Enterprise Unified Process 主页, Scott Ambler, http://www.enterpriseunifiedprocess.com,Ambysoft, 20022006。
参考资料
关于作者  | 
|  | Barry Snyder 领导并协调 Noblestar 在 IT 企业方法论解决方案和服务方面的实践。利用他在软件开发方面的丰富经验,Barry 通过实现 Booch 的方法论开始了他在过程方面的足迹。这使他在超过10年的时间里为众多项目和组织实施了 RUP。 最近他将注意力从软件开发扩展到了利用 RUP 、ITIL 、CMMI 和 PMBOK 等实现 IT 企业过程解决方案。他当前着重于通过最佳实践和 RMC 的支持交付 IT 企业过程和治理。他在 Penn State University 获得了硕士学位。 |
对本文的评价
|