本篇为杂谈，主要是帮助大家理清在企业架构咨询中如何更好的和云计算和SOA思想进行融合，具体有哪些融合的点，如何结合为一个整体。要知道对于传统的企业架构思路如果不做变革已经很难满足当前SOA和云计算的思想，满足真正的资源集中化，可复用，灵活应对业务的相关目标。
对于企业架构，SOA和云本身的内容，前面已经有很多文章谈到过了，再次不再单独的一一进行说明，重点是结合企业架构的规划分析思路，找寻具体的融合点和融合思路。
对于业务架构，再次强调其入手点是端到端的业务流程分析，首先是分析端到端流程，流程分解，然后是按照高内聚松耦合原则规划离散自治的业务组件。业务组件本身提供对外的粗粒度服务能力，这些服务能力能够更好的组合，组装或编排满足业务流程的需求。这本身就是SOA的思想，按照这种思想进行规划分析，顶层设计和建模，那么以后整个企业架构来说自然是基于SOA思想的。不从流程分析入手的业务架构很难真正说最终的业务架构如何去匹配端到端的业务流程。
在业务架构的分析中，我们同样要随时考虑到可复用的业务组件的抽取，可复用的业务功能的抽取，可复用的业务流程片段的抽取，复用的分析和抽取在业务建模阶段就需要考虑，而不是遗留到应用架构和技术架构阶段才去考虑。复用本身分业务和技术能力两方面的内容，业务能力层面的复用和业务建模阶段相关。
对于数据架构，再次强调核心不是数据分类和数据域的划分，整套的从概念模型到逻辑模型到物理模型的数据建模和分析方法。在云和SOA思想指导下我们需要关注两个东西，一个是核心的主数据和共享数据，一个是数据集成和交换。这是建设后续共享数据中心的一个基础，存在共享的SID数据中心并提供可共享的数据服务能力本身就可以理解为PaaS平台中一个核心的内容。没有SID库的分析和抽取，那么整个企业架构中的各个组件变成单纯的数据集成和交换，谈不上共享能力集中化和朝云平台的迁移。这个我们在规划中一定要注意这个问题。
数据架构在TOGAF里面是划入到了大的信息系统架构里面的，这个容易让我们产生误解。实际上数据架构本身是包括了业务和应用两个层面的内容的。数据域和概念模型时候可能偏业务，但是到了逻辑和物理模型的时候已经偏应用。这是一点。
其次，为何要将数据架构和业务架构一起分析，前面已经强调过很多次了，流程分析和业务架构中，最终的业务功能和活动本身就承载了业务对象和数据，这是数据分析和识别的一个基础。数据本身不是凭空来的，而是随着流程和业务产生的。
这个谈完后，我们需要在业务架构和数据架构完成的基础上去考虑服务架构的概念，在这里的服务架构更多的是偏业务层面的内容，根据前面的业务和数据架构分析和规划，已经基本清楚了具体涉及到的数据服务，业务服务和流程服务。完全可以规划出初步的服务架构和服务共享集成模式。在服务架构的规划中，涉及到服务的分层模型，高层的服务视图和服务目录集规划，服务和业务数据架构的映射关系分析等。
有了前面这些基础铺垫，到了应用架构的时候相当就比较容易点了，首先应用架构的总体架构思路是平台+应用的架构模式。这个平台包括了IaaS层基础设施平台，也包括了PaaS层平台。对于平台的核心是提供共享的资源和服务。对于IaaS层重点是提供共享的资源能力，对于PaaS重点是提供共享的业务服务，数据服务，技术服务能力。共享本身有包括了两种实现方式，一种是集中化建设后直接能力开发，一种是将其它组件的能力集成进来统一发布出去，这两种模式都属于共享的范畴。
对于IaaS层主要实现虚拟化资源池和弹性计算和存储，在这里不再去做过多的描述。在这里重点再谈下IaaS层上面的平台层规划。在前面讲共享和复用的时候已经谈到包括了业务和技术两个方面的内容，因此可以将平台理解为包括了业务平台和技术平台。业务平台提供业务能力开放，技术平台提供技术能力开放。
技术平台和业务平台本身定位要搞清楚，业务平台本身可以是依托构建在技术平台上面的，但是应用本身又既可以访问业务平台，也可以访问技术平台。举例来说，一个ESB平台产品是纯技术平台层面的内容，但是ESB上提供和接入了各种业务服务能力，即变成一个业务平台；一个标准的技术架构和框架是纯技术平台，但是基于这个技术平台我们扩展了各种公有的业务组件和共性基础业务能力，那么这个平台可以上升为一个业务平台。
在实际的企业架构规划中，也可以直接规划为一个大平台，即这个平台既需要提供业务能力，也需要提供技术能力。同时对于提供的业务能力包括了业务协同能力，共享数据能力，共享业务组件能力；技术能力包括了底层资源池能力，技术组件能力等。
在理清平台+应用的思路后，另外一个重点就是理清SOA构建应用的思路，核心再简单就是通过服务解耦业务和技术。平台层提供服务能力，应用需要基于平台层的服务能力去构建，流程需要基于服务的编排去考虑等。这是我们的目标，但是这种落地实施来说相当有难度，那么重点可以放在基本的组件化要求，共享的服务目录库创建上面。至少需要体现应用是调用了共享服务能力来构建的。
前面也强调过，在SOA思想下，彻底的打破业务系统的边界，将业务变成一个个独立的业务组件是一个很重要的目标。如果企业架构设计和规划中，还是按照传统的一个个纵向的业务系统去独立规划和建设，那么最终仍然是一个竖井式的烟囱应用。
对于IT基础设施架构和规划，TOGAF是放在技术架构里面来阐述，因此也可以将IaaS层规划放到技术架构里面来。将IaaS和PaaS纯技术平台的规划放到技术架构中来考虑。
对于企业架构，SOA和云本身的内容，前面已经有很多文章谈到过了，再次不再单独的一一进行说明，重点是结合企业架构的规划分析思路，找寻具体的融合点和融合思路。
对于业务架构，再次强调其入手点是端到端的业务流程分析，首先是分析端到端流程，流程分解，然后是按照高内聚松耦合原则规划离散自治的业务组件。业务组件本身提供对外的粗粒度服务能力，这些服务能力能够更好的组合，组装或编排满足业务流程的需求。这本身就是SOA的思想，按照这种思想进行规划分析，顶层设计和建模，那么以后整个企业架构来说自然是基于SOA思想的。不从流程分析入手的业务架构很难真正说最终的业务架构如何去匹配端到端的业务流程。
在业务架构的分析中，我们同样要随时考虑到可复用的业务组件的抽取，可复用的业务功能的抽取，可复用的业务流程片段的抽取，复用的分析和抽取在业务建模阶段就需要考虑，而不是遗留到应用架构和技术架构阶段才去考虑。复用本身分业务和技术能力两方面的内容，业务能力层面的复用和业务建模阶段相关。
对于数据架构，再次强调核心不是数据分类和数据域的划分，整套的从概念模型到逻辑模型到物理模型的数据建模和分析方法。在云和SOA思想指导下我们需要关注两个东西，一个是核心的主数据和共享数据，一个是数据集成和交换。这是建设后续共享数据中心的一个基础，存在共享的SID数据中心并提供可共享的数据服务能力本身就可以理解为PaaS平台中一个核心的内容。没有SID库的分析和抽取，那么整个企业架构中的各个组件变成单纯的数据集成和交换，谈不上共享能力集中化和朝云平台的迁移。这个我们在规划中一定要注意这个问题。
数据架构在TOGAF里面是划入到了大的信息系统架构里面的，这个容易让我们产生误解。实际上数据架构本身是包括了业务和应用两个层面的内容的。数据域和概念模型时候可能偏业务，但是到了逻辑和物理模型的时候已经偏应用。这是一点。
其次，为何要将数据架构和业务架构一起分析，前面已经强调过很多次了，流程分析和业务架构中，最终的业务功能和活动本身就承载了业务对象和数据，这是数据分析和识别的一个基础。数据本身不是凭空来的，而是随着流程和业务产生的。
这个谈完后，我们需要在业务架构和数据架构完成的基础上去考虑服务架构的概念，在这里的服务架构更多的是偏业务层面的内容，根据前面的业务和数据架构分析和规划，已经基本清楚了具体涉及到的数据服务，业务服务和流程服务。完全可以规划出初步的服务架构和服务共享集成模式。在服务架构的规划中，涉及到服务的分层模型，高层的服务视图和服务目录集规划，服务和业务数据架构的映射关系分析等。
有了前面这些基础铺垫，到了应用架构的时候相当就比较容易点了，首先应用架构的总体架构思路是平台+应用的架构模式。这个平台包括了IaaS层基础设施平台，也包括了PaaS层平台。对于平台的核心是提供共享的资源和服务。对于IaaS层重点是提供共享的资源能力，对于PaaS重点是提供共享的业务服务，数据服务，技术服务能力。共享本身有包括了两种实现方式，一种是集中化建设后直接能力开发，一种是将其它组件的能力集成进来统一发布出去，这两种模式都属于共享的范畴。
对于IaaS层主要实现虚拟化资源池和弹性计算和存储，在这里不再去做过多的描述。在这里重点再谈下IaaS层上面的平台层规划。在前面讲共享和复用的时候已经谈到包括了业务和技术两个方面的内容，因此可以将平台理解为包括了业务平台和技术平台。业务平台提供业务能力开放，技术平台提供技术能力开放。
技术平台和业务平台本身定位要搞清楚，业务平台本身可以是依托构建在技术平台上面的，但是应用本身又既可以访问业务平台，也可以访问技术平台。举例来说，一个ESB平台产品是纯技术平台层面的内容，但是ESB上提供和接入了各种业务服务能力，即变成一个业务平台；一个标准的技术架构和框架是纯技术平台，但是基于这个技术平台我们扩展了各种公有的业务组件和共性基础业务能力，那么这个平台可以上升为一个业务平台。
在实际的企业架构规划中，也可以直接规划为一个大平台，即这个平台既需要提供业务能力，也需要提供技术能力。同时对于提供的业务能力包括了业务协同能力，共享数据能力，共享业务组件能力；技术能力包括了底层资源池能力，技术组件能力等。
在理清平台+应用的思路后，另外一个重点就是理清SOA构建应用的思路，核心再简单就是通过服务解耦业务和技术。平台层提供服务能力，应用需要基于平台层的服务能力去构建，流程需要基于服务的编排去考虑等。这是我们的目标，但是这种落地实施来说相当有难度，那么重点可以放在基本的组件化要求，共享的服务目录库创建上面。至少需要体现应用是调用了共享服务能力来构建的。
前面也强调过，在SOA思想下，彻底的打破业务系统的边界，将业务变成一个个独立的业务组件是一个很重要的目标。如果企业架构设计和规划中，还是按照传统的一个个纵向的业务系统去独立规划和建设，那么最终仍然是一个竖井式的烟囱应用。
对于IT基础设施架构和规划，TOGAF是放在技术架构里面来阐述，因此也可以将IaaS层规划放到技术架构里面来。将IaaS和PaaS纯技术平台的规划放到技术架构中来考虑。
