SOA服务架构规划

本篇重点说明下SOA服务架构规划中服务目录规划集的形成。SOA服务架构规划不仅仅是基于SOA参考架构的思想，更多的是需要基于TOGAF和企业架构的思想来分析和构建完整的服务架构和服务目录库。

服务架构规划的重点有一项是形成完整的服务目录库，除了服务本身的多维度分层外，更加重点重要的还是识别出粗粒度和可重用的各类服务。SOA的核心思想就是要将企业的业务或信息系统划分为多个松耦合的组件，然后根据端到端流程的协同关系来识别和发现服务，即业务能力组件化和组件能力服务化；其次则是要基于云平台能力向云端集中化迁移的核心思路，来考虑整个IT应用架构中需要平台化的能力，同时将平台层能力以服务化的方式暴露出来。

在整个服务架构规划中也可以看到，对于主数据和共享数据的平台化建设，PaaS技术平台的建设，最终将识别和产生共享数据服务和平台技术服务。而对于从流程协同和业务架构分析入手，更多的产生业务服务；而对于从数据架构中的CRUD矩阵分析入手则产生数据服务。

下面再重点阐述下整个服务架构规划的核心逻辑和过程：

首先最重要的仍然是当前业务和IT现状调研，一开始不要陷入细节，而是应该从端到端业务流程分析入手，对于工程项目建设，供应链，研发生命周期管理，财务概预核决算，从客户提出产品或服务的需求到最终的能力交付，都可以看到有不少的端到端流程，这些端到端流程是入手的基础。通过端到端流程的梳理可以看到流程在多个业务部门和单位之间的协同，最终再将业务流程协同映射到跨多个业务系统或业务组件间的业务和数据协同。跨系统交互核心流程分析和梳理是识别组件或服务的关键一个步骤。

由于企业整个服务目录规划前期只会做到系统间协同和能力开放，因此分析到跨系统的端到端流程已经足够来分析和识别有价值的服务。基于由顶向下的思路我们不会马上落入到某一个业务活动，或者某一个业务系统中功能细节，而是分而治之，先将业务系统内部处理流程和逻辑看为黑盒，先分析清楚哪些能力是业务系统必须开放出去以实现跨系统流程交互的。

在跨系统流程交互中分析中，自然会分析到业务协同和交互过程中传递的业务对象，我们会进一步去分析这些业务对象映射的数据对象，通过单独数据对象的分析以方便我进行单纯的数据架构建模和数据CRUD分析，这个对于后续分析和识别数据分析是相当重要的。

其次，基于业务和IT调研的内容，我们会初步分析和构建当前企业的流程和业务架构，数据架构和应用架构，同时在业务架构中识别和分析相关的业务组件。如果仅仅是分析到系统间的话，那么最终的业务系统就是相关的业务组件，这跟我们识别和分析的粒度密切相关。

在这些都分析完成后，接着可以构建完整的企业业务系统间的集成架构视图，也可以理解为当前的系统间详细接口和集成情况。这个图梳理清楚后，基本系统间交互的接口全部梳理清楚，也清楚了系统间集成和交互关系。对于集成架构图的形成，一方面是采用第一步谈到跨系统流程分析和梳理中的接口交互，数据架构CRUD分析中的数据共享和交互；一方面是由底向上的分析当前系统间已有的历史接口情况，并对接口的业务场景和对应流程进行补充梳理，以形成完整的集成架构视图。

集成架构视图做好后，可以将前期分析的端到端流程执行情况，进一步在集成架构视图上进行交互模拟，以确保核心的接口交互和服务没有遗漏。特别要注意的是在前面我们重点分析的是端到端流程，但是很多不是端到端流程场景，例如只跨了两个业务系统的简单业务流程或协同，业务需要进一步考虑清楚，否则会出现较多的集成接口遗漏。

最后，我们需要基于集成架构视图情况，规划和梳理服务目录集，即按照服务的分层和分类来重新审视当前的系统间集成和能力共享。下面来看下几类典型服务的进一步服务识别和规划。

流程服务：注意端到端流程也是流程服务，但是该流程更加长，也很多对应到最终的流程编排和组合。因此需要从端到端流程中进一步找寻流程协作片段。这种流程片断最好是完全的自动化业务流，或者有较强的一致性和事务要求，这些都可以识别为流程服务。

业务服务：业务服务更多强调的是业务规则类服务，或者强调基于业务功能操作触发的单条数据操作类服务。业务服务将更加体现服务调用的实时性，和业务操作场景的绑定以及业务逻辑的体现。或者可以理解为对于业务流程中横向实时协同的服务都可以看做为业务服务。

数据服务：更多的是从数据CRUD分析中识别出来的服务，其中既包括了主数据，也包括了共享动态数据。一个服务如果更多是事后非实时的共享数据传递或数据查询，则更多的是数据服务。从这个层面来说业务服务和数据服务本身存在一些较难界定清楚的地方。也有一些方法是单独仅仅将主数据和共享数据中心提供出来的分析规划为数据服务，其它全部为业务服务。

服务全部识别清楚后，还需要进一步对服务进行归并去重，服务组合或拆分，服务关键属性的定义，以方便根据服务类型，服务技术分层，服务提供系统多层面来规划完整的服务目录库和服务视图。