看看阿里架构师是如何分析SOA的业务价值实现

作了SOA实施不少年，不得再也不来回顾SOA业务价值这个话题，SOA是一种商业模式，一种架构方法，一种方法论。而企业实施SOA真正的业务价值又体现 在哪里？有多少企业实施SOA后真正体现了业务价值？至少从最近几年SOA的实施效果来看，SOA要走到真正能体现业务价值的实现和实现业务敏捷性还有很 长的一段路要走。

在实施SOA的初期，不少时候都仅仅是EAI企业应用集成的一个延伸，包括SOA自己产品也仅仅是消息中间件的进一步发展。从这个层面上SOA很难发挥其真正的业务价值，而对于SOA的核心业务价值必定是体现可重用资产库的积累，业务敏捷方面的内容。

SOA自己是一种架构方法学，该方法学不是对已有的面向结构，面向对象方法的否认，而是一种延伸，这种延伸的重点即在于流程驱动IT，业务驱动架构，从端到端的流程到业务组件化和服务化，又从可重用的业务组件和服务来快速构建业务应用。

在SOA架构方法出来后，构建IT系统的时候咱们会更加关注业务流程梳理，业务架构和业务建模，这也是可以真正实现业务和技术解耦的基础，没有这层解耦就谈不上后续的快速服务组合和编排。而在整个方法里面，业务组件自己就占据了很重要的位置，业务组件提供业务能力，而业务能力自己又以服务的方式提供出来。这种架构方法必需要引入到系统内，从一个系统的构建之初就采用这种方法来构建应用，包括端到端流程的分析，业务建模和业务组件，服务组件和服务识别，跨组件的数据CRUD分析，组件间的服务交互等。

对于遗留系统的SOA化改造和集成，每每很难对已有历史系统进行全SOA化改造，只能对现有的系统集成接口进行SOA化服务改造，在这种思路下咱们很难真正的去分析和识别各个业务系统已有的业务组件和业务能力。也很难遵循咱们的从顶向下的端到端流程分析和建模的思路进行，这天然致使了业务组件和业务服务没法真正的有效识别，后续的服务编排和流程编排更难以真正落地。要知道BPEL服务编排的重点是业务服务，而不是数据接口和数据服务。

业务价值1-造成真正的服务资产库

能够讲造成真正可复用的服务目录和服务资产库是SOA实施的一个重要业务价值体现，SOA一直在强调服务的粒度和服务的可重用性，服务的每一次重用都是在下降IT系统建设和实施的成本。服务资产库正是将各个业务系统可重用的业务能力提取出来以服务的方式提供出来。

当咱们在构建新的业务系统的时候，咱们就优先考虑有哪些服务资产或能力能够借用，有哪些是咱们须要全新构建和开发的功能。能复用的服务和资产越多，咱们构建IT系统的成本和时间越短。

服务资产自己就是业务组件和业务能力，用户或新构建的业务系统并不会关注提供这个能力的业务系统(SOA自己谈的透明性)，这种服务自己就是粗粒度的，实现机制彻底黑盒的。SOA自己重点就在于提供这个服务目录，而不是自身去实现这个服务。若是SOA和云计算结合，那则才是既自身产生这个能力，也提供这个服务。

服务资产库即能力提供中心，而支撑这个能力提供中心的仍是各个已有的业务系统，是各个业务系统将可复用的能力抽取出来注册到了ESB企业服务总线上。为了更好的为ESB提供这种服务和能力，对各个业务系统的组件化和模块化开发要求天然就更高。

业务价值2-业务敏捷性和效率

业务流程或业务的变化能够经过BPEL服务编排调整快速适应，这是咱们谈SOA可以实现业务敏捷性的基础。可是这条路每每是任重道远。一个全新的业务功能实现彻底能够经过服务组合和编排，流程的编排来实现，这是咱们的指望，可是却至关有难度。

首先是咱们的服务资产库是否足够完备？这里面涉及到两个方面的问题，其一是业务服务的识别而不是单纯的数据服务，要知道数据服务很难真正用到服务的编排。其二是服务的识别过程自己是否从流程分析入手，识别出业务组件，再来分析流程驱动的组件间的交互，这样分析出来的服务才真正支持从底向上的组装。

其次要实现业务的快速构建，经过单纯的BPEL是远远不够的，在BPM业务流程管理，BPMN2.0推出来后，这个方面前进了一步。能够部分实现从业务流程建模到IT实现的平滑过渡。可是这里面又有一个关键问题，即规则引擎，这块作很差快速应用开发，流程编排和组装仅仅是泡影很难真正落地。接触了太多的快速开发平台，企业级应用不是简单的增删改查，若是规则没法剥离，没法复用，就谈不上复杂业务流程自己的复用。

打破业务系统的边界，解决烟囱式的竖井结构，不是单纯的服务集成，而是实现跨系统的流程集成。这个时候业务系统下沉为能力单元，浮在上面的是可组装和编排的流程和应用。孤立的业务系统的概念越强，业务敏捷性的推进就愈加困难。

如何落地实施的问题

对于落地的问题也是咱们考虑的比较多的一个问题，方法论再完美若是没法落地那么也仅仅是空中楼阁。而落地的过程自己又是一个整体规划和分布实施的过程，前期的基础打的越好后续越容易实施落地。对于具体的落地，主要考虑以下几方面内容：

1.流程驱动业务架构思路，跨业务部门和系统边界，进一步分析和识别业务服务。

2.整合已有的服务资产，造成可复用的服务资产库

3.弱化各个业务系统的概念，业务系统变化为业务能力单元，而服务能力又集成到ESB

4.抽取各个业务系统可复用部分，进一步下沉和集中化，造成企业内PAAS云平台

5.选择合适的新业务系统或业务功能，采用BPM等工具，借助已有服务能力构建应用

6.逐步迁移传统的业务功能和业务单元