这次我们谈服务导向架构 (SOA) 的执行面。一如近几年来导入 J2EE 架构和应用服务器，每当 IT 转型进入新的架构（从两层式 client-server 到 3-tier/n-tier 分布式架构），跌跌撞撞的情形在许多企业都会见到，特别是刚开始的时候。
深究阵痛的病因，不外乎事前规划过于轻率、architect 脑中仍残留先前 IT 世代的余毒、开发人员在实作上对新科技缺乏掌握度、与使用单位沟通不足等问题。而 SOA 的到来，architect 和开发人员在观念上和思维上所需调适的幅度，事实上并不亚于前几个时代的IT 架构间的差异。
如同先前所讨论的，SOA 试图让 IT 能更快和业务同步，在规划上以朝向提供弹性的业务服务为目标。从CIO到负责规划的 architect，需要和业务单位和策略伙伴间有充分的沟通。CIO必须体认， SOA 的建立，将会是一个为期数年的承诺，基础建设需要按部就班打起来，资助的模式也必须在 IT 和各个业务单位间建立，来陆续支持基础建设及各项业务服务的开发。
在规划建置业务服务方面，和在过去的 IT 架构之下相比，IT 和业务单位的互动幅度会需要更多。此沟通工作的执行，甚至会需要一种新的角色，在技术与业务间扮演桥梁的任务。
有些 architect 或许可以胜任这项工作。但姑且不论是兼职或专职，此项工作的负责人，除了 domain 的知识和 SOA 的认知之外，最重要的是要能不厌其烦地将业务单位的需求，与技术人员充分沟通，进而规划出较为完善而有价值的业务服务（或者说 “business API”）。
在另一方面，技术单位必须培养具备设计 “business API” 的新技能。对开发人员来说，转型到 SOA 所需要作的调适，幅度或许不如从 structural programming 到 OOP，历经「顿悟」般的转变；但对于习于使用 function call和组件等较为紧密结合(tightly-coupled) 的方式进行应用整合的 architect 和开发人员来说，改成从业务的角度来思考、设计 AP，且能充分掌握松散藕合 (loosely-coupled) 的设计法则，仍是一项新的挑战。国外一些开始导入 SOA 的企业CIO也纷纷意识到，设计“business API” 的技能，需要开始导入和培训。
如我们先前所讨论的，松散藕合的原则，是 Web services 和 SOA 承袭自第一代 Web（即 Web 1.0）的主要精髓，也是 Web 之所以能有今天，其背后最重要的关键因素。
要设计出业务导向的服务，开发人员在规划 Web services 接口和 XML 的颗粒大小（应囊括哪些字段和内容）等问题时，可以把要规划的接口单元想象成一个个的页面（不管是网页的形式，或者client-server 的 GUI 画面，或主机的终端画面皆可），其提供了一项项申办、查询、订购…的功能。
如何透过和业务单位 and/or 策略伙伴充分沟通（视该项 Web service 要服务的对象），从业务和续发展的弹性等角度出发，然后逐渐讨论、描绘出 XML 文件的各项字段，将会是规划业务服务的过程中，需要好好构思的一项重要工作。
文/萧百龄
