当我们把目光转向SOA时，同样的问题出现了——当应用因为一个根本性的故障而被迫终止的时候，应该由谁来负责接听并处理用户的紧急求助？对于很多企业领导者来说，半夜两三点电话响起不是什么好事情——这很可能意味着，企业出了事，而且这些事情很有可能不知道该由谁解决。
随着企业规模的逐渐扩大，企业的复杂性也不断增加，不同部门之间职责、利益、流程的交错，让包括部分高层管理者在内的很多人不清楚，如果企业某个地方出了问题，到底应该追根溯源到哪个部门、哪个人。
这种现象对于已经深入到企业每个角落的IT产品、IT服务也是如此。早上ERP登录不上去了——这到底是网络问题，还是ERP问题，或者是数据库、服务器出错了？IT部门到底应该找哪个供应商解决问题呢？
当我们把目光转向SOA时，同样的问题出现了——当应用因为一个根本性的故障而被迫终止的时候，应该由谁来负责接听并处理用户的紧急求助？
目前SOA已经步入实施的纵深阶段，然而，近来国外的一系列SOA实施案例表明，曾经备受肯定的SOA架构正暴露出其架构的固有缺陷——当基于SOA的服务管理达到一定深度时，目前的SOA管理策略在服务故障的追根溯源方面力有未逮，这一现实对整个SOA架构和管理理念都提出了严峻的挑战。国内SOA用户应该对这一动向保持足够的警惕。当我们把目光转向SOA时，同样的问题出现了——当应用因为一个根本性的故障而被迫终止的时候，应该由谁来负责接听并处理用户的紧急求助？对于很多企业领导者来说，半夜两三点电话响起不是什么好事情——这很可能意味着，企业出了事，而且这些事情很有可能不知道该由谁解决。
随着企业规模的逐渐扩大，企业的复杂性也不断增加，不同部门之间职责、利益、流程的交错，让包括部分高层管理者在内的很多人不清楚，如果企业某个地方出了问题，到底应该追根溯源到哪个部门、哪个人。
这种现象对于已经深入到企业每个角落的IT产品、IT服务也是如此。早上ERP登录不上去了——这到底是网络问题，还是ERP问题，或者是数据库、服务器出错了？IT部门到底应该找哪个供应商解决问题呢？
当我们把目光转向SOA时，同样的问题出现了——当应用因为一个根本性的故障而被迫终止的时候，应该由谁来负责接听并处理用户的紧急求助？
目前SOA已经步入实施的纵深阶段，然而，近来国外的一系列SOA实施案例表明，曾经备受肯定的SOA架构正暴露出其架构的固有缺陷——当基于SOA的服务管理达到一定深度时，目前的SOA管理策略在服务故障的追根溯源方面力有未逮，这一现实对整个SOA架构和管理理念都提出了严峻的挑战。国内SOA用户应该对这一动向保持足够的警惕。SOA管理缺乏全局眼光
“这是因为每个人的眼界都被限定在他们自己负责的那部分基础架构工作里，而这恰恰是SOA架构的特色之一。”海福纳说。
那些服务管理达到一定深度的CIO们目前面对的现实状况很不乐观，为了解决这一问题，SOA的管理策略和解决方案必须重新进行调整，以帮助他们解决那些深层次服务管理问题。
海福纳认为，SOA管理方案应当从多个方面调整各种服务之间的关联，比如为消息添加更多的标识。这样一来，服务中产生的问题可以更容易被独立鉴别出来，CIO们也更容易判断应当向哪个开发团队求助。
海福纳还指出，通常，SOA管理解决方案的眼界未能上升到整个SOAP界面。但是，即将涌现出的新一代管理工具必须站在整个服务界面的高度审视底层的数据库、服务和消息层。
“你所购买的SOA管理解决方案，必须能够处理执行复杂服务的SOA底层服务需求。海福纳说，这一任务可能细致到涉及调用Java消息服务、MSMQ、Java RMKI或CORBA等一系列服务，这背后甚至需要一个专门的ESB或应用服务器予以支持。
将“深度”牢记于心
对此，海福纳对那些未来希望基于SOA架构搭建应用的CIO们提出了自己的建议。建议之一就是忠告他们充分理清自己的SOA管理策略。他认为，在CIO开始考虑该选用那种SOA管理工具之前，应该首先搞清楚你打算怎样做好SOA管理。CIO们将不得不深入了解各种技术，了解自己企业将要实施的SOA管理将会复杂到何种程度，了解SOA解决方案是否能够帮助自己管理跨技术平台的服务以及了解SOA管理方案是否能与现有SOA的复杂度匹配起来。
此外，一个称职的CIO必须站在整个SOA管理全局的高度，着手建立深度SOA监督和管理机制。这套机制应渗透到架构设计、服务组件和服务接口背后的一切细节之中。
总而言之，在寻求任何SOA应用解决方案时，CIO们必须将深度服务管理的理念牢记在心。
