迄今为止，针对有关监控IT交易的技术，人们都将目光聚集到了网络层。这种做法虽然对网络的持续运转来说很有利，但是对于实现商务智能来说毫无用处。接踵而来的是，今天的每一个企业都处于这样一种状态：对流经它们IT架构的事件是如何一秒秒或一天天地影响它们的高层业务交易和战略实施感到一片茫然。当他们IT层上的事件（不只是简单的事件，通常还包括许多事件共同出现的模式）对于一次业务前景来说意义重大时，管理者们无法实时地分析它们。我把这种情况称为IT盲区。它是一个实时问题。我们不能把这些事件先存贮进数据库，以后再拿来研究——因为这样做解决不了燃眉之急。

IT盲区不仅使我们不能有效地实时监控和管理我们的业务流程，而且它还阻碍了我们去实现未来电子商务这样的宏伟前景。在充分利用新技术诸如产生大量新类型的IT事件的RFID技术时，IT盲区很快就会成为我们最大的绊脚石。

在一个实时企业中，IT投资的最重要的一致性目标必须是改善业务流程技术，诸如对流程进行迅速改变的灵活性、对流程进展的跟踪能力。任何技术投资，只要被用于预测IT层事件会如何促进业务流程的成功执行，这些投资就要与业务目标保持一致。并且这种投资是克服IT盲区的一个步骤。

在过去的三到四年里，人们开始体会到克服IT盲区所面临的挑战。而持这种想法的人把IT盲区视为一个财源滚滚的商业机会。Gartner公司列出了一百多个当代卓越的中间件销售厂商，这些中间件要么是被用来跟踪业务流程进展，要么是预测高级政策的违反性，或者是分析关于执行业务交易的IT资源过剩所造成的影响。这些是您能通过一些IT透视所能或要求做的事情。当几年前人们刚开始注意到IT透视的冰山一角时，Gartner公司的Roy Schulte已成为第一个揭示其本质的人，并且他把这小部分IT透视命名为“BAM”，即业务活动监控。

IT透视是指预测一个企业内IT层中的事件模式将如何影响高层商业目标、政策和流程的能力。

第一步：描述事件模式

IT透视的第一步是能够洞悉云中正在发生什么。怎么做呢？让我们回顾一下在线银行的一些事件模式，并揣度它们为何如此重要。

图1展示了经典的银行事件模式，即窃贼们在窃取口令进入帐户后所做的事情。我们可以看到在帐户上的事件活动模式，在一段很短的时间里，发生了先是登陆，紧接着是密码修改，然后是一个新的自动支付命令。图2中这种模式的两个例子发生在不同的背景下。第一个例子中，三件事是直接一个接一个发生的。而在第二个例子中，三件事两两之间会有一次帐户余额查询。事实上，在三件事之间还可能会出现其它的一些操作，但是只要这三个关键事件在很短的时间里都出现了，我们就应该把它们标记为可疑事件。例如，一个窃贼可能会先登陆修改密码后退出。然后过一会又会登陆执行一个新的自动支付命令。为何中间间隔的时间如此之短？因为窃贼们想要在别人注意到帐户被盗之前快点执行转移支付。

图1展示了针对可疑的银行活动监控器应该能做点什么。它必须能够检测一系列不同背景的连环（此例中为三个）关键事件，如果它们之间的时间间隔很短，那么创建一个警报事件。监控器监控到可疑的帐户活动时，我们要求其要检测出不同背景和不同时机下的一些与可疑事件相类似的事件模式。在一些扑朔迷离的情况里，可疑的活动可能会同时涉及到好几个帐户，因此这时的事件模式不会是在一个时间间隔下的简单事件序列，而是长期在几个帐户之间所进行的并发且相互关联的一系列事件。然而，针对检测网上银行盗窃案例和核实转帐来说，在我们图上所展示的这种监控简单系列事件模式的能力已经算是一个不错的开始了。

针对该银行案例，我想指出一点，一个事件模式通常包括：

• 几个事件，它们中的一些可能共享公用的数据元素。
• 这些事件可能需要以一个特定的顺序出现，可能允许不属于这种模式的事件在模式事件两两之间出现。
• 此模式中的一些事件可能独立发生，也可能以任意的顺序发生，而模式的另一些事件可能要先有前奏才会发生。
• 可能在一定的时间间隔后，一些事件一定会发生，并且这些事件会对数据做一些限制。

事件的模式可能会变得十分复杂。而且要完整地表示它们需要很详尽地描述。因此IT透视的第一步是要求制定一条精确的事件模式描述。

软件科学家们在用程序设计语言来做与此相似的事情已有四十年了。计算机科学家们也几乎一直在开辟事件和时间选择逻辑的理论。因此这一步并不难，不需要一些非常新的科学。只要去做就好了。

第二步：检测事件模式

电子商务正卯足了劲加速前进。在过去，企业之间要花上一个星期或更多时间来进行交易，而现在只要数个小时就可以了。因此企业的管理也要与时俱进，而且需要靠这些工具来实现。

在全球事件云中，事件模式匹配是模式检测所需的最基本的技术。这项技术至今仍在襁褓之中。业务活动监控的趋势是：制定模式检测引擎来监控涉及到几个事件（包括顺序事件、间隔事件以及并发事件）的复杂模式。对一些应用软件来说，在调度过程（所谓的执行的可量测性）中，模式匹配执行的速度变得至关重要。可量测性包含了三个维度，待检测模式的数量，事件进入事件云所伴随的速度，以及时间。

事件模式检测引擎的一个好的基准目标可能会是每秒以逐千个模式的速度进行测试：即监控一千个不同事件模式的能力，这些模式的复杂性与我们的银行案例相似，即一个事件云以每秒一千个的速度在产生新事件。

这是一个极富挑战性的基准，但是这样的技术就要成功了。同时，许多地区的电子商务都可能通过性能略逊一畴的事件模式检测引擎来实现IT透视。

第三步：事件模式提取

IT透视的这一步是向前——或向上的一次最大飞越！

就执行事件处理的新人来说，事件模式可能会亮出足够的复杂度来挑衅新人们的理解能力。而他们为何应该需要真正去了解这些模式——因为他们在管理业务时感到太吃力了！要实现IT透视，就要将IT层里的事件模式所包含的信息传达给企业中各司其职的人员。传达前要将事件模式的数据聚集并进行提取。

例如，图2展示了一个交易案例，其涉及到四个企业，一个买方，一个卖方，一个拍卖机构以及一个结算机构。本质上我们是在分析一个电子商场或电子供应链中的事件活动。这些事件包括买方向拍卖机构提出产品申请。卖方单独进入拍卖机构的目录。这两个事件使拍卖机构能告知买方可能符合其要求的产品。因此，买方可以向卖方发送一个接受信息并向拍卖机构询价。然后拍卖机构向卖方和结算机构发送开始结算事件，这样就进入了交易的结算阶段，这之后，由结算机构充当中间人来完成买方和卖方之间产品和款项的交换。这个模式案例展示了交易层事件之间的因果和时间关系。

您真的不想看到象这样的事件模式，是吗？

四个企业中任何一个企业的业务管理人员都不想在一次谈判中就完成所有的交流事件。实际上若牵涉到几个买方和卖方，详情可能会比这个案例还要复杂得多。针对这种交易，管理者们想各自提取与他们在公司的职责相关的事件模式。就拿CFO来说吧，他可能只想知道产品的资料，价钱，支付额。而且他可能想在交易成功发生时，将每一次交易的数据都汇入到他的总分析表中。另一方面，就这一相同事件模式来说一个IT管理者可能要的资料与上面截然不同，他想要的是对此交易提供的IT支持方面的时间资料，尤其是出现了如果另一方对缓慢的回复有所不满的情况。

提取的任务是按各管理者所需将此交易层的相关事件分别传送给他们。我们通过创建新的事件（根据交易层模式计算而来，并且它们涵盖了提取资料）来实现这个任务。并且我们把它们视作较高层事件。图4展示了提取的概念。

那些几近完成但似乎慢下来或抛锚的交易的提取也同样重要。例如，一次交易进行到结算阶段但是花的时间远远超过正常的完成时间。原因何在？是不是有些交易事件显示出现了一个竞争者以一个较好的价钱进入交易？通过向买方提供折扣是否能完成结算？这是一个依赖于事件检测模式的实时交易。

事件模式集聚和提取其功能是为了向您大致介绍您所需要的IT层事件云。为使同一事件模式案例的不同提取资料能在同一时间传达给不同的人，我们传送事件模式提取请求的技术必须要很灵活。

目前事件模式集聚和提取的技术尚在雏形阶段。人们还要求它有处理复杂事件的能力，这样它在功能上真的会远远超越BAM。我相信这样的初始产品可能会在2004年的秋天问世。

总而言之，IT透视的三个步骤是：

1．详细描述事件模式。
2．可升级执行型事件模式匹配。
3．事件模式集聚和提取。

我们即将要实现IT透视，并且实现的速度快得令人匪夷所思。2003年，我们还在讨论，要制定出商业工具来实现基于事件处理的IT透视，这到底需要花多少时间，我们还以为整个行业起码要过个十年才能走完这三步。现在，到了2004年，看来这三步五年内就能大功告成了。光阴荏苒，不久的一天，我们都能买到IT透视产品，并用它们来深入了解我们当代所有的企业都在做何忙碌。