刘尔洪：各位来宾大家下午好！我今天跟大家分享的主题是想来解答一下为什么服务构造和业务发展流程是SOA中国发展的关键任务。在讲这个之前，我想我们先来回顾一下利用SOA我们到底要实现什么。

　　SOA的目标，我相信大家都比较清楚，实际上它的终极目标是想实现一个敏捷型的企业，什么叫敏捷型的企业呢？就是我们企业在很多年的IT建设过程中，无论是新建的还是怎样，通过不断积累，会形成一大堆原来的IT系统。原来我们企业的模式，就是说，可能我们建一个系统，它的生命周期很短，我们要一遍一遍的重建。SOA里面，就是我们能够把企业IT系统真正的能够作为资产，就是未来我新业务的建设都是在我原有IT资产的基础上，形成对业务支撑迅速响应能力，有一个数据统计，我们现在IT支撑能力，响应变化能力，实际上落后于我们实际业务变化能力的7到20倍。所以SOA本质上是建立一个敏捷型的企业。

　　我记得2002年的时候，当时中国EAR这个概念刚刚兴起的时候，大家知道当时EAR当时红红火火好几年，各个厂商、用户开口闭口都是EAR，主要是一些大的企业，试图通过EAR解决类似的问题。当然这个里面包括集成的问题。大家可以看到，后面我们EAR真正应用并不是很好，所以这几年IDC的观点，它是讲的我们在接受SOA的同时，还是能够以务实的思路去看待SOA。

　　刚刚有位朋友提到什么样的应用需要SOA，什么样的应用不需要SOA。实际上不是所有的应用都需要SOA，如果我讲的很简单，我这个企业可能就是一个单一部门，单一的业务，这个时候不一定需要SOA。当然如果我有很多业务部门，有很多供应商，我需要它们快速协同去工作，那么这个时候SOA可能就比较重要。SOA的理想是什么呢？就是我们现在很多去讲我们的SOA解决方案的时候，基本上和这个图大概类似。就是原来有很多的遗留系统也好，新建系统也好，能够通过ESB，把原来的系统服务，先是把我遗留系统的服务能够重新包装好，通过ESB可以注册管理起来，同时跟其他的信用交互的时候，我有一个物流交换，还有通信转化机制，最后通过BPM流程编排，就很容易把一些服务组装成一个新的业务。这个实际上是一个理想的情况，为什么这么说呢？这个是把问题简单化了。我想通过一个具体的案例来讲一讲为什么津津有ESB，或者在ESB上加上BPM，依然不能解决我们说的目标当中要实现敏捷型的企业。

　　我不知道大家对SOA有什么了解？做大的服务等级的开发商或者是我们电信或者金融的客户应该都会经历这个过程。我这个里面举了某一个电信运营商引入SOA的这样一个过程。这是一个很自然的，因为电信的运营我要不断的精细化运营，为客户提供差异化服务，肯定给客户分类，对不同等级的客户提供不同等级的服务质量，进而我可以跟他签订不同服务，这个肯定是发展方向，而且我们现在正在发生的。但是如果我们去看这个例子，就是说，如果某一个运营商引入SOA，我们把它看成其中一个业务，比如传统的固网，DDN，我不知道大家是否知道DDN，就是一个数据专线。原来我们在没有SOA的时候，实际上你只要告诉原点、终点，就是从哪到哪，电信局就给你拉通了，现在有了SOA指标就不一样了，我要签这个合同的时候，要把它的接通率的保障，是不是提供备用量，以及它的服务的优先级开通的实现，我都要作为要求的。如果你运营商达不到我这个要求，我可能付给你的钱是比较低的，如果你要达到这个要求，我可能付给你的代价比较高。自然是这样，大家想想原来我们在证券行业，大家可能炒股，我们下单的时候，大股的从证券公司到交易中的线路都是都是通过DDN专线，如果这个线断了，这个是什么后果？后果很严重。我们看看它的演进过程，时间关系，不具体讲业务过程。大家可以看到因为要引入SOA，那么对产品销售的流程，前端会有这样的变化，这个变化就是原来我直接受理DDN专线业务，现在变成我前端要有客户经理的参与，跟电信的这一块沟通，因为它想要的服务保障，我现在后端资源不一定能够保障，所以大家看，有一个人就表示人工的环节，这个里面有很多拓展图的，就代表自动环节。大家看我这两个人工活动，就划分出多了三个人工环节，多了一个自动环节。后端我们开通过程中也会有很多变化，我刚刚讲了售前，实际当中，资源配置上，会根据SOA里面不同客户不同类别，我就要走不通的开通流程，所以这个流程变化是比较大的。

　　我们就对这样的案例做了梳理，这个梳理结果我给大家看一下，总共把整个销售和开通的这项业务过程中，所有涉及到的服务我们全列出来了。这里有它的状态是需要修建，还是重用，还是需要改进。最后的结果是我们需要改进的有53%，就是整个的服务，因为引入了SOA，我这个服务不合适了，要去调整这个服务，有53%服务需要调整，只有27%服务可以完全重用的，还有20%服务需要重建。而且从这个里面，我们可以得到两个结论，一个结论就是我们在管理流程演化的时候，对IT系统的支撑，对流程这个环节，不仅仅是说我能够自动的流程编排好就可以了，而是这个里面会存在大量的人工。为什么强调这个人工环节呢？这个前面无论是放的片子，还是程先生都讲了，中国跟一些发达国家是有很大的差别，这个差别实际上如果我们从流程的角度来看，在人工这个环节差别是最大的。为什么？因为人工环节它会涉及到组织和人，我想所有的人都会有这样的感觉，中国只要涉及到组织，涉及到人，这个事情就变化多了。因为领导会随时让你干一件可能是原来工作不相关的事情。所以在我们看了这个流程演化过程中，实际上你会发现有大量的人工环节。

　　第二，我们有高达73%的服务，需要更改我们的内容或者是新建。所以，大家都知道，如果开发做得比较多，如果我们说高达73%的服务都需要重新建设或者是需要改进，对我原来系统意味着什么？如果没有很好的服务架构，基本上这个系统就会出现问题。

　　实施SOA的挑战和难点，从非技术层面来讲，我觉得最大的挑战是企业管理上，就是流程是否规范，组织是否健全，是否稳定等等这些方面，我认为是很大的挑战。是不是稳定可能还好说一些，主要是你这个流程化情况怎样，如果从技术层面来讲，刚刚我讲了，我们管理流程需要不断的演进，而作为一个企业来讲，无论你今天做到什么样子，也许你今天管理水平很高了，但是你还是要持续的优化，优化你的流程，调整你的流程，在这样的环境下，随着管理精细化，你的服务是要求越来越细，要求越来越提供比较细致的颗粒化的服务。刚刚有个朋友问到了服务颗粒化问题，我认为这个问题不好讲，尤其中国这个环境里。因为你很难有一个非常稳定的，我就是这么大颗粒度的服务就可以了，我们刚刚谈了中间出现的很多管理流程的环节，都是要有相对应的服务，这种情况下，作为服务这一块，必须要有灵活的架构是第一位的。当然我规划的好，抽象的好，相对来讲，也可以让它适应度更好一些。

　　第三，刚刚我讲了服务的颗粒度的问题，就是管理流程演进，需要越来越流程。如果实现我们说的SOA目标，就需要业务层面上，要具备配置流程。现在我们讲的很多BPM的解决方案，实际上是具备这个能力的，更多是编排一些自动活动。如果对人工的流程多了，很多一些比较复杂的处理，可能也很难处理。

　　另外，在中国人工活动是具有它很复杂的特性。比如说，在中国有很多代理、代办、督办、会签等等这些和人工活动相关的环节。这样一些处理和我们很多流程规范里都不会有这些内容，而是它只是存在于中国这样一个特殊环境中。我们要想能够达到这一点，还是需要具备很好的适应中国复杂人工环节的特点。

　　SOA的中国关键任务，我的论点是服务构造和业务化流程这两个问题。

　　第一，我们怎么样建立高质量、可扩展、易管控的服务。

　　这个我们的论点，就是服务的颗粒度，要很好的根据我的需要去变化。所以你的扩展能力一定要强。质量就不用说了。可管控是什么意思？就是要在服务的全生命周期，都要有很好的管理，实际上刚刚程朝晖先生也讲了，从管理技术和业务这三个角度，我们要能够达到一个矛盾的统一。

　　第二，业务流程需要强大的业务配置能力和人工环节处理能力。

　　讲到这里，有的人可能会问，我能不能通过规划去解决我的服务的颗粒度的问题。这个我刚刚已经回答了，就是很难通过规划去解决。为什么？中国这样一个环境下，在全球都是很难的，有的很多变化是我们不可预计的。比如中国电信行业，在近十年里，三番五次的不断的重新组合，它每次重新组合，对它原来的组织机构、职责、业务流程都产生翻天覆地的变化。就是你要按期规划做得再好也没有用。一旦变了以后，你发现原来规划的服务都没有用了。所以从规划角度，通常会有自上而下和自下而上两种规划的方法。

　　实际上在中国更适合的，还是说我有一定的自上而下的规划的基础上，更多是采用自下而上的去规划服务，可能更来得可行一些，自下而上的意思就是我先看我现在看得到的一些东西，现在看得到的系统遇到的一些问题，比如我现在要走CRM，我应该提取哪些服务，可能这些服务和我其他系统有一些什么关系，这个可能从成本化收益的角度，可能投资回报率更高一些。所以，我们很难从规划的层次去解决这样的问题。

　　我们下面来看看服务构造，为什么会比较困难。这个里面我想大家在座的可能对原来我们没有SOA的时候，建设应用系统的时候，有很多的体会。我不知道大家很多都存在这样的问题，就是越大的项目，达不到项目的预测概率越高。你会发现失败率是比较高的。我调研过很多的公司，基本上都存在着这个问题。

　　第二，项目实施的周期和质量不可控，常常拖延周期和发生质量问题。

　　第三，技术人员很辛苦，但是你会发现价值得不到体现。进而，会引起我们的技术人才流动比较大，项目质量的成功也是更多取决于我们每个人参与这个项目的个体素质。

　　第四，难以进行知识转移和知识承接，知识积累比较困难。也就是说，我如果参与一个项目，我积累了很多东西，我要交给另外一个人，在这个基础上去发展，这是一件很困难的事情。

　　最后，服务构造的标准化的问题。在电信行业里有一句话，不知道大家是否知道。就是真爱生命，远离BOSS。就是指做BOSS这样大的一个系统，工程师都很辛苦，但是常常因为最终交付的东西达不到用户希望，所以大家辛苦的价值没有被充分体现出来。这个问题从哪里来的呢？我想分三个层面来看：

　　第一，看一下软件规模和生产率的矛盾。

　　按照软件行业的经验，用户对我们的要求，移动的BOSS规模，两年之前是大于360万行，那个时候我记得我们有一个大的开发商，它一共有四个版本，等于1600万行，这个公司要维护1600万行代码，如果按照上面顶级标准去算，不讲上线、部署、推广，也要3000人月，电信CRM是大于400万行，超过3000人月，开发期一般6到12个月，前一段时间我们CTO在上海站演讲，讲到国内可能用户给你1/10价钱让你做一个10倍于美国这样的环境复杂度的软件，实际上从这个数据上就可以看得出来。

　　在这样一个条件下，我们交付的软件，如果没有一个很好的方法，你是不可能像我们刚刚讲的那样，有很高质量很低成本，而且也没有用户付得起这个钱。我们解决这个问题的有效方法，实际上刚刚最开始沈先生在他的报告中已经讲了，传统行业给了我们很好的借鉴，一个就是我们要能够不断去提升我们的复用能和生产工艺的改革，生产工艺的改革是任何产业发展到一定阶段时候，必须要经历的事情，而且谁能在这个里面抢得先机，谁就具有最核心的竞争能力。

　　第二矛盾，可扩展、快速变化和高质量的矛盾。

　　也就是在不断变化环境下，我还要让它高质量，这个事情比较麻烦。大家做过项目实施的都有体会，用户需要你改这个，改那个，还要把文档做好，测试要做得很充分，还要让软件质量很高，这个也是很大的矛盾。要解决这个矛盾，必须从技术架构入口去解决。原来可能我们有很多的用户是不关心这个架构，我那个时候和他们沟通，我说如果我给你一个选择，今天我给你两种方案，一个方案是百分之百把你业务功能做出来，我的扩展性比较差，稳定性比较差。还有一种方案，把你50%功能做出来，但是我告诉你另外50%业务功能稳定性比较好，可扩展性比较好，他们一般会选择第二种。这就说明非功能性需求有时候比功能性需求更重要，因为第二个业务功能没有完全实现，但是非功能性需求做得很好，这个就靠我们软件架构保证的。也就是软件架构的存在，之所以我们需要一个架构，就是因为我们有很多下面这些非功能性需求需要解决，它的可扩展性、性能、稳定性、可维护性、可管理性，尤其可维护性、可管理性架构设计的时候没有考虑，你等系统做完了再考虑，是一定做不到的，你会发现维护这条系统很麻烦。

　　第三，管控问题。

　　我想讲一个全程管控，还有从软件生命周期来看，从软件的需求开始，设计到开发，到测试，到链条，到上线，到后面的维护，到再使用全生命周期管控，实际上软件行业做得很差。我刚刚讲的软件项目，取决于每一个工程师个体能力，实际上就是一个这样一个缩影，就是做的过程当中，我做什么样子没有人可以知道。这个问题怎么造成的呢？我觉得最重要是软件生产复杂度太高造成的。任何一个东西太复杂了，我们都必须要借助于工具去解决。就跟我们今天，如果面临管理一两个客户，你可能脑袋里面肯定记得你不需要任何工具，你要管理上百个上千个客户，肯定是需要一个工具，如果像电信运营商管理几千万个客户，就必须要有一套IT系统，当你管理的东西达到一定复杂度的时候，一定需要这个工具。软件复杂度问题，因为它这么复杂，所以造成了这样一个管控的难题。所以要想去解决的办法，必须要依靠工具，光依靠工具还不行，必须还有一定的标准。

　　我们看到三个层面的问题以后，我们怎么样解决它？

　　第一，需要建立适合SOA的服务架构。

　　刚刚我说了架构重要性，就是我们可扩展性、管控性的一部分，都是需要架构里面解决。这个架构要去解决，怎么解决？比如说可扩展性，就是说我们需要从不同的维度去看架构的时候，都必须是一个可扩展的，我们看层次的时候有层次结构，从管理的视角，也有一些其他的问题。要都做到不是很容易的事情，大家平时更多的是关注我这个功能结构是不是做得很松散，但是层次结构可能就不够。普元提供了很好的解决方案，无论从哪个维度看上去都是松散吻合的结构。第二，将复杂的未知的服务能够分解为简单的收敛的稳定的单元。

　　如果我们今天统一都用汉字，大家知道中国常用汉字就5千个，汉字上组成词组，汉字和词组组成文章，这样就可以做成每个人可以理解的文章，我们能不能把复杂服务，分解成稳定的单元，有限的收敛单元是很重要的。

　　最后采用标准化的技术构造，形成天然的SOA服务。

　　第二，建立统一封装的平台化架构。

　　我们最后要有统一封装的平台化架构，这个不仅仅是复用问题，我们作为一个平台完备性是非常重要的，当然还有一个很重要因素，既然架构这么重要，怎么样很完整的复用，最好有一个平台化的架构。

　　最后我们需要一整套方法，去解决我们前面提的这些问题。

　　流程平台的挑战和问题分析，如果要建立管理体系，从哪几个角度去建呢？就是这几个要素，流程、组织，组织职责是什么，流程是什么，人是什么，KPI是什么，建管理体系就是这样。从这个角度来讲，大家可以看到，在管理上，实际上这些要素都是经常变化的，无论组织也好，人也好，KPI也好，都会经常不断变化，所以我们在去实施SOA的时候，需要流程平台，这样就能够在业务层面上能很好的去配置我们刚刚讲的四个方向的灵活变化，今天由于时间关系，我不仔细展开讲了。等一下我们还有演示。

　　我再讲一下，我们去实现业务层面配置流程和传统模式有什么区别。

　　传统模式下实现一个业务流程，业务流程提需求，到技术部门去消化以后去设计，设计完以后，开发测试部署上线，最后给业务部门去验收。整个流程很长，沟通成本很高。如果我们在业务层面可以配置流程，它的实现模式是什么？实际上就变成了前面除非我在流程的实现的环节里面，有我新需要的服务，否则它在业务层面上全部可以自动调整，包括部署，包括自动的部署。完全就是实施部署的系统，我这个流程KPI也好，组织也好，人也好，变了以后，业务流程的页面上就可以做上配置，马上就可以测试验证去发布了。不一定需要技术人员的参与。

　　总结一下，第一SOA的规划很难用单一的自上而下或者自下而上的方法，而且很难通过规划去解决我们的服务颗粒度的问题。所以我们的服务需要一个很好的架构。

　　另外SOA关键挑战在于，第一，是管理流程的规范性建设和逐步演进的需求。因为管理流程的逐步演进是会要求你整个IT支撑系统，要能够具备支撑它的能力。在这个能力里面，有两个核心关键问题，一个就是服务的构造，我要足够的灵活，第二我要能够有足够的适合中国国情业务化配置能力的流程。它的解决方法，就是我们能够有一个适合SOA架构的这样一个平台的一体化的解决方案。谢谢大家！