昨天谈到soa之所以不同，是因为它结合服务组件及流程，而形成严谨而具有美感架构的IT概念。但它是不是仅只是于「比较美」而已呢？它对企业运作，是不是真的发挥效益呢？让我们再随着昨天的例子继续走下去。
「变」才是自动化IT最大挑战
伴随着澳图美德跟Sun 原厂生意往来的增加，他们的合作关系越来越密切，也越来越有信任感，因此在两边老板与业务同仁热切期望与鼓吹下，在短短一个礼拜会议讨论后，老板们握手作出以下决议：「面对市场的快速反应，某些单期的商品，只要是澳图美德业务人员确认后的订单，Sun原厂这边就可以直接出货，澳图美德的同仁只要事后在一个月内补上订单及货款即可，以缩短整体的交期。」
这样的消息对两个公司的业务同仁而言都是一个普天同庆的大好消息，特别在信任感足够的前提下，交期缩短的做法会让客户满意度增加，并相对地提升业绩，特别对澳图美德而言，这样的做法会缩短货品在途与减少库存，可大大提升两个公司在整体销售上的执行力。
但获得执行力是要付出代价的。
老板又继续说了下去：「为符合这样的需求，请IT人员于半个月内修改系统…」一语未闭，信息部门的同仁全都当场傻眼（并考虑要不要递出辞呈）：天啊，当初为了达到整体的商业自动化，花了澳图美德公司与Sun原厂的信息同仁们三个月时间的系统分析以及六个月的程序撰写，最后逐一的测试，直到上个月才刚算完全测试完成的系统，半个月要怎么改啊？疯了吗？
IT主管们（特别是信息长与技术长）所面临的最大挑战并不是一个固定的商业行为，其实大部份跨企业/组织的商业流程自动化需求都可以利用传统EAI所使用的IT技术手法来完成；讲白了，IT人员只要把商业的作业流程定义清楚，不管采用什么技术（VB、JAVA、N-tier、mainframe、有数据库就用数据库，没有数据库就用最笨的方式，像是TEXT file等），大部份商业上的需求都还是可以硬生生--不论用苦力技术或高级的方式（例如对象导向加XML）来实作出来，但最大的挑战往往发生在商业流程改变的时候。
「规划永远赶不上商业变化。」这是所有IT人的痛，因此当我们谈到商业自动化，「流程」只是故事的一半而已。也是soa的切入点所在。
在瞬息万变的经营环境中，soa目的在于更深一层去关切并预想商业流程的变异性，并思考、定义与切割一个个服务与流程，以强化企业商业自动化的灵活度。
是营销名词还是真的有用？
谈到这边，我想「为什么要soa？」或「soa是不是一个营销术语？」应该会得到较清楚的答案。在商业自动化为前提下，「服务组件」与「流程」可视为商业自动化的基本元素。面对商业行为的变异性，在「服务组件」与「流程」的设计与实作上，应该要达到弹性并且可以重复被使用的水平，以减少系统重复开发的时间，这样子以商业服务为基本元素来做为的出发点，而设计出来的IT架构，我们就称之为「服务导向架构」(soa)。
而在这样一个约定而成、公开规范的soa架构下，企业便可藉由「服务组件」与「流程」灵活组合（就像玩乐高积木一般），因应瞬息万变的商业行为需求。
理解soa的本质后，我们再来看soa中各个信息原厂或SI厂商所提出的各种五花八门信息名词时，应该就会比较清楚个中差异。例如：BPEL（Business Process Execution Language，商业流程执行语言），简单说就是特定信息语言可以用定义及规范各个服务组件的执行的先后顺序与因果关系（也就是流程）。再如ESB（Enterprise Service Bus，企业服务总线）则是服务被实践的地方，ESB在系统与系统间、企业与企业间，负责整合的作业，让「服务」的串连形成一个总线（Bus），如同巴士（Bus）一般地，传递跨系统、组织与企业的信息服务。
面对企业信息「整合」的需求，soa并不是唯一的答案，但无疑地，随着soa技术逐渐发展成熟，新的概念与技术可以让企业面对商业整合时可拥有更大的弹性与效率。而接下来的专栏文章中，我们将陆续探讨soa对企业内人事、流程、甚至CEO角色职权的冲击。
文/杜奕锋
