IBM软件技术开放日分会场二 毛新生主讲CDL

IBM软件技术开放日分会场二 毛新生主讲CDL2006.04.13
时间：4月12日 15：00-15：45
主讲人：毛新生
主持人：各位来宾，大家下午好，非常感谢大家能够一直坚持听我们的演讲，相信大家听了毛先生的演讲肯定会觉得不虚此行，为什么呢？因为SOA谈了几年，其实在各种场合中在各个领域里也有很多的交流，我得到反馈毛先生是讲的最好的人，希望大家多多问他一些问题，让他把演讲讲得更加生动和精彩。
毛新生：SOA确实是在太多的场合讲过同样这样一个题目，所以我深知讲大家听过的题目讲出一些名堂，是非常辛苦的，所以今天还是需要大家嘴下留情。
今天我希望给大家报告的主要有这么几个部分内容，第一部分，SOA究竟希望解决什么问题。第二部分，应该怎么样去看待SOA，当我们考虑SOA应该从哪些方面来考虑。第三部分，谈论IBM在SOA方面的方法、技术和服务。最后，做了两年多，我们也一些经验希望能够分享给大家。
现在的业务环境对于这些老板来说，他们关心的重点当然永远都是“钱”，是利润，是他整个部门和整个企业员工的生产效率，以及对各种各样的变化快速的响应能力，不管是客户的需求还是市场上的变化，这就需要他们做各种各样的创新。IBM有一些市场调查，像今年我们刚刚对全球的CEO做完调查，要做到这一点非常不容易，我们需要持续地创新，也就是说我们要改我们的业务模型等等。这样一个创新或者说这样业务上的转变，主要有这么三点：一，怎么样让我们的人在整个企业范围内部或者在企业外部，也就是跟我们的合作伙伴，跟我们重要的客户很好地协作。二，我们的业务模型、业务流程能够怎么样做一些改动，使得它的自动化的东西更多一些，效率更高一些，然后使得我们的业务模型的成本结构更加优化等等。所以，我们需要创新我们的业务模型、优化我们的业务流程。三，我们怎么样对我们的信息有更好的利用，这在我们日常生活当中是非常多的。
我接触过亚洲的好几个银行，这些银行都非常强调，跟我抱怨说他们现在没有办法，业务人员没有办法拿到一个单一的对客户的信息，其实在中国是非常普遍的，前不久我就面临自己的一个问题，我到中行给我信用卡交钱，我就跟他说，我现在在你银行有一个帐号存了多少钱，我有一个信用卡，麻烦你从这个帐号划一笔钱交到这个信用卡上去。这个柜台的小姐说对不起，我不知道你的信用卡花了多少钱，需要你打电话。然后我就打电话，那边打电话查询你花了多少钱，每一笔是多少钱，合成美金是多少钱，然后告诉我需要到网上查，在中国银行事实上它不同的客户渠道看到的客户信息是不一样的，毛新生这个人在中行不同的渠道那儿是个不同的人，就不是一个人。我就很不爽，我在这里所有的业务都在这个地方，怎么是不同的人，还得我做这个做那个，这是一个典型的情况，造成的IT每个渠道就是一个单独的系统，建立的模型不一样，处理的过程也是不一样的。我在招行有一张卡，这些问题就可以解决。
信息看起来不是那么容易，我们要把这个信息自由地在整个企业范围内流动，让我们的员工在需要得到信息的时候就可以得到，就是信息唾手可得。谈论这个问题引出的一个结论，我们今天是一个强调速度的时代，有越来越快的变化，有越来越多的变化，这些东西还要变得正确，我们要做一个正确的变化，来使得我们的业务能够持续地去创新，在业务上、在市场上能够获得一个很好的业务结果。做到这一点，大家都希望企业的IT信息系统能够帮这个忙，但是这个好象不是那么令人满意。首先，看看企业的企业架构就有点问题，结构非常乱，而且也非常复杂，我们做一些项目周期很长，在某个地方做一些小的改动，将一些系统连接起来，花的代价都非常大。非常有趣的是，在过去两年多来，我在亚洲所有国家的客户那儿，我跟客户要整个架构，每个几个企业不能够给出来，这是普遍的情况，韩国、日本、东南亚一些国家都是这样，拿不出整个企业范围内的整体企业架构，如果要拿出来，画出来的东西就是这个样（见图）。从花钱的角度来讲，整个IT现在花的钱，每年拿到的预算超过70%的钱都是用在IT的维护方面，IT运营当中出的一些问题的解决方面，而不是用来开发新的系统，或者是加强已有的系统来满足我们客户的需求，这样一个状况也非常的普遍，比如我们在上海的中国远洋集团，他们的情况就是这样，他们EDI系统大概有十来个人做工作，差不多八九个人解决各种各样的问题，一会儿三星来一个抱怨说我这个海关报关怎么没有做，有什么问题，一会儿又是沃尔玛来一个电脑，弄得他们天天加班还很不高兴。IT部门一直处于不太好的状况，非常努力地做事情，可是业务部门经常在质问IT部门你们花了我们很多钱，你们能不能做得更加快一点，做这些事情花的钱更少一些，然后做的事情出问题少一些，质量更加高一些。甚至说在几年前华尔街有一个分析师说IT已经不重要了，这个东西没有办法说，用IT的东西就让我获得战略性的优势，这就需要IT去思考，我们该做什么样不同的事情，或者我们换一种不同的做法，来使得我们重新回到十多年前沃尔玛有一个小小的零售链，利用IT、利用整合扩展的价值链上的供应链管理系统，从而使得它逐渐从一个美国偏僻地方的小仓库逐步发展到今天全球零售业的老大，在它的号令之下，无数的垂直的价值链听命于他，他给你一分钱的利润就是一分钱的利润，这是IT所成就的。到今天，沃尔玛的IT系统依然是非常具有特色。
我们IT需做些什么东西改变安全状况，改变IT企业架构的混乱，大家非常努力做事情，还是非常委屈地受业务部门的抱怨。事实上它意味着我们构建软件的新的趋势和要求，这就需要我们认真想。首先我们来看看过去的IT系统，过去的IT系统无论是美国，美国大概有四十多年的IT建设的历史，其他的国家有三十多年，如果要看中国大陆，应该是十几年的IT建设的历史，这么多年的建设历史，实际上过去我们都是这样一种哲学来做的，就是由部门驱动的，我们过去的业务模式也是这个样子。一个部门提高效率，就能够在市场上单打独斗，就可以生存下去，还可以赚到很多钱，现在IT环境比过去复杂的多。我们需要从过去以部门为导向开始转移到企业内部各个部门要努力去很好的相互协作，非常动态的，根据外面客户的要求动态的协作。而且我们还要想办法把自己不太擅长的东西交给我们的合作伙伴去做，在一个动态的价值链上怎么样去利用别人的能力，大家以一个双赢的心态、双赢的合作来为我们的客户提供最有竞争能力、最适应、最让他觉得值得的、需要的服务，这样就导致我们的业务模式发生一个很大的变化，放在整个全球化的状况之下，其实每一个企业、每一个行业都面临这样一个状况。
比如前不久我参加了一个汽车IT论坛，大家都在说现在中国要怎么样利用我们的自有优势，参与到全球汽车的零部件采购当中去，我要在这个价值体系当中来发挥我的优势，赚到我的钱，这对他意味着什么？意味着他的业务模式转移成这种方式，而不是过去那种方式。这种业务上的变化，对IT意味着非常非常多的东西，我们可以看到在过去我们IT系统建设的原则就是我们以一个部门为导向、为中心，提出它的业务需求，然后我们给它建造一个系统，这个系统完成这个部门所需要的东西，我们看到不同的部门在做自己的事情，在过去若干年当中建立了一堆系统，但是很不幸的是，每一个部门其实建这些系统的时候他们的哲学都不太一样，请的人也不太一样。由于在不同的时间点上建的这些系统，因为IT的技术都是逐步发展的，所以他们使用的技术也不太一样，从而使这个整个企业范围内的系统不仅仅是一个孤岛，大家没有连在一起，大家对数据的看法，大家对业务逻辑的看法、对技术方面的看法不太一样之外，还有一个非常有趣的问题，就是整个这些高度异构、高度分布、高度异制系统的就像一个破碎的系统，这种做CE的方式，业务上这种变化并不是一天一夜发生的，它是逐渐发生的，很多企业的IT系统建设也反映了这样一个业务模式的变化过程，也就是说在过去我们力图在采用一些私有的或者是业界比较那么不通用的方式做了很多的阐释，就是我们过去一直做的企业应用整合。我们采用各种各样的方法，有的人有文件共享的目录，有的用STP，有的用RPC，有的人做得好一点会提供数据总线，采用类似于中心、辐射这种所谓集成范式，来形成有线的连接，大多是点对点的连接，这种集成到今天为止，因为其私有的技术，因其在探索过程当中形成整合的范式并不是最佳的做法，从而带来了相当多的问题，一方面是这种整合没有带来一种灵活性，缺乏这种灵活性，使得整个架构非常脆弱。也就是说我希望在某一个地方希望发生变化，这个变化将会沿着整个集成的架构扩散到很多跟它打交道的地方去，从而使得一个小小的变化需要非常大的变化才能将这个变化所满足。
另外一个问题，相当多的点到点的连接，使得系统当中的逻辑和系统要重用的时候，付出的代价是相当高的。不管我们过去做了多少，我们还是在一个非常技术、非常细节性的层面看待IT系统，在IT系统里面表现出来的是对象、过程等等东西它们富有的只是技术的含义，我们为了表达非常业务模型的东西，比如业务的过程、业务的活动、业务的流程，我们是用代码将它们拼起来的，从而使得这样硬编码的方式改起来相当难受。为了配合这样一个普遍的业务模式，我们需要我们IT做些什么，首先我们需要从部门导向这样一种方式逐渐开始转移到在整个企业范围内的整体规划着手的方式来转移。这样一个转移最重要的目标为了确保我们的移动逻辑和数据的资源确实是能够共享的，因为要共享首先意味着他们在讲同样的话，在采用同样的标准、指导原则等等，而不是说你做你的，我做我的。这背后意味着你的IT管控能力，意味着你整个企业范围内应该有架构师的委员会，甚至通过你的高管所形成的推进委员会，由他们在决策层面、在战略层面和技术执行层面制定种种规范，使得整个企业范围内每个解决方案的执行都应该有整个企业范围内考虑的参考架构以及相关的设计原则等等。从而保证你的数据模型、你的业务逻辑等等具有一致性，这种一致性是最后在实现级别，大家能够相互共享最重要的基础。
其次，我们开始要从过去比较私有的或者是局限于某一个提供商的技术和方法，逐渐地转向到一种开放的、通用的标准所基于的运行环境、开发方法、工具等等，并且要确保所有的系统都能够非常自由地、通用的方式整合在一起。通过这样一个方式，我们还需要整个系统能够去限制这样一个变化，也就是说当某一个地方发生一个变化的时候，我们要让这个变化只是局限在这个地方，而不会扩散到企业的其他系统当中去，我们称之为防止企业架构的脆弱性。我们终于要将IT系统从简单的技术元素要上升到业务的元素，也就是说我们需要将业务活动、业务的流程，以及相关的评价的性能指标等等，作为一个直接的元素开始为它建模，实现它，然后把它部署在系统里运行它，然后要管理、监控它。这个东西就不同于我们过去用代码的级别，我们需要有清楚的语义描述，在这样的基础之上，这些东西对业务人员来说变得非常直观和自然，而且具有完整的业务理念，当你对这些东西进行建模的时候，跟业务人员沟通就有很好的基础，当我们将这样级别的东西是现在IT系统并且管理的时候，我们直接自然地支持业务活动和业务流程的管理。通过这样一种实现，我们期望着直接是现在IT业务系统的元素都是可以用的，而且可以用它在不同情况下组装，来满足业务模型本身的变化。这样一个变化就是我们所谈论的业务创新所带来的。为了要做到这件事情，实际上有若干个关键问题需要回答，这几个关键的问题是SOA所期望去回答的。
第一个问题，我们开始要动身为这个业务本身来建模，我们要将业务流程表述为一系列业务活动，而且我们要将那些可重复的业务活动标识出来、定义出来，描述清楚，我们称它为所谓的业务服务。我们通过这样一个方式期望有一种方法使得我们将业务模型变成一个非常灵活的模型，在这样一个模型当中，当业务发生变化的时候，实质上主要是用来将那些可重复的业务活动，也就是所谓的业务服务进行不同的组装，形成你新的业务活动。这样一种重新的组装可能包括了业务服务的插入到已有的业务活动和业务流程当中去，或者去掉某一个业务服务，或者是这些业务服务之间的组装顺序进行调整，或者是某一个同一语义的业务服务的替代，这个替代是插入、顺序的调整，大家都是如此自然。后来同一语义服务的替代，比如我们帮华为做的那个事情，华为在欧洲有很多提供商帮他运交换机，这是当地很多服务的提供商帮他提供的服务，华为不能绑死在一个人身上，在这个地方等于有若干个人，我们只需要根据提供的业务服务，根据SOA服务级别的数据来调整，谁的成本低，谁的响应快，我们根据客户的需求，根据业务的规则去选择适合我们不同的服务提供商，这样我们业务模型非常清楚，这个地方根据业务规则去动态调整，使得我们业务变得非常灵活。
我们要做业务模型，这件事情是我们过去做得非常少的，我在过去这几年里为客户做事情的时候，客户说给你业务用意就好了，没有这些事情了，说明我们的业务人员实际上他的脑袋里面没有想我应该对我自己的业务有一个非常清楚的认识和定义，我要把它变成一个非常清楚的结构，通过对这个结构的分析，对这个结构当中每一个要素也就是业务活动或者业务服务去进行分析，去看它每一个活动应该要满足什么样的要求，评价的指标，它会有一定的开销，时间上的开销或者是成本上的开销，它会带来一定收益。所有这些东西怎么样跟我整体业务谈论的利润问题、成本结构问题，以及我哪一部分应该外包给别人，哪一部分应该自己留下来，哪一部分应该作为核心部分留下来，我的业务人员在这个地方没有清晰，大部分客户都说我给你一个业务用意，他看到的是操作的层面，甚至这个业务人员上来跟你讲做这个做那个，这离灵活的业务模型太遥远了，没有这样一个灵活的业务模型，不可能真正、很好地业务创新当中各种各样的调整。
第二个问题，是IT要做得事情，IT要非常能干地支持这样的业务建模，要做这件事情并不容易，要有一套方法和过程，帮助IT人员和业务人员坐下来一起，用业务人员的语言，用业务人员脑袋中比较自然的想法和描述，去一步一步地推导出来一个比较灵活的业务模型。第二件事，IT系统要有一系列的设施帮助我们对这些业务模型当中的各种要素以及要素之间的相互关系去进行描述，去进行建模，要能够有一系列的技术帮助构造部署运行和管理业务模型当中的内容。这就意味着IT从过去比较低级的技术模型转向高级的业务模型。第三件事，可追溯性，在业务和IT模型当中，在于整个SOA方法论当中最重要的事情，我们业务模型搞清楚了，IT也有这个能力去支持这样的东西，试问当我的业务模型发生变化的时候，我怎么样能够比较顺利地去使得这样一个变化传递到IT所实现的模型当中去。IT自身要满足怎么样在高度分布、异构的计算环境当中提供无缝的集成能力，在人、数据、应用和流程不同方面都要能够很好的支持集成。其次，整个架构需要采用过去所谓的最佳实践来使得我们的架构能够变得非常的柔性，这样一个有柔性的架构可以很好地支持IT系统自身可持续的演进，这样一种演进需要应付什么样的挑战，整个企业范围内事实上有很多的应用，你有可能增加一个应用，可能减少一个应用，某一个应用技术因为太老了需要淘汰，我很多的应用需要打个补丁，所有这些东西不能因为我要做新的做法来约束这些行为，这些问题没有办法避免。像过去一样，我们在很多客户看到打补丁是最常见的做法，我们有一个新的业务需求来了，我要把已有的系统做拷贝，然后改写代码，怕它影响中间的数据库，在中间建立一个运作时的数据库，然后进行拷贝等等，这样的事情我们在某种程度上因为局限于现有的IT环境，我们还是没有办法避免这样的事情，我们也不应该过多地去限制它在已有的应用上去做调整，或者增加减少这些应用，这些东西都是非常必要的，因为部门级的东西我们还需要很好的支持。
最关键的是我们需要避免的是这样一些演进、这样一些演变、这样一些改变不至于使得我们所实现的业务模型受到冲击，要做到这一点，最关键的两件事情，一个我们要做到技术实现的独立性，所谓技术实现的独立性，是指某一个IT系统指支持了哪些业务活动，支持了哪些业务模型当中的业务要素、业务服务，只要他的业务语义不变，只要它的接口不变，你今天用J2EE做，你今天是用主机做，我们需要帮忙做到这些事情，就使得你拥有了一个很好的手段，这个架构提供了一个很好的柔性，使得你可以根据你自己的人员、根据你自己的钱的问题，根据你自己的时间上方方面面综合考虑，我怎么样去调整我现有的应用系统，使得你拥有很大的灵活性。其次要做到位置透明性，也是进一步地给你带来灵活性，位置透明性有几种情况，一是我要在动态的价值链上去工作，我们希望服务本身、业务流程不应该假定这个服务就在哪里，或者在这个应用，或者在那个应用，我们是根据业务规则动态看它在这里，在那里，只要是业务的语义，只要是业务的接口是一样的，就好了。另外一个可能性，你要调整应用的时候，需要这种位置透明性，举个例子，比如我现在帮一个银行做事情，他们在主机有非常多的核心业务，实际上对银行来说绝大部分的核心应用都是在3900，或者类似于主机系统上面来做，这些主机上所做得事情通常来讲现在由于主机的技能越来越少，他们会面临非常大的压力。现在有一些小银行希望把主机上的东西开始转移到J2EE，要做这件事情没有办法一下子把主机上所有的事情都转移出来，我们需要一点一点转移，我们将原来的服务由主机实现，现在需要一个一个拿到开放的J2EE平台上来，这个时候位置透明性就可以帮助我们，使得你IT本身实现上的变化不至于影响业务上的模型。
有了IT方面的好处，从而就使得业务的部分和IT部分就有一个结合，使得业务模型的变化可以比较容易、顺畅达到IT系统，同时IT又拥有自己非常好的柔性，任意地去改变我实现的时候所用的技术、应用，从而使得IT方面自由演变不至于理想而影响高层的业务模型。我们要解决这几个关键的问题，我们有一个非常简单的哲学，在业务层面上，我们希望能够从建立起所有组建化的业务视图，通过这个业务视图，我们将我们的业务逐渐变成一个拥有非常清晰的结构，在这个清晰的结构里面，每一个业务部分都有非常清楚的范围，哪些东西是可重用的，这样我们得到一个业务模型，怎么样利用一套方法去将它预设到一个基于SOA的比较柔性的IT架构里面。我们来理解SOA，从业务的角度，什么是服务？服务就是那些可重复的业务活动。在这样一个视图之下，我们的服务开始逐渐地从过去不清楚的想法来看的方式开始转向以服务为中心的方式来看待你的业务。什么是以服务为中心，也就是我们通过服务来组装来实现你的业务，以及由此派生出来的各种各样的概念和技术。
什么是SOA？SOA就是以服务为中心，来组织IT系统当中的架构风格，它的通过松散耦合和隔离关注等设计原则实现架构灵活性，这种架构灵活性加上可以重用、可以组装的服务，可以使得你企业的IT系统在动态、不确定、变化的环境下可以自由持续地演进。我们还需要一些方法论来帮助达成业务视图的过渡，这样的方法论重要的是，我们需要解决业务和IT之间的结合，其次我们要解决IT和业务之间模型的可追溯性。
SOA作为所谓的新的软件构造方法要包含哪些关键要素，通常我们谈论的软件构造方法，在软件构造方法里，我们应该从这么几个方面来判断，首先我们拿到一个问题，应该有一套抽象的概念和手段来帮助你去思考你的问题域，然后去建模。这些抽象手段都是基本要素，比如我们过去为了解决一个问题，就是用一个过程，现在处理的问题越来越复杂，有一个对象帮助你建模，将一些数据封装在一起，它是一个类聚非常好的元素。慢慢我们开始将功能组合在一起，用来简化对我们问题域的视图，这样我们拥有一个管理复杂度的能力。你会持续地看到在过去我们构造一个问题域，我们怎么为这些问题域去建模，到今天我们为它增加了另外一个东西，那就是从业务的角度出发来考虑所谓的服务，这个服务本身有一个接口，并且有附着于这个接口的业务语义。其次，你有要有一套方法，怎么样将这些抽象元素很好地组织在一起，过去我们在OO里有所谓的设计模型，通过这样一些模型，有各种各样的模式，将这些基本的抽象元素组织在一起，这种组织本身其实背后所做的决定包含了很多设计方面的设计原则和设计的风格与理念，比如说我们希望这样的元素目的都是为了使得对象之间的变化或者是组件之间的变化相互之间存在很好的结耦，可以做各种各样的变化，但是我那个部分不会受到很多的影响，或者为了简化整个过程的复杂性。
这些很好的设计实践，就逐渐出来很多设计范式，将那些比较简单的、基本的抽象元素，按照一定的设计风格和理念组装在一起的方式方法，这个就是我们在CBD看到的很多设计方式，在SOA领域里，我们将会出现业务范式，在你业务流程里，有一个从得到订单以后怎么样得到钱，这些范式有一些主要的业务过程。
我们对我们的业务过程，对我们拿到的问题域，我们要解决的业务部门带来的问题，我们就有了一个逻辑上的东西，我们开始要考虑实践的细节，从而将它变成是一个物理上的架构，所以我们要考虑到部署模型，考虑到实践的细节。再往下到物理的运作环境，物理运作环境我们称之为计算环境，这个计算环境可以是J2EE，今天我们谈论的是以服务为中心的计算环境，所有这些活动都应该很有序地组织起来，让它发生，有很多人做不同的决策，不同的人有不同的活动，这些活动之间有相互协作的顺序，他们还要满足企业开发的要求，所以我们有开发的过程。所有这些东西跟IT上面的活动，跟业务的活动衔接在一起，我们怎么样跟业务有很好的配合。作为这样一个IT部门的活动，我们要为业务部门提供服务，所以你要满足整个公司的政策，比如ROI的问题等等。在SOA的角度来讲，其实是A、B、C、D的事情，我们有服务的计算环境，有以服务为中心的业务与相关的业务驱动业务模型，有以服务为中心的分析和设计模式，或者IBM在金融行业里也有相关的业务模型和范式。我们在韩国航空公司， 参考国际航空协会的过程，那些东西有很多范式在里面。面向以服务为中心的开发过程，我们非常强调敏捷开发过程，在IBM各个部分都有非常清晰的支持，从开发过程当中来讲，我们有RUP，XP，在运作环境中有SOA Foundation，在设计部分有业务组件模型，还有跨越这两部分的建模分析与设计、架构决策等等，有SOA的成熟度模型，服务建模与架构方法，参考架构，设计模型，行业SOA模型。与此同时，我们还提供了SOA的管控，是在IT监管模型之上，它主要是侧重从业务的驱动方式来定义我们的业务模型，然后实现到我们的IT系统里面，这些业务服务都是可重用的，大家都是共享的。为什么创建这个服务，别的部门应用这个服务，需要负担成本上的东西，出了问题，谁来负责，需要做改变的时候，谁来做改变，做这样的改变对我们业务模型意味着什么，做这个改变，对我们的利润、对我们的业务、对我们的用户满意度带来什么影响，所有这些东西需要有一个严谨的有业务人员介入，并且有IT人员支持的审查、批准的过程。这个过程还要跟原来的IT管控模型结合起来，使得我们SOA比较侧重在业务以及业务和IT互动这个层次上的决策，具体实施到IT所负责的完全底层的技术，以及日常运行的活动当中去。这样一个过程我们称之为SOA的管控，使得我们通过SOA的方法论所定义的业务模型以及这个业务模型在IT的世界里面实现之后，真正能够产生和带来价值的重要的依据和手段。
现在我们来看看IBM的SOA方法、技术和服务。我们今天非常简化地来讲这些，从SOA的实施步骤来讲，我们有五个大的步骤，第一步，应该看看自己的业务成熟度，一个非常详尽的问题集，我们大概有一千多个问题，到目前为止，我在韩国做过最复杂的是200多个问题，我们从不同的角度去问你的问题，从商务的角度，从技术架构，从应用的角度，从开发方法的角度等等，不同的角度，每一个角度都有很多的问题，我们会得到一个成熟度，你看看你处在哪个成熟度模型之上。第一个级别就是完全与部门驱动是一个个孤岛。第二个级别就是已经有一些点对点的整合，有一些传统的EI方式带来局部的整合。第三个级别，我们开始已经对某些应用做了所谓的组建化，也就是说我们根据业务的建模指导，将一个应用所实现的业务处理，以及相关的数据资源以一个业务服务的方式表达出来，使大家共享，实现IT灵活性和柔性。第四个级别，整个公司范围内所有的应用都已经陆陆续续地变成了以Web Server作为自己的拥有的资源。通过这些符合的应用，将原来不同的应用所实现的能力转化为更加复杂的业务服务拿出来。第六个级别，我们所有这样一些服务，如果从第一级别到第五级别，我们有可能还是存在一些服务之间是一些硬连接的方式，到了第六个级别，这些服务全部都是动态的绑定，这些服务帮助你在语义方面的选择，本身在企业范围内开始往外拓展，拓展到你的合作伙伴或者客户，这样形成一个动态虚拟的企业。
因此企业需要识别我们现在处在哪个级别？然后我们开始制定一个转型的路线，让我们怎么样从现有的状态转移到我们期望的目标状态，在这个方面来讲，比如方法论。第二个级别，我们开始需要用业务组件的方式，来帮助在业务这一部分帮你创建一个比较灵活的业务模型，我们在这一步非常需要业务人员的介入，大家一起来看怎么样子合理地将你的业务进行划分，划分完了之后，我们需要看哪些东西给你带来差异化的或者带来核心竞争能力，或者你不得不有的一些东西，哪些东西是给你在投资上会影响你的成本结构，哪些东西是属于你开始需要考虑在未来需要发生的，可能某些东西需要我们外部的人员来做，意味着在未来它有可能转移到我们的合作伙伴，有些东西可能需要内部挖掘更好的潜力，意味着不同的部门需要更好的协作，或者是有些部分现在做得太差。所有这一切其实都是我们从业务的角度来进行指导的。通过有一个业务模型之后，我们开始将高层的业务模型分解，利用我们服务建模、架构方法学，逐渐转向到向技术方面的模型转移。我们有相当多的步骤来帮助将一个高层的业务组件模型转化为比较细的业务组件模型，利用服务建模和架构设计方法去转化为一个服务模型，这个服务除了服务的列表，我们还需要看这些服务之间相互的组装的关系，以及服务相互之间的依赖关系，和我们怎么样去利用这些服务组装我们现有的业务流程，以及怎么样去在考虑我们前面分析的各种各样的变化，比如我们要把某个部分要进行合并，哪个部分要去除等等，在业务模型方面的变化，对单个的业务服务或者业务服务组装所形成的变化都需要在流程方面有很好的考虑。使得可能的变化以及长远可能发生的变化都能够被我们做出来的服务模型所覆盖。
其次我们要为每一个服务提供一个实现的决策，这个实现的决策包括两个层次，一个层次是这个服务是我们从外面买，因为外面有可能做了相关的服务，比如有些公司可能对于地图的服务不做了，还是我们自己建，我们自己建开始要牵扯到IP方面的决策，这样一个服务我们要建是用全新的系统来建，还是利用已有的系统，如果利用已有的系统，我怎么样重用已有的系统，我怎么样用一个设施将已有的系统连接起来，在这个基础上我们要考虑一些安全、性能等等方面的问题，可能我们还需要考虑数据的重新建模和重组的问题，因为有的时候我们有很多数据分布在不同的系统当中，它们格式不一样，它们业务语义不一样，我们要做这样一个服务，要做用到这些过程，我们要使用一些方法，要一些源数据，让这些联系起来。还有一些比较工程上的考虑，我们期望这些服务都是单独，都是相互独立的，也就是说每一个服务自身的存在并不依赖与另外一个服务而存在。这就意味着我们每一个服务在另一个服务看起来是无状态的，我们每一个服务发送一个请求到另外一个服务当中去，不需要顾及他现在是一个什么样的状态，这对于在服务当中的我们强调的灵活性和结耦能力是非常重要的。通过这个服务模型，通过前面的架构决策，开始逐渐地推进到组件模型，实现这些服务所需要各种各样的组件，就回到我们前面已经很熟悉的所谓基于组件开发的方法。
我们做完这些建模事情之后，我们逐渐将这些东西映射到参考架构上来，在做这些参考架构上我们面临着一系列的实现架构，这样以服务为中心的参考架构，我们用什么样的产品，为什么用这样的产品？我们建一个什么样的企业服务总线，建什么样的集成设施，为什么建这样的集成设施，还有安全的问题、性能的问题等等。我们来做各种各样的相关的架构决策，IBM有一个参考架构的模型，它考虑到方方面面，可以供大家参考使用。所有这一切我们应该有一个管控的组织，以及相关的流程，我想这个东西对于SOA在业务部分的价值是非常重要的，当然我们在国内实施的经验来看，要一步到位实施这些管控是相当困难的，所以需要我们在做项目的时候需要主动积极地跟业务部门互动，来争取业务部分的价值更多、更好的展示。IT技术方面，架构对技术的适应能力等等都是比较容易得到的。
IBM的建模方法，还有一些服务，我们有SOA相关的业务咨询服务，包括前面我们提到的成熟度评估等等，我们也有一些设计的服务，包括实施的服务。我们前面提到SOA Foundation系列产品，服务的整个生命周期，我怎么样根据你的业务去标识业务服务，怎么样创建，部署到系统里来，怎么样管理，在管理这些业务流程和业务服务基础之上，我们了解到我们的业务服务和业务流程有哪些地方需要优化，然后我们跟业务人员重新建模，所有这些我们都有很好的产品去支持。
从工具的角度来讲，我们前面提到了高层业务模型怎么样去转化到技术级别的模型，从技术级别模型转化到技术级别的转化模型，这样的过程是模型驱动，使得代码可追溯性，以及生产效率都有大幅度的提高。重要的是模型驱动的开发方法，能够将你各种各样的经验和所做的事情转化为可重用的资产，如果我们看过去在对象、在组件的级别，我们看到有非常多的设计范式，根据这些设计范式，可以在支持模型驱动的工具里，将这些流程具体化，具体化你自己可重用的资产。然后可以在业务层面来做这些事情。
我们在亚洲做了一些客户，我们有一些经验，这是一个实例，前面我们提到了一些做法，这个例子是中远集运的例子，有20多个，相互分立的，完成中远集运，基于文件的平面为基础的消息格式，来跟全球的港口它的重要合作伙伴，比如三星、沃尔玛，以及当地的政府、港口打交道等等这方面的业务流程。他们效率非常低，因为他们没有很好的集成在一起，当三星抱怨我的报告没有完成的时候，事实上他都不知道他相关的数据在哪里，这些数据也都没有一个明确的业务语义元素，他要处理这些问题，要找到这些问题，定义这些问题在哪里，去解决这些问题，要花很多的力气。最后用SOA的方式，得到他的业务组件，分析他的业务流程，出来他的业务模型。这个业务模型应用参考的架构实现起来，这在各个级别有很好的整合。假定你需要发生业务变化，这些业务变化有可能是我要增加一个新的港口，流程没有变化，这个非常容易，我们只需要重新部署一个新的业务实力就可以，如果新的港口、流程没有变化，但是需要支持的业务受到变化的时候，我们只是需要在企业服务的总线上做一些调整和处理，这个部分增加相关的处理就可以了（见图）。如果你的新的港口不需要支持，当流程上有一些变化的时候，我们只需要在流程的部分对于已有的信息或者是业务处理的服务做一个重新的组合就可以了。如果这个新港口又要支持信号的流程，又要支持新的报文，我们能够自由地以非常小的代价在高度重用的级别之上来满足我们新的业务需求，并且这些变化都是非常清楚的被局限在一个一个自己该有的地方，而不会进行扩散。
企业范围因为做了这个事情之后，他们开始考虑我怎么样以EDI为基础，建立整个企业范围的总线，怎么样将各种各样已有的系统把它们的业务处理和数据转化为可重用的服务，然后重用它整体的业务模型。
服务模型创建和架构设计中的经验分享，SOA的实施还是要以价值为导向，而不要盲从，不能过于技术驱动的方式，还应该看到SOA结合我实际要做得事情，看看在业务技术上给我带来一些什么样的好处，然后我们再来看SOA的设计原则，怎么样来做，我们要建设新的架构元素，比如ESB等等，会给我们带来什么样的附加的东西，比如我们整个架构会花很多钱。我们还要对变化有足够的重视，我们要在业务的级别，在技术实现的级别，对各种各样的可能变化用意拿过来，很好地去测度你的业务模型是否适合。我们在组织和流程成熟度都会影响到服务模型质量，假定你的业务流程今天和明天完全不是一回事，我想再怎么样做，这个业务模型本身以及将基本的要素组织成一个灵活的要素都是非常困难的和富有挑战的。所以我们在选择某个部分进行SOA实施的时候要有所侧重和考虑。我们非常希望强调业务人员能够有高度的参与度，已有的系统要去重用，并且将它们的能力转化为服务，实际上并不是那么轻松的事情，还是需要做很多事情，还是需要一个系统一个系统做一些事情，有相当多的系统，尤其是现在市面上比较流行的系统都已经有标准的适配器，这样大部分都能解决。做SOA，尤其是刚开始推动SOA其实非常需要整个企业范围内对SOA有好的认识，需要高层领导对SOA要了解，并且重视，我觉得国内各种各样的客户在IT管控方面都需要提升了。
我觉得性能的事情并不是一个问题，SOA并没有带来额外的性能问题。服务的包装有各种各样的方式。
影响SOA实施工程中工作量的因素，这取决于成熟度的要求，要求要达到什么样的级别，整个团队对于SOA相关的方法、技术产品掌握的程度，还有一个常识就是你现有的产品本身是不是够复杂，以及这种地域的分布或者业务流程、数据和技术环境的易用性怎么样，包括你的系统相当难以改造等等，这些都不会有影响。
主持人：把博大精深的SOA讲的这么细其实挺难的，大家会后再跟毛先生交流。