SOA 背后的管理哲学

　　SOA与之前软件思潮的几种技术架构最大不同是它面向业务的设计。SOA的架构理念，不仅用松耦合的分层结构隔离了技术，使得业务和技术的变化周期可以不互相影响;更重要的是，它还可以把不同知识域的人放在一个平台上讨论问题，比如用一个Workspace平台可以将业务人员，架构师，IT主管，程序员集成起来，让他们可以在一个桌子上交谈，从业务流程的设计到实现，现在可以用一种贯通的方式进行讨论与及时修改。以前，不同知识域的人群，由于专业分工，有各自的思考角度，互相难于理解。现在，那些以前隔着墙打电话的人，可以在这样一个平台上共同的交换信息，完成任务。所有人都知道好的应用程序是不可能由不懂业务的程序员开发出来的，但苦于无法在业务和技术人员之间建立一种共同语言，现在这种语言出现了，就是服务。

　　服务之间的调用用契约来固定，其实不难理解，这其实就是市场经济的本质。最早理论基础要去卢梭的《社会契约论》来寻找，西方经济体系就是基于契约架构起来的。具体到SOA的设计哲学里面，Design By Contract的目的完成了服务之间调用标准，也为未来遍及整个IT系统的服务网络提供了基础。Google与其商业客户之间的靠点击来计算收入的方式就是个参考的例子。以后的服务之间的调用，如同市场上的交易，可能是按次收费的，这样才会把服务的生产方调动起来。这种模式，在汽车这样的传统行业早已通行百年，每种特定的零件都可以有很多的供应商，只要基于标准的契约来设计，安装到整车上都可以保证整体的功能。软件行业的奇特之处在于，尽管软件行业在普通人看来是个高科技，但这个行业，在基于标准的生产方式上，远远不如离散制造业。这个行业充满了孤胆英雄，绿林大侠，自我为中心的散漫气质，在中国还有一种诗意的浪漫情怀。在软件行业内部的人，都觉得自己的江湖很有武侠境界的气质。现在SOA要讲契约，讲标准，讲交换。程序员出身的人也许会说，还不如自己开发一个。这也许是Design By Contract面临的最大文化难题。

　　北美的SOA咨询顾问们，关于SOA实施的一个口头禅是，SOA是一个3-5年的旅程，唯一的办法就是循序渐进。我们可以把SOA理解为一种混搭的中庸架构，说它混搭，是说它是独立于技术的，说它中庸，是因为它必须与现有的各种系统相融合。SOA改变的不仅是开发方式，而且是管理方式，甚至是业务组织的方式。它不是个IT战略，还是一个公司战略。在这个缓慢进行的改良主义过程中，如何在每个阶段可以有一些阶段性的回报，是管理者必须考虑的问题。没有管理者会批复一个五年后才能有回报，又需要投入巨大精力的提案。针对每个企业设计一个有针对性的演进路线图，这不是个技术问题，而是一个业务问题，有一个瑞士保险公司的SOA案例是，客户在一年半的时间里达到了实施SOA项目的正向投资回报，其中的案例分析精确得像财务报表。只有这样的案例才会给管理者巨大的信心。不是在所有的情况下都会找到这样的项目，这种情况需要找“SOA友好”的项目，SOA的特点有很多，比如，它和业务敏捷正相关，它和变化的强相关，和集成项目的强相关，和企业治理的强相关等等。客户必须从业务和IT两个角度来寻找切入点。只有步步以ROI为考量，才能将这个旅程走下去。

　　只需要用一天把SOA的基本设计哲学讲给一个管理学教授，他就会很快发现，SOA的管理与控制都是管理学命题。去年在有关SOA的播客节目里面，我第一次用杀人游戏来比喻SOA面临的多重囚徒困境，很快在最近得到一些客户的印证：推进SOA真正的难题在于组织障碍。比如，每个部门都想享受别人的服务，但自己却不愿意开放自己的服务，现有的组织架构里面，IT部门的工作有时需要靠人脉来解决，但一旦真正开始SOA的转变，一些硬性的部门利益冲突，就不可能靠人脉来解决了。信息的拥有权在现在的时代如此重要，很多时候是部门不愿意公开的秘密。SOA的共享理念，需要采取一种变通的方式，来获得各部门的支持。这很象一个建立城市公共设施的课题：如果SOA的目标是在企业级建立一套共享的IT资产管理体系和标准，那么这个工作就不可能仅由IT部门可以推动。在SOA项目的管理支持里面，需要一个SOA管控委员会，凌驾在所有部门之上，拥有绝对的生杀大权，这在很多企业里，好像要把分属战国诸侯的资产，统一起来，象秦始皇那样统一度量衡。最近，很多美国的评论家，仍然认为，中国是所以成为现在的统一国家，秦始皇的贡献最大，因为他统一了度量衡，语言，甚至包括车辙的标准。作为暴君的秦始皇给人的印象不好，但建立的标准人人在享用。类似的近期版本是苹果公司，很多管理评论都认为，正是乔布斯的暴君风格才保证了苹果过去几年的成功。政治学中有个词描述这个概念叫“政治所必要的恶”，就是这个意思。整治竖井式的部门应用，看来没有专制的狠手不行，这叫制度保证。这也许会引起草根程序员的反感，但没办法，你看到哪个讲民主的公司成功过。