3. 所有角色齐心协力
一个重要挑战是J2EE应用的复杂性在不断增加。尽管它们可以反映三层的应用架构，但是负载均衡，大量依靠关系，来自外部的影响和外部用户等方面的复杂性是公司以前从未碰到过的。在这种环境里，故障或应用的问题几乎从来不是线形的，也就是说在原因和结果之间很少有单一的路径。识别问题不象识别单一的因果关系那么简单。所以，这需要快速遍历复杂的可能性树并在无数可能的原因中找出真正的原因。
线性的： 一个由于没有正确释放锁而执行缓慢的方法会减慢响应时间，因此在一定负载的情况下应用会慢下来。由于这是很好理解的关系，所以原因和结果是清楚的。
非线性的 事务处理的响应时间很慢。碰巧一些方法的执行也变慢了，这就有很多可能的原因。前一天修改了一些代码，影响到了与这个事务有关的一些组件。另外，网络也时而慢下来。机构面对的原因可能是复杂的，可能是多个方法相互关联的问题或网络的问题，诊断将不会是单一线性的。
协调适当的角色克服这种复杂性的能力将是公司获得成功的要害。一旦建立这样的机构，公司必须转换他们的关注点，以确保角色之间能够共同合作。确保合作意味着将工作集中在过程定义，共享工具和共享运营数据等方面。
3.1. 过程
为保证很多不同的角色像一个默契的管弦乐队一样一起工作，他们就必须都遵照相同的过程规范。
重要的是所有的过程都应该从对最终用户影响的视点出发。无论关系到评估影响，识别问题的的重要性，了解测试的负载程度，还是推定适当的响应时间，出发点必须是"用户需要什么？"。
支持J2EE应用的要害过程包括:
故障的识别，报告和转交：这个过程包括对警报进行识别，确认存在的问题，并确定在机构中如何将问题转交下去。最初的警报将转给运营或应用支持。公司不应该简单地给这些小组一个简单的通知单(即，单子上写着"假如A警报发生就通知治理员B")；他们应该让这些小组使用初始的诊断工具以便更深入地识别问题，同时应该开始搜集信息，并将信息转交给能最终解决问题的小组。其他小组使用他们自己的工具（例如网络治理工具），应该时刻保证与应用和运营支持小组共同保证他们数据是同步一致的，同时避免为一个简单的故障安排过多的人手。META Group观察到很多这样的情形，多个人员响应同一个故障，每个人都使用他们自己工具中的数据，独立作战。他们不仅在重复劳动，浪费公司的时间，而且存在着干涉他人工作的风险，因此拖延了故障的时间。这就是为什么以对最终用户的影响为优先并从清楚的问题识别和故障转交为出发点的重要性原因。
分析/解决问题/根本原因: 一旦一个队伍负责处理一个故障，那么这个过程就是对一系列检查点的简单遍历，从而隔离出故障的可能发生位置。当识别出一个简短列表时，就从最可能的项目开始逐一排查。然而，确定可能的原因和影响并不轻易。这就是在解决问题过程中需要工具的地方。故障处理小组从运营小组得到的数据越多，他们越能更快地做出评估，确定如何恢复服务，识别根本原因并做出修正。另外，这些队伍应该有一个装有诊断工具的工具箱以便让他们做更深的分析。最后，应该寻找能够快速隔离可能原因的工具。
这一过程应该考虑到角色之间能够直接的问题转交。这应该包括运营角色或者应用所有者角色将问题转交给J2EE治理员的能力，然后是J2EE治理员转给质量保证小组做更深入的诊断的能力，或者将问题直接转给开发角色的能力。一个小组将问题转给另外一个小组不应该受到惩罚。这种协作必须成为正常的程序。假如用户受到了很大影响，那么这些小组甚至可以同时协调共同参与解决故障。
改变治理/生产接受：现在更新应用系统，改变应用治理，对应用和相关技术的影响性分析（例如假如计划对服务器做变动，需要分析其对应用的影响）等都已成为日常工作。在以前的治理中，这一过程在各个小组之间有很大空白。简单地说，开发角色开发完之后，将工作转给质量保证经理。质量保证小组完成工作之后又转给生产接受角色。然后生产接受小组拿到应用后会发现大量无法接受的地方，就开始和质量保证和开发小组协商进行一些完善。在快速前进的J2EE应用环境中，在各个小组的通力配合下，必须更快地执行整个过程。由于每个小组都需要扮演运营支持的角色，所以不能将应用转给其他组。公司必须规定一个过程，在这过程中必须包含转交技术的小组的参与（例如质量保证小组应参与生产环节），同时当转交技术时，还应包含那些可促进下一步工作效率的信息知识 (例如一些脚本（scripts），众所周知的阈值等级)。
性能调整：这是一个通过调整应用及其组件从而保证所有组件处于最佳运营状态的过程。这一过程从开发人员确保编写的代码正确运行开始，涉及到下面角色：
- 质量保证小组角色：保证可以处理正确的负载程度和提供希望性能的生产配置。
- J2EE治理员角色：保证Web应用处于最佳良好状态
- 应用所有者角色：保证最终用户的体验-体现所有小组的所有改进工作--达到或超出期望。
性能调整是一个主动性步骤，不管有没有故障，公司都应该把性能调整作为经常性工作。经常性的性能调整可以防止应用耗费资源和运行变慢。
3.2. 工具
传统上，购买工具不仅从技术的分类角度考虑也从机构组织的分类角度考虑。这导致在J2EE世界中的每个角色针对他们的具体工作都有自己的工具。虽然我们知道每个人在其领域中对工具都有非凡的需要（例如开发工具与生产监控工具的需求是不同的），但是假如在这些工具能够有联接，那是很有好处的。一个要害的联接是在数据层次上的集成，这使得信息可以在工具间流动，使每个工具比单独使用时更具智能。
在J2EE环境中，我们非凡看到开发小组购买自己的运营工具并不只是为开发人员提供帮助（例如调试工具）。在开发工具和生产工具之间通常是有关联的。这些工具也被用来与质量治理小组共享来加快他们的工作。所以开发和质量保证小组能够共享这些已经采用的工具以及他们的使用知识和与生产小组（例如运营、应用支持，J2EE治理员等）共同使用的脚本等，从而缩短时间，提高这些小组的工作效率。一个附带的好处是大家都使用相同的数据工作。当每个小组都熟悉这些相同的基本工具时（在不同层面有不同用途），这些数据就成为可信的信息来源，每个人都可以使用做决策。这可以减少小组之间的指责，减少不同小组之间的分歧并可以帮助整个协作过程。
工具带来的另一个价值是加快了问题的识别，从而加快了解决问题的过程。这是处理上面提到的非线形故障的一种办法。由于这些故障需要大量的调查分析，所以解决这些故障需要付出巨大的努力。公司应该寻找一些工具，这些工具能够识别所有当前的问题点，可能的原因或影响最大的问题，而不是只是提供简单的线形的，因果关系的功能。 虽然很少能识别出唯一的问题根本原因，但是通常能够提出应该调查的一些因素和应该进行进一步调查的一些可能原因。这将防止公司进行漫长费力的问题识别工作，其典型的做法是对应用基础结构和软件一步一步地进行逻辑检查。
4. 成熟中的机构组织
成功的机构组织将看到他们的运营能力从单纯的反应型状态到适应型状态的成熟过程。这种成熟性对于降低支持成本和减少失败风险是非常重要的。为了保证这种成熟，公司必须了解和测量他们的成熟程度，成熟程度可分为反应型，治理型，主动型和最终的适应型。
4.1. 反应型
反应型阶段是运营一个机构组织最没效率的方式。其特点体现在：几乎没有治理过程，在应用的生命周期中各个角色几乎没有协作，使用一些不相关的工具。
不幸的是这是大部分机构组织的状态。我们给处于反应型环境下的公司的唯一建议就是：现在应该将工作重点集中到应用支持上并且努力成为一个治理型环境。
4.2. 治理型
治理型环境是指当故障发生时，有清楚的确认真正问题，识别原因和负责人，和修正故障的过程。机构不会陷入混乱，相互指责或各自为战中，每个小组都愿意协作。治理型环境的一个特点是在相关的小组之间共享数据，通常使用相同的或可集成的工具。当然治理型环境有程度之分，一些已经是完全治理的，而其他是正在快速成熟的（例如每个小组中使用还没有集成的工具）。
治理型环境将如下一些要害的特点
各个小组与数据相结合，而不只是对数据作出反应: 一个警报引发全部恐慌的阶段正在过去，现在的警报提示着需要做更多的分析，验证和汇集另外的智能，并且开始问题的识别过程。此外，数据被用来决定如何解决问题，而不是被用来指责其他小组。这需要一种"我们的问题"而不是"别人的问题"的文化。
在机构组织中有明晰的技术关系，使得能够快速评估影响：这可使公司进行基本的根本原因分析。当存在简单的因果关系时，根本原因分析有用的。但是由于不能扩展到包含所有可能结果，所以对于复杂多维度问题的作用是有限的。因此公司需要了解复杂的Web技术和业务关系，这可使他们看到问题扩散的多条路径以及在IT机构和业务中的影响。对这些关系了解的越多，会发现他们的关系越多，组织机构也就越强壮。
必须清楚理解下面内容：
- 应用的最终用户：哪些应用或服务影响哪些用户群体？在特定应用或服务上，一些改变或问题对业务有何影响？
- 要素关系(例如服务器，数据库) ：现在有哪些要素，它们是如何联系的？哪个Web应用服务器运行在哪个物理服务器上？Web应用服务器和哪个数据库相联并且数据库运行在哪个物理服务器上?
- 组件关系(例如类，方法) 哪个类被哪个EJB调用?哪个方
