51ibm

标题: IBM软件技术开放日分会场二毛新生主讲CDL (2) [打印本页]

作者: 精英猛女 时间: 2006-7-6 13:34
标题: IBM软件技术开放日分会场二毛新生主讲CDL (2)
第一个问题，我们开始要动身为这个业务本身来建模，我们要将业务流程表述为一系列业务活动，而且我们要将那些可重复的业务活动标识出来、定义出来，描述清楚，我们称它为所谓的业务服务。我们通过这样一个方式期望有一种方法使得我们将业务模型变成一个非常灵活的模型，在这样一个模型当中，当业务发生变化的时候，实质上主要是用来将那些可重复的业务活动，也就是所谓的业务服务进行不同的组装，形成你新的业务活动。这样一种重新的组装可能包括了业务服务的插入到已有的业务活动和业务流程当中去，或者去掉某一个业务服务，或者是这些业务服务之间的组装顺序进行调整，或者是某一个同一语义的业务服务的替代，这个替代是插入、顺序的调整，大家都是如此自然。后来同一语义服务的替代，比如我们帮华为做的那个事情，华为在欧洲有很多提供商帮他运交换机，这是当地很多服务的提供商帮他提供的服务，华为不能绑死在一个人身上，在这个地方等于有若干个人，我们只需要根据提供的业务服务，根据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的世界里面实现之后，真正能够产生和带来价值的重要的依据和手段。

欢迎光临 51ibm (https://www.51ibm.com/)