个 “智能” 企业必须拥有运营商业智能(Operational Business IntelligenceOBI)在本文中我们将描述个用于实现智能企业可重用 OBI 框架解释如何捕获并定义时间轴/里程碑模式以便自动化运营业务管理和灵活 OBI 应用构建时间轴/里程碑模式对企业内许多业务流程运营都十分关键这些业务流程包括订单跟踪、产品发布、实现、服务提供等本文定义了个时间轴模式模型及其行为并描述了几种用于将该模型及其逻辑封装为可重用智能组件思路方法这里描述概念将展示通用(可重用)运行时引擎构建块用于处理基于时间轴运营管理解决方案

　　智能企业应该拥有运营商业智能

　　业务驱动原因要求构建适应性强敏捷企业 —— 由于可以理解当前发生事情(拥有环境意识)这种企业能够更快速、更智能地运行能够迅速地感知和响应 机遇和威胁能够在重要项目生命周期中跟踪和追踪 它们环境意识、感知和响应、跟踪和追踪是运营商业智能几个例子运营商业智能使企业能够更快速、更智能地运行它有助于缩小以下两件事情的间时间差距:知道或预测到某件事；某个人、设备或组织单位对这件事采取行动为实现运营商业智能企业希望能够通过从可重用组件轻松组装应用来构建灵活 OBI 应用并针对某个特定问题领域轻松配置 OBI 应用本文将展示个允许企业实现这个目标系统和思路方法

　　Business Activity Monitoring (BAM)、Business Process Management (BPM) 和 Business Event Processing (BEP) 等现有技术联合起来向企业提供 OBI 解决方案但是在这些技术几乎所有部署中都需要针对具体企业进行大量定制许多解决方案试图减少这种定制并且可能提供了些模板用于解决特定业务领域常见问题比如银行业、制造业和证券经纪业由于部署需要高度系统集成因此许多企业都聘请擅长 BAM、BPM 和 BEP 专家来实现解决方案这使得这些解决方案成本非常高昂

　　有种思路方法可以减少构建 OBI 应用所需大量定制即发现许多 OBI 场景都通用底层模式并将这些模式捕获为可重用、可轻松定制组件本文建议架构个重要创新就是发现这样个事实:时间轴/里程碑模式是运营管理个关键底层模式各种业务活动运营管理可以作为个时间轴建模和管理在这个时间轴中只有时间轴上各个里程碑得到满足该时间轴最终目标和最后期限才能得到满足这个时间轴模型行为包括每个里程碑需要动作(包括正常运营动作和里程碑未按期完成而造成异常运营动作)

　　本文将时间轴/里程碑模式及其行为定义为个可重用软件Software组件本文还将展示个用于构建灵活 OBI 应用思路方法和系统它们只需对些可重用组件(比如本文描述时间轴组件对象)进行少量定制

　　有点很重要:本文介绍时间轴模式并不局限于为企业构建 OBI 应用它还可以用于其它领域和应用本文定义时间轴模式组件及其行为可以用于许多其他应用包括跟踪个人时间轴里程碑和生成自动化时间轴异常处理动作

　　时间轴/里程碑模式 —— 个宝贵运营管理工具

　　如果您不遵循计划即使是最好计划也毫无用处制定计划后您需要种思路方法来针对该计划监控进展即检查实际进度日期是否和计划致里程碑是用于监控进展工件个里程碑表示个清晰具体成就您可以检查该里程碑是否在给定日期和时间实现通常多个里程碑被附加到个时间轴上具体日期从而形成个项目计划

　　用于管理运营活动时里程碑通常和特定事件发生和动作规则相关联例如运营团队(Team)通过检查某些特定事件是否发生来验证个里程碑是否完成如果遇到个里程碑在最后期限到达时仍未完成异常情况将生成各种警报并发送到和该里程碑完成相关团队(Team)成员和此里程碑关联其他动作可能在正常运营期间发生而并不只是出现在发生异常时例如个发送提醒通知动作可能被计划用来通知其他成员:某个里程碑最后期限正在迫近该里程碑必须在最后期限的前完成以下举例展示了个使用时间轴和里程碑运营管理场景

　　时间轴/里程碑模式是个在多个业务活动管理场景(例如订单跟踪、实现、服务提供等)中使用关键底层运营管理模式各种业务流程活动运营管理可以作为个带有多个里程碑、关联通知和其他动作规则时间轴建模并管理

　　现有运营管理应用没有明确表示和重用时间轴模式相反这种运营管理所需逻辑通常被硬编码到其他应用逻辑中因而难以实现重用本文通过明确定义个时间轴模式新颖模型来捕获时间轴运营模式这个模型不仅包含时间轴结构还包含它行为这些行为包含处理时间轴活动所固有逻辑和规则本文还将定义些思路方法用于将这个时间轴模型及其逻辑封装为可重用智能组件这些组件的所以智能是它们能意识到自己目标预先定制所需信息在目标没有实现时采取适当动作并持续检查目标是否实现

　　新产品公告举例

　　我们来检查个真实举例 —— New Product Announcement (NPA) 流程借此阐释本文核心理念研发和销售产品公司通常会公告某个新产品将在未来某个日期允许订购我们将该日期称为 Day of Announcement (DOA)在 DOA在线目录中将提供产品和价格信息客户和业务伙伴可以从在线目录采购该产品支持这些公告流程涉及企业中多个组织和应用公告流程通常在产品被发布为 “普遍可用” 几个星期的前启动各个品牌产品开发团队(Team)很早就定义了产品信息初稿这个初稿将随着时间不断修改完善当 DOA 接近时公告筹备(运营)团队(Team)跨多个相关组织管理这个流程确保这个产品信息正确、完整产品和价格已经设置并在相关实现和制造系统中推广并设置 DOA 的前几天很关键活动每小时都受到监控以确保事件和活动的间出现交接(hand-off)

　　图 1 展示了这个时间轴和各种里程碑必须完成这些里程碑才能支持产品公告

　　图 1. 产品公告时间轴



　　查看原图(大图)

　　在这个举例中这个产品结构必须至少在 DOA 前 14 天确定(在研发产品结构企业应用中设置状态标记 “FINAL”)在另个处理产品定价应用中该产品必须至少在 DOA 前 8 天定价这个价格必须至少在 DOA 前 4 天发布(到实现系统)图 1 中其他里程碑和实现系统里程碑相关它们必须在 DOA 的前各自最后期限的前就绪

　　通常通过检查某些事件来验证某个里程碑是否完成如果某个里程碑在最后期限到来的时没有完成各种警报将生成并发送对于每个里程碑有组可以被配置关联动作(图 1 中 A 圆圈)例如如图 1 所示个提醒警报在里程碑日期前 7 天生成另外 3 个延迟警报分别在里程碑最后期限的后第 1、3、和 7 天生成

　　用于为智能企业实现个灵活、可重用 OBI 框架架构

　　本文描述概念用于帮助自动化运营业务管理和灵活 OBI 应用构建借助本文介绍架构概念OBI 应用可以从这里定义可重用组件轻松组装并可以针对个特定问题领域轻松配置

　　本文核心理念就是捕获基于时间轴运营管理问题中重复部分并使其可重用即:

　　捕获时间轴结构(模型)及其里程碑、事件和通知

　　捕获时间轴活动处理固有逻辑和规则

　　将模型和逻辑封装为可重用组件

　　时间轴组件在构建时和运行时被配置为活动实体在这些活动实体中每个里程碑都知道它需要订阅什么外部事件预先执行订阅并捕获和处理进入事件另外每个里程碑知道需要发送什么通知应该在最后期限的前还是的后发送通知

　　时间轴/里程碑模型

　　本文将定义个时间轴/里程碑模型图 2 展示了这个模型举例

　　图 2. 时间轴/里程碑模型举例



　　在这个模型中个时间轴定义为个列表或者个里程碑集合里程碑是具有以下属性对象:

　　Name:里程碑名称例如 Price_Released

　　Deadline:里程碑必须完成最后日期

　　State:里程碑状态完成状态为 “Done”

　　Description:描述这个里程碑表示活动文本

　　Output Events:里程碑发布事件(通知)

　　Timer-based events (timed notications):由 Milestone 设置定时器事件驱动并包含作为主体 Notication 消息

　　Name:基于定时器事件或动作名称

　　Timestamp:这个动作必须发生时间可能和里程碑最后期限相关

　　Notication:由这个里程碑动作发送通知消息

　　通知类型、接收人、主题、主体 SQL、发送源

　　Completion Expression:有关事件内容 XPATH 表达式如果这个表达式值为 true则表示该里程碑项目完成

　　Input Events:事件里程碑监听/订阅:

　　Subscribe expression这个表达式允许里程碑订阅或接收它感兴趣输入事件例如XPATH 表达式 /timeline/NPA/Event/Price 表明我们对所有 NPA Price 事件都感兴趣当某个 Milestone 服务在运行时启动时它将运行其启动代码(如 图 3 所示)

　　这个代码第步是订阅外部事件在这个步骤中这个里程碑将创建条订阅消息(例如它能够使用 WS-Notication 标准来创建订阅消息)将消息发送到个 Publish 和 Subscribe 代理(例如WS-Notication 标准中 Notication Broker)我们将在稍后解释这个架构组件交互时详细介绍这方面内容

　　Metrics/KPI:跟踪这个里程碑指标列表

　　作为这个模型部分我们将个里程碑行为定义为驱动该里程碑逻辑如图 3 中流所示当被封装为可重用服务时这个流表示里程碑运行时逻辑当我们稍后介绍里程碑和各种系统组件运行时交互时这个流(或行为)就更有意义了

　　图 3. 里程碑逻辑流



　　实现时间轴/里程碑模式

　　图 4 展示了实现时间轴/里程碑模式系统上下文这个系统拥有个构建时组件和个运行时组件构建时组件帮助用户定制时间轴/里程碑模型以创建个特定于用户模型用户将这个特定于用户模型部署到运行时组件运行时组件根据指定规则跟踪并管理里程碑

　　在构建时业务用户配置此前描述通用时间轴/里程碑模型以适应其特定问题领域例如个熟悉 New Product Announcement (NPA) 流程业务用户可以指定为了理解和管理流程性能而需要跟踪关键里程碑如前所述时间轴/里程碑模型还包含管理流程需要执行动作和通知构建时工具还允许业务用户定义和指定需要事件并将这些事件映射到里程碑业务用户无需为从企业中各种元素(应用、数据库、文件等)捕获和生成业务事件操心 IT 开发人员仍旧必须编写自定义代码(适配器)和配置来监控企业中各种事件源并转换这些事件原始表示以生成业务用户定义业务事件业务用户还可以为此前介绍里程碑模型中定义每个里程碑定义关键性能指标(KPI)

　　作为构建时活动结果个特定于用户时间轴/里程碑模型被定义并生成例如用户可以指定和生成时间轴/里程碑模型以便管理操作并支持 NPA 流程

　　图 4. 时间轴/里程碑系统构建时和运行时组件



　　这个工具允许业务用户将生成特定于用户时间轴/里程碑模型部署到运行时环境中这个特定于用户应用(例如NPA 应用)作为个具有多个里程碑服务时间轴服务(例如NPA 时间轴)运行每个单独流程例子中每个里程碑都通过时间轴和里程碑服务跟踪生成适当警报、通知和用户报告并发送到有关人员并将里程碑状态及其 KPI 提交到仪表板

　　在下小节中我将介绍这些服务如何和运行时系统其余部分交互在运行时由应用监控数据被转换为业务事件(事件消息)并被时间轴/里程碑应用服务利用有些数据(比如来自事务或其他消息传送系统信息)可能已经使用了事件格式其他数据(尤其是关系数据库或平面文件中数据)必须被映射为事件有许多工具和适配器可以用于实现这种事件映射功能

　　综上所述构建和运行个时间轴/里程碑运营管理应用步骤如下:

　　业务用户定制时间轴/里程碑模型以创建个特定于用户模型并定义该模型需要业务事件

　　IT 开发人员创建和部署监控企业中各种事件源所需 “适配器” 组件并生成所需业务事件

　　业务用户将自定义模型部署到运行时环境中

　　组件交互

　　这个架构定义系统组件交互在 图 4 中展示在这个举例中我们假定这样个事件驱动架构:异步消息(或通知)通过消息或通知代理在系统组件的间交换OASIS Web Services Notication (WS-N) 规范标准通常在事件驱动架构中用作通知标准通知是将场景(situation)有关信息传递给其他服务单向消息场景是被方注意到且和其他各方有关事件我们系统遵循个通知模式它是个涉及使用者注册和事件后续传播交互模式

　　图 5. 时间轴/里程碑系统运行时组件交互图表



　　查看原图(大图)

　　在这个架构个具体实现中本文描述系统可能使用多个通知生成者和多个通知使用者这个系统组件描述如下:

　　发布者:创建通知消息实体发布者通常和外部信息和事件源存在接口并将有关事件打包到条通知消息中发布者通常向消息添加个主题头部根据通知主题模型或分类模式确定该消息类别发布者是通知生成者发布者服务负责将通知发送给适当使用者通知使用者是接收由通知生成者分发通知实体

　　通知代理:不会创建通知消息但代表个或多个发布者管理通知流程个通知代理包含个订阅管理器用于管理 Query、Delete 或 Re 订阅请求订阅是表示通知使用者和通知生成者的间关系实体订阅记录这样个事实:通知使用者对通知生成者能够提供部分或所有通知感兴趣订阅者是请求创建订阅实体它发送条 Subscribe Request Message 到通知代理Subscribe Request Message 识别通知使用者订阅者可以同时充当使用者和订阅者(代表自己订阅)或者代表独立使用者订阅(第 3方订阅)

　　在我们系统中时间轴和里程碑服务充当通知使用者它们对接收某些通知感兴趣它们还充当订阅者它们会订阅感兴趣通知另外它们还是通知生成者它们生成通知消息

　　系统中其他服务大部分是通知使用者并且包括:

　　定时器服务:定时器/调度器服务是订阅定时器类型通知通知使用者它发送个警报或个定时器以便唤醒个已指定时间另外它在唤醒同时发送关联通知消息到系统其他组件

　　电子邮件服务:订阅具有个电子邮件主题通知当该服务接收到条通知消息时它通过电子邮件发送该消息

　　指标/KPI 服务:收集 KPI 指标计数

　　仪表板服务:管理向仪表板发送通知

　　日志服务:能够订阅某种类型通知并记录它们以满足历史查询和调试需求

　　启动和警报通知场景

　　以下步骤对应于 图 5 中交互图表描述个启动场景和个警报通知场景中交互步骤尽管有许多场景但启动和警报场景对于解释系统在运行时工作方式已经足够了

　　时间轴服务订阅其感兴趣所有事件它将末端时间轴里程碑中定义订阅表达式用作订阅表达式中订阅过滤器

　　在某个时间发布者发布时间轴服务已经订阅通知消息发布者将这条消息发送到通知代理

　　通知代理将消息发送到时间轴服务

　　时间轴服务启动它管理所有底层里程碑

　　每个里程碑服务都订阅该里程碑感兴趣事件

　　里程碑发送通知消息以建立它所有警报定时器和通知通知消息内容是定时器启动时将发送实际电子邮件消息它包含个主题表明它是个电子邮件通知

　　通知代理将这些定时器通知消息发送到定时器服务定时器服务将定时器设置为指定时间戳

　　当定时器时间戳到达时定时器服务将警报发送到代理

　　电子邮件服务订阅所有具有 “send email” 主题通知它接收这些通知并通过它电子邮件服务器发送它们



　　结束语

　　本文介绍了时间轴/里程碑模式强调了它在业务流程活动管理和运营中作用我们定义了个详细时间轴/里程碑模型通过举例展示了如何定制这个模型以构建灵活应用来自动化业务流程运营管理本文还介绍了个可重复用于构建和运行基于时间轴应用框架其中包括个可重用通用运行时引擎用于处理基于时间轴运营管理解决方案