【IT专家网独家】这是OASIS论坛上SOA专家们讨论后所取得的一致意见。其中一位专家，Intel公司的高级程序经理Robert Carpenter在总结该问题时说，讨论SOA时提到的XML, SOAP和UDDI对管理并没有意义。他认为，架构师应该更多的关注其业务价值。

　　Forrester Research高级副总裁也提出了相同的看法。他说，SOA只有在IT部门和业务部门能够相互沟通，一起工作的情况下才能体现出价值。

　　因此，问题就是如何在IT技术人员和业务经理之间搭建沟通的桥梁呢?

　　为BEA公司负责全球咨询的高级主管David Groves就在为搭建这座桥梁而工作。他相信，有办法在业务和技术之间获得平衡，因此SOA是可行的。

　　他说：“技术和非技术方法的平衡能够造就成功的SOA。”

　　但是这种平衡并不容易达到。

　　他在最近对一位经理的谈话中提到，CTO们都在为找不到头绪而烦恼，因为IT专家和业务经理都不想对SOA项目中的特殊问题负责。

　　Groves 针对CTO们的困境说：“IT部门说自己没有问题，HR部门也说自己没有问题，财务部门也说同样的话。于是大家成了一个圈。”他认为，这种恶性循环在SOA的最高层就能看到，即那些业务策略和过程有定义的，被SOA项目支持的地方。每个部门都从陈旧的分组观点来看，所以都觉得自己没有问题。

　　Groves说：“由于人们不知道谁处理这些问题，所以就没人负责。而且由于他们出于技术术语太难理解而缺乏沟通，因此更不知道谁该管这些问题。”

　　但是他并没有放弃希望，因为他已经发现这个困难的原因也是组织中技术和非技术人员沟通的起点。

　　基于对真实SOA项目的咨询经验，BEA的咨询师在过去两年中已经为沟通SOA开发了模型，它由6个没有专业术语的领域组成。其中三个分别被称为“业务策略与过程”、“开销与收益”、“组织与管理”，它们都是最基本的业务问题。另外三个“架构”、“构建块”和“项目及应用”的领域是基本的IT问题。Groves说，所有BEA模型中的6个领域都用最少的专业术语来表达，以使非技术人员可以和架构师和开发人员更容易沟通。

　　在开始讨论SOA如何支持业务策略和过程时，就可以打破沟通障碍。Groves认为，在项目开始时，让技术人员和业务人员都理解SOA如何实现并达成一致，将对业务起到帮助作用，这是成功的关键。

　　他说，当C/S结构在90年代盛行时，这样做并不可行。因为业务人员被强迫在确定应用程序可以帮助他们完成工作之前，就要学习开发人员的专业术语。并且，然后才考虑业务策略和过程。

　　他说：“有意义的是业务策略和过程域可以使IT部门和业务部门有办法用一种任何人都能理解的方式讨论SOA。有了SOA，进一步考虑业务策略和过程、开销与收益、组织与管理就显得更重要。事实上，研究显示缺乏对这三件事情的关注将使得对重用的尝试不如预想的那么成功。”

　　Groves说：“正确实施的SOA使服务能够根据服务的业务策略和过程被讨论，因此业务用户能够理解并参与讨论和决策制定。”

　　他说：“基本原则是让SOA可以理解，让它成为业务部门和IT部门共同拥有的东西，这样当产生一个业务策略时就能直接连接到IT部门。我认为过去很多情况下，这是为什么人们对应用不停抱怨的原因之一。”

　　在过去，COBOL程序员很可以是C/S时代最接近业务人员的人。Groves觉得，SOA又重新把开发人员和业务人员自然地联系在一起。

　　他说：“对我来说，我喜欢SOA是因为它让开发人员更接近业务人员。我感觉”开发人员被中间件推的越来越远，越来越抽象。而在服务的现实中，服务变成了与某个过程相关的服务功能的一部分，并且与其它过程可以互操作。它把开发人员拉回到真实的业务中，因为他们知道与业务交付给客户的东西紧密相连。我认为SOA对开发人员的确是有积极作用的。

　　TechTarget独家授权文章，严禁转载

　　查看本文国际来源 >>