谈企业架构和SOA的融合

本篇讲主要强调下在常规的企业架构规划和顶层设计中与SOA规划设计之间的融合。

再次强调下SOA的核心思想是解耦，在首先满足解耦的要求下实现共享，协同和复用。一个完整的业务系统被拆分了应用，服务和资源层能力三个方面的内容。资源层的能力最终以粗粒度的服务方式暴露出来，应用的构建需要大部分的借助于共享服务层抽取和接入的各种服务能力。对于传统的企业架构规划和SOA规划思想的融合，在这里也只谈一些关键点和上下游衔接。

首先谈下业务架构的设计必须是以端到端流程驱动入手，通过逐层的流程分解最终确定各种业务活动单元，各个业务活动单元按照高内聚松耦合的指导原则（各种类似CRUD的矩阵分析方法）来确定大的业务域和业务组件。前面很多文章都谈到了业务组件化和组件能力化是一个核心，那么初步的业务架构和业务组件规划完成后，接着又一个重要的事情即组件向外暴露的能力服务如何识别？在这里需要在业务架构层面增加一个跨业务域或业务组件的组件交互或协同分析，分析在完成一个端到端流程的时候这些业务组件应该如何交付，那么这些具体的交互点将成为潜在的服务识别点。

在业务架构完成后进行数据架构规划和设计，而数据架构规划中的一个重点即是SID共享数据，其中包括了主数据和共享动态数据，在这里仍然是通过各种功能和数据的矩阵分析方法来找到相应的SID共享数据。当然在业务流程建模和分析中，可以看到有两类数据，一种是衔接某个业务活动输入和输出的数据，一种是该业务活动需要依托的底层数据，往往业务活动依托的底层数据很多都可以分析纳入到SID共享数据中。对于数据架构规划和分析中要注意到，最终是识别和形成各种数据服务能力提供。

在前面谈企业架构和云计算的融合中已经讲到了，在进行应用架构和技术架构分析的时候，需要考虑平台层云化能力的抽取，包括了IaaS平台和PaaS平台。其中对于PaaS平台层则需要考虑各种共性的技术组件和组件化服务能力的抽取，形成各种技术服务。

在上面几个部分都完成后，结合在应用架构规划中的应用集成架构规划和进一步分析，可以进一步分析和识别服务，形成完整的服务架构和服务目录。服务架构是在企业架构规划中必须增加的一个内容，这也将直接影响到我们应用架构的构建转化为资源+服务+应用的模式。服务在里面起到关键的解耦作用。

在基础的服务架构规划和服务目录库出来后，业务架构中的业务域可能已经转化为我们应用架构规划中的技术组件，数据组件和业务组件。这些已经是技术层面的概念，当然业务流程也进一步映射到系统层面需要实现的系统流程，那么就还得再做一次流程分析，分析在流程执行过程中需要调用到哪些业务组件或技术组件的服务能力，是否存在服务识别遗漏和缺失。这一步分析完成基本才能够保证前期分析和识别的服务是能够满足服务组装和流程编排的需要的。

我一直强调了SOA的实施包括了系统间层面和系统内层面，在本身IT建设成熟度不够的时候建议还是只考虑系统间的情况，而真正做的好的就是需要考虑系统内的全业务组件化和服务化。这样会直接导致我们的服务数量剧增，增加服务管控和治理的难度。

  青春就应该这样绽放   游戏测试：三国时期谁是你最好的兄弟！！   你不得不信的星座秘密