您的企业架构设计已经得到实现并不意味着您就高枕无忧了。通过本文了解当您的设计正在运行时要监视什么。本文是一个包括七个部分的有关企业架构的“企业架构核心”系列中的第7部分。

　　由于您的企业架构设计已经得到实现，您可能觉得迫切需要抛开剩余的琐碎工作，进行充分的休息以便为下一个挑战做准备。我知道，在完成实现后将设计抛在脑后是很有诱惑力的。毕竟，您已经从事该设计很长时间了，也许此时您已经在某种程度上开始厌烦该设计了。但是，这最终可能成为该过程中的最关键阶段。

　　为什么呢？因为您的设计好坏是由其性能所决定的。也许所有的部分在实现后都已各就其位，但是如果用户感到失望或者设计的某些方面没有按预期工作，您需要了解这些情况以便能够锁定任何问题领域。达到此目的的唯一方法是监视该企业架构的性能。因此，不要太得意了——您仍然还有一些工作要做。您必须测量业务的性能，以确定问题和机会，然后采取纠正操作。

　　技能和能力

　　您的总体设计已将业务远景和战略与信息技术(IT)工具完美地组合在一起，因此应该将企业架构设计的监视阶段的重点放在性能上。例如，信息 ——而不是技术——正在如何推动并服务于业务流程？用户是否达到了他们需要达到的目的？是否存在对流程的改进？在本部分中，我将研究哪些技能和能力会在您努力解决性能问题的过程中提供帮助。

　　保持灵活和适应性

　　我谈到了许多有关灵活性和适应变更的信息，因为对我而言，存在两种架构师可以使用的最关键技能。尽管您公司的其他所有人可能都认为事情应该是完美的，但是生活中没有任何事情是完美的。其中包括您的企业设计。虽然告诉其他人“这就是该设计——不管您喜不喜欢”可能充满了诱惑力，但是灵活的架构师知道，始终可以做出更改来改进任何设计。

　　考虑提高灵活性技能的一种方法是学习一条来自投资界的经验。当投资规划人员向客户谈到保持投资灵活性时，他们的谈话使用了流动性、信用 和机会成本 等术语。如果您将这些相同的概念应用于企业架构，则会在性能问题出现时帮助您以更灵活的方式思考和做出反应。

　　下面以流动性概念为例。在投资术语中，流动性 指的是将投资或资产转换为现金而不损失价值的容易程度。在您的架构中，当性能问题突然出现时，您能做什么来将问题转换为“现金”而不损失太多的价值呢？您是否能够让系统的一部分绕道以消除该性能问题？也许您可以将某个流程转移到另一个应用程序中，而不会在修复问题的时候损失宝贵的数据输入时间。

　　就信用和机会成本而言，信用 指的是即时获得成本合理的贷款的容易程度；机会成本 是在您未将“现金”交付给表现最佳的投资情况下的回报损失。请考虑一下：您是否能够即时使用一种不同的方法来改善性能问题？如此迅速的更改对组织的影响是什么？您所选择的任何方法会产生什么损失？您甚至可能会发现一种管理以前从未出现过的问题的方法。保持灵活的思维，以使您不致错过可能隐藏在幕后的重大投资机会。

　　保持沟通渠道的畅通

　　当您正在监视设计的性能时，不要回到您的办公桌或办公室去独自处理问题。当然，也许您很尴尬，因为如果您在实现之前捕获了某个正在发生的性能问题，该问题是决不会发生的。并且您也许应该感到尴尬！但是独自工作很少能够解决性能问题——您必须获得来自各方面人员的输入，以帮助您考虑该问题的所有 潜在后果，并确定最适当的问题解决途径。

　　举行一次会议；邀请关键业务成员参加会议，并包括其他架构师——甚至是您不怎么喜欢的那些架构师。集体思考过程可以激发找到解决办法的灵感，而个人独自工作则很少会考虑到这些解决办法。如果问题涉及到组织的用户，为什么不同时邀请一些用户参加会议呢？毕竟，在设计的实际使用过程中，有谁比用户更了解什么将会使他们的工作更容易呢？

　　一个提示：在您致力于寻找解决办法时，应该让管理层保持知情。他们将产生大量的抱怨，并且在解决问题的过程中，让他们了解事情的真相会对他们具有极大的帮助。为达到此目的，您可以根据需要向他们发送每日最新快报——创建一个简单的模板，以便只需填写空白即可将自从上次沟通以来发生的活动通知他们。如果让管理层保持知情，您会在他们心目中获得许多得分，因此不要忽略了这个至关重要的一步。

　　杜绝情绪化

　　在您监视性能时，保持理性是非常重要的。不要让您的个人感觉妨碍您判断设计的某些部分是否工作得尽可能好。其他人可能会对某个最终不值得担心的问题变得焦头烂额。通过戴上理性的帽子，您可以判断某个性能问题是否真正是个顾虑。为了保持理性思维，可通过输出、输入和流程系统地回溯预期的大致结果，以确定何处出现偏差是可接受的。

　　当然，诀窍在于确定设计中的哪些项最为关键。如果您发现设计的某个很小的方面工作得不是很好——例如，用户界面(UI)的某个部分有点令人混淆——应考虑此问题对用户的总体工作效率意味着什么。该混淆是否会导致客户服务的延迟？如果是，该延迟有多长时间？一秒？30秒？数分钟？然后，将延迟时间乘以涉及到的客户和服务代表的数量：该问题现在的情况如何？

　　如果分析表明该延迟将随时间推移而导致更大的问题，那么您就遇到了一个真正的性能问题。如果不是——也许该延迟每个星期才影响一个客户——那么该问题就没有什么大不了的。要点在于，在监视性能时要保持超然和理性。

　　工具和技术

　　在一个相关系列中的前一篇文章“企业架构核心，第6部分: 可管理性”中，我讨论了可在应用程序架构中使用的各种性能管理工具和技术。该文是尽力克服企业架构性能管理问题的所有人的理想参考资料。但是当您从企业角度处理性能管理时，以下工具和技术可能也是非常有帮助的。

　　管理风险和资产

　　首先，即使是在出现性能问题的时候，您的业务也必须保持有效地运行。例如，您不能关闭客户服务中心以修复某个问题：您必须找到一种在后台修复问题的同时保持客户服务中心平稳运行的方法。但是有时，找到具体的性能问题是非常困难的。也许您所知道的不过就是系统运行得太慢而无法有效地为客户提供服务。

　　可帮助找出性能瓶颈的工具包括IBM Rational Performance Tester和IBM Tivoli Composite Application Manager for WebSphere（请参见参考资料）。您可以结合使用或单独使用这些工具来帮助构建性能测试，创建场景，以及确定瓶颈来源。通过使用此类工具，您可以在确定问题来源的同时有效地管理业务风险和资产。

　　考虑所有信息

　　为了避免纠缠于单个性能问题，应该实时地监视整个业务流程，以便能够维持所需的连续性能。一个能够帮助您达到此目的的工具是IBM WebSphere Business Monitor（请参见参考资料）。该工具提供了业务流程状态的可视化显示，并带有发送给关键用户的警报和通知，此可视化显示可以促进业务流程的不断改进。

　　该工具的美妙之处在于，它还与IBM WebSphere Business Modeler Advanced集成，以提供业务建模、模拟和富有洞察力的分析。这两个工具组合起来可帮助您确定和考虑手边问题的所有相关信息，以便您能修复问题并继续处理其他项目。

　　维护整体视图

　　有效的业务流程管理（business process management，BPM）是监视您的设计中的性能的关键。如果您维护有整个企业的整体视图，则更有可能在故障变成严重的性能问题之前找出故障。为了帮助您保持有条理并了解、定义、执行和优化为公司产生价值的核心业务流程，请考虑一下由面向服务的体系结构（Service-Oriented Architecture，SOA）所支持的BPM（有关更多信息，请参见参考资料）。

　　立即使用此方法来检查您的整个组织——在性能问题出现之前。从长远来看，此方法还可以为您节省大量的时间并减少实现难题。不可否认，虽然在您已经处于性能管理问题之中的情况下，此方法可能不会有帮助，但是最好查看一下该主题以确定它是否可以在下一次帮助您。

　　里程碑

　　当您在处理企业设计中的性能问题时，通常存在几个务必要记住的里程碑。

　　了解Sarbanes-Oxley报告

　　在美国，有一部列出公司财务报告要求的联邦法律可能影响您对设计中的性能问题所采取的行动——或不能采取的行动。这部称为Sarbanes-Oxley(SOX)法案的法律控制着影响财务报告的各个业务方面，包括自动化的流程。因此，如果您是在与美国公司合作或为美国公司工作，则必须清楚SOX要求。在某些情况下，可能需要关于性能问题的特定报告。

　　要了解有关SOX及其可能如何影响您的更多信息，或者要创建您必须清楚的里程碑，请参见参考资料部分。IBM Rational Method Composer和IBM Rational Portfolio Manager可以帮助您遵守法律法规。

　　客观地看待ROI

　　让我们面对现实吧：大多数项目都很少工作得如我们希望——或计划的那样好。而且，当您尝试管理某个性能问题时，您将需要提供有关要求您实现的投资回报（Return on Investment，ROI）的信息。当您与管理层讨论某个建议的修复的ROI时，务必记住以下几点。

　　IBM Rational Services部门的副总裁Walker Royce曾经说过，ROI估计不是科学；它们是用于建立指导性合作(guiding coalition)的尽责调查活动(due diligence exercises)。此外，ROI估计旨在用于获得管理层对有关组织变更的某些方面的认可。

　　在逐渐地解决性能问题的过程中，当您提出解决问题的更改建议时，注意不要使用“未调整的精度”来计算ROI。根据Royce的解释，未调整的精度 是指有点过于松散地取平均数。他举的例子在于，取10个问卷调查回答的平均数来获得1至5的评价结果不是对客户满意度的精确描述。尽管几乎所有ROI数据都是主观的，还是务必要尽可能保持客观地陈述主观或推测性的估计。

　　了解您的端到端响应时间

　　在本文前面的内容中，我提到了确定问题大小的概念。因而，将出现的里程碑之一就是端到端（end-to-end，E2E）响应时间。E2E是用户按某个键与收到响应之间所经历的时间。在性能评估过程中的某个点，您必须测量此时间。

　　因而，您真正的里程碑是事先了解该E2E计时应该是多少，以便能够迅速确定该时间是否受到危害。如果在实现之前没有对该时间的预期，您将会某个地方出错时手忙脚乱地寻找答案。E2E响应时间是主管和管理层在尝试了解手边的问题时将会问您的首要问题之一。因此，帮自己一个忙并牢牢记住E2E响应时间，以便您能迅速确定可能影响该时间的任何性能问题。取决于您的特定环境，有各种各样的IBM工具可以帮助您迅速查明响应问题。

　　总结

　　正如我在本文开头提到过的，您需要测量业务的性能以确定问题和机会，然后采取纠正操作。您的企业设计的优劣是由其性能决定的，并且真正卓越的企业架构师知道，在某个实现能够顺利和有效地运行之前，艰苦的工作尚未结束。

　　关于作者

　　S. E. Slack是一位自由撰稿人，具有超过17年的商业写作经验。她同时还是IBM、联想国际和State Farm Insurance Companies的业务转换沟通咨询师。她是Windows Vista: Home Entertainment with Windows Media Center and Xbox 360一书以及其他许多书籍的作者。您可以通过sally@sslack.com与S.E. Slack联系。