CharlieShen

用契约的方式定义层次之间的关系

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

用团队演进的方式平衡长短期的ROI

  北美的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管控委员会，凌驾在所有部门之上，拥有绝对的生杀大权，这在很多企业里，好像要把分属战国诸侯的资产，统一起来，象秦始皇那样统一度量衡。最近，很多美国的评论家，仍然认为，中国是所以成为现在的统一国家，秦始皇的贡献最大，因为他统一了度量衡，语言，甚至包括车辙的标准。作为暴君的秦始皇给人的印象不好，但建立的标准人人在享用。类似的近期版本是苹果公司，很多管理评论都认为，正是乔布斯的暴君风格才保证了苹果过去几年的成功。政治学中有个词描述这个概念叫“政治所必要的恶”，就是这个意思。整治竖井式的部门应用，看来没有专制的狠手不行，这叫制度保证。这也许会引起草根程序员的反感，但没办法，你看到哪个讲民主的公司成功过。

那一天

我不得已上路

为不安分的心

为自尊的生存

为自我的证明

路上的辛酸已融进我的眼睛

心灵的困境已化作我的坚定

 

在路上 用我心灵的呼声

在路上 只为伴着我的人

在路上 是我生命的远行

在路上 只为温暖我的人

温暖我的人 

用松藕合的架构整合不同知识域的人群

 

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

• 政治智慧

现在的CIO处在一个充满了各种各样利益相关者群体，复杂的商业生态环境中。而SOA作为一项企业长远的IT策略和计划，需要改变业务部门和IT部门合作的方式，需要改变组织和文化，必然存在各种利益的冲突。因此，如何处理与各种利益相关者之间的关系，平衡各方面的需求，应对来自不同方面的各种声音，这需要CIO懂得如何应用政治智慧。组织内外的利益相关者可以按照权利和态度两个维度划分为四种类型：强支持者、强反对者、弱支持者、弱反对者。CIO应该努力将有影响力的反对者转换为支持者；对于无法转变的反对者要限制他们的声音；要努力保持强支持者的影响力；扶持弱支持者；同时还要关注弱反对者的利益。

• 执行智慧

CIO着眼的通常是具有很高不确定性的，未来的IT战略。但不管IT战略是什么，必须把这些长期目标转变成意思明确、可衡量的、可操作的短期目标，响应迫切的业务需求，循序渐进。通常，业务部门与IT部门在对如何达成目标的方法上经常存在差异，比如业务部门喜欢 “速效”（quick win）方案来证明IT的价值，而IT部门则更倾向于先构建基础架构。智慧的CIO需要在“见成效”和“打基础”上寻求一种平衡，先快速地向业务部门证明SOA的价值，让他们乐于参与其中，再逐步发展SOA基础设施，更加主动地响应业务目标，实现自己全局的IT战略。

 

SOA呼唤智者，正确的认知，决断拣择并恰当执行。这是一个坚难的过程。幸运的是，我们在以电信、金融、电力、政府行

这两年来，关于SOA的各种概念探讨不绝于耳。几乎没有人会质疑SOA对于加速变化的业务环境的商业价值，但坦率地说，截至目前，被真正打动的CIO寥寥无几。从心理学的角度，人在对待未来和做出决策的时候，通常有两个截然不同的视角，一个是希望，一个是恐惧。前者愿意从好的方面预期，认为它可以让自己变得更好；而后者往往是坏的方面看待，而畏惧向前或焦虑不安。就像前段时间大家津津乐道上证指数会涨到5000点，有人毫不犹豫，也有人谨慎乐观，还有人保守不前。因此，我想SOA尚不能打动CIO的一个最简单的解释就是：不存在市场可以买到的开箱即用的SOA，它包括了许多未知的因素，而未知事物往往是恐惧的源泉。

 

前不久看CCTV-2的《赢在中国》节目，听到一段主持人就“聪明和智慧”的评述：“聪明是对当下事物的瞬时反应，一下子显出很机灵；智慧是一种对未来预测的，不确定性的事物的一种判断，这是两下的分野”。非常精彩，也使我对智慧一词突然间有了兴趣。Google一下智慧一词，获得以下注解：“智，意为决断；慧，意为拣择。智慧是一种对事物认识、辨析、判断处理和发明创造的能力；展现智慧的人具有在复杂而微妙的情境中迅速地、十分有把握地和恰当地行动的能力”。想起以前看过的一篇网文，里面提出的一个很有意思的问题：“当CIO遇见SOA，该希望还是恐惧?”。现在看来，我以为要回答这个问题，对于CIO而言，智慧显得非常的重要。如何决断拣择并恰当执行，这其中的智慧我想至少应该包括以下三点：

• 战略智慧

CIO的使命是为组织贡献其技术远见和领导能力，主动开发和实施IT应用，在持续变化和激烈竞争的市场中创建并保持企业的领导地位。这决定了CIO应该首先具有战略视角，为组织建立一个IT愿景，将企业带向更高境界的、清晰的和引人注目的蓝图。这需要CIO关注技术创新，从创新中发现其蕴藏的新的机会和商业价值，结合企业自身的实际，发现解决业务问题的新机会和新方案，并恰当地执行。几乎所有的创新都会带来变革（SOA也不例外），而变革通常伴随着不确定性，并产生与其解决问题相媲美的新问题。但如果我们完全被对新问题的恐惧所控制，企业将永远停滞不前。我也同意，某些时候当缺乏执行的条件，放弃也不失为一种战略智慧。

 乐高玩具—作为一种设计哲学的SOA

这是最早的一个成功的比喻，传统的应用好比是普通的玩具，不可拆卸和拼接。基于SOA的应用都是由更小的服务组件组成的，如同乐高玩具的模块。用乐高玩具可以搭建各种不同的形状，好比可以实现不同的应用，乐高玩具的模块式基于标准的，而且可以重用。这个比喻的好处是很快给非技术人员建立一个头脑中的形象，在一个研讨会里面，组织者发了一些乐高玩具的模块，让客户们自己做出一些东西来。由此很快让听众明白，他们就是在做和软件开发类似的事情。

也许有人会说，SOA那么复杂，用小孩玩具来比喻是否太浅显了，这时，进入深层次探讨的机会来了。看上去，乐高玩具这么简单，似乎没什么深究的。这背后隐含了一种设计哲学，设计乐高玩具的团队都是一群拥有博士的设计专家，他们必须解决的一个矛盾是，如何把标准，松耦合，模块的功能，力学等要素在设计和规划的时候统统解决，留给使用者的，只有玩乐的乐趣。一个有趣的事实是，乐高玩具这样一个看上去如此简单的东西一直没有模仿者。软件工程师都可以用十分钟说他知道SOA是怎样一会事了，就像所有人看到乐高玩具时一样。然而，当一个人用设计者而不会玩家的角度来理解乐高和SOA类似的设计哲学时就会发现，两者的服务对象其实正是不需要关心技术的人，而且，他们都是为技术买单的人。工程师的位置，到底是个玩家，还是设计者？作为玩家，工程师懂得似乎多了一点，做为设计者，他还有太多东西要学，就像要成为乐高玩具的设计者一样。

电视与电脑—一个基于标准的结构

 修电视比修电脑难多了，虽然电脑比电视复杂多了。因为电脑有一个基于标准的结构，总线结构，即插即用的契约标准，这些IT界的流行语塑造了PC行业。SOA也拥有几个标准的参考结构，总线，松耦合这些理念和PC行业的基本理念完全相同。这个比喻的好处是，电脑是一个更为具体的例子。这个例子隐含了用比喻说技术的几个规则。第一，被比喻的事物之间一定要有同构，这是比喻的一个逻辑前提，就是说在基本结构上，两者的设计理念是近似的。第二，用于比喻的事物最好是人们喜闻乐见的，通俗的，第三，至少可以举出几点证明两者的相似之处。

 从我第一次听说SOA到现在有几年的时间了，其间和各种各样的人士有了各式各样的讨论，越来越发觉这不是个可以用定义来说得明白的概念，以前软件行业里还没有个词容易引起如此多的非议与争论，我有时觉得SOA很想禅宗里讲的，“说是一物即不中”。其中最难的，就是把这样一个抽象的概念说给没有技术背景的人去听，建立概念唯一的办法就是利用比喻。在我听说过的几十个关于SOA的比喻之中，有几个比喻得到更多人的认同。那些想把这个概念说给业务人员和管理者的技术人员，不要再冒险了，用这几个比喻试一下。

王勃的故事