对于企业架构规划方法给人最大的一个思考就是将其和SOA，和云计算架构思想的融合，并理清四大架构之间的协同和集成关系。

企业架构规划思想概述

企业架构（Enterprise Architecture EA）是从企业全局的角度审视与信息化相关的业务、信息、技术和应用间的相互作用关系以及这种关系对企业业务流程和功能的影响。从这个定义至少可以看到重要的两点，其一是业务、信息、技术和应用的融合；其二是EA包括了业务和IT两个重要的方面，是从全局考虑业务和IT的集成。企业架构是一个多视图的体系结构，它由企业的业务架构、信息架构、应用架构和技术基础架构共同构成。

业务和IT的融合

IT规划涉及到咨询方法论、流程管理和分析、信息架构、应用系统分析和设计、技术架构、项目管理和实施等众多方面。从企业战略到业务目标，从业务目标到IT目标，从IT目标到应用蓝图，从应用蓝图到分阶段实施落地，任何一个步骤的脱节将导致规划内容无法落地。再完美的规划和架构，如果脱离企业业务目标，都不能带来企业业务价值的提升。

IT规划之难，不在于IT本身，而在于流程；不在于技术本身，而在于业务。

对于IT规划，遵循的思路主要是：从业务到技术，从流程到IT，围绕价值链分析和优化的核心模型驱动。

核心过程包括现状分析、差距分析、目标提出、蓝图规划、实施规划等几个关键步骤。现状分析包括业务现状和IT现状，根据企业战略提出业务目标和发展规划，分析现状和目标之间的差距提出和整理问题集（定义IT建设目标），根据差距和问题给出规划蓝图，根据目标和问题分解到的子目标和子问题以及蓝图规划内容，多维度评估和确定后续的实施规划，定义IT系统建设实施的优先级。这就是IT规划的一般逻辑。

从以上的描述可以看出，整个IT规划始终围绕业务和IT两条主线，业务包括了业务流程，业务数据，岗位组织和角色，业务管控体系；而IT包括了数据架构，应用架构体系，技术架构和平台，基础设施建设。业务驱动IT，端到端业务流程最终落地到应用系统的功能上，业务数据最终映射到数据模型并沉淀到数据库中。

随着各种思路的不断融合，IT规划核心指导思想应该转化为企业架构层面。企业架构的提出，主要是为了解决业务和IT“两层皮”的问题，企业架构的整个方法应该融入到整个IT规划思想中。此外，核心业务模型和业绩标准作为核心指导思想，虽然有裁剪，但是必须参考，如供应链SCOR模型，产品研发IPD方法论，项目管理PMBOK体系，战略和人力资源的平衡记分卡，CRM的4P和4C，财务域的核心模型等。针对不同行业可能又有不同行业的业务标准和模型，如电信行业的eTom模型等。

企业架构和SOA，云计算思想融合

与此同时，在前面基础上再融入云计算和SOA的核心思想，它将很好的解决我们多年前IT规划经验里的多个竖井式IT系统的集中化和协同化的问题。若现在规划仍走以前的老路是不妥当的。那么，今天规划重点在开始之初就应该考虑集中化和协同的问题，将SOA思想融入到IT规划当中。当今的信息化规划，要务必避免出现IT重复建设和信息孤岛，流程断点和业务无法协同的局面。

对于业务架构，其入手点是端到端的业务流程分析和流程分解，然后按照高内聚松耦合原则规划离散自治的业务组件。业务组件本身提供对外的粗粒度服务能力，这些服务能力能够更好地组合，组装或编排满足业务流程的需求。这恰恰就是SOA的核心思想，按此思想进行规划分析，顶层设计和建模，那么对于以后整个企业架构规划来说自然是基于SOA思想。不从流程分析入手的业务架构很难真正说它如何去匹配端到端的业务流程。

在业务架构的分析中，我们同样要随时考虑可复用的业务组件的抽取，可复用的业务功能的抽取，可复用的业务流程片段的抽取，复用的分析和抽取在业务建模阶段应当充分考虑，并不是遗留到应用架构和技术架构阶段。复用本身分业务和技术能力两方面，业务能力层面的复用和业务建模阶段相关。

对于数据架构，其核心不是数据分类和数据域的划分，而是从概念模型到逻辑模型到物理模型的数据建模和分析方法。在云和SOA思想指导下我们需要关注两个方面：一方面是核心主数据和共享数据，另一方面是数据集成和交换。这是建设企业整体共享数据中心的一个基础，存在共享的SID数据中心并提供可共享的数据服务能力本身就可以理解为PaaS平台中一个核心的内容。没有SID数据中心的分析和抽取，那么整个企业架构中的各个组件变成单纯的数据集成和交换，则谈不上共享能力集中化和服务能力云化。这个我们在规划中一定要注意这个问题。

数据架构本身是包括了业务和应用两个层面的内容。数据域和概念模型偏业务，而逻辑模型和物理模型偏应用。其次，为何要将数据架构和业务架构一起分析，核心原因是流程分析和业务架构中，最终的业务功能和活动本身承载了业务对象和数据，这是数据分析和识别的一个基础。数据本身不是凭空来的，而是随着流程和业务活动产生的。

理清以上内容后，我们需要在业务架构和数据架构基础上考虑服务架构，前面的业务和数据架构分析和规划，已基本清楚了具体涉及到的数据服务，业务服务和流程服务，这就可以规划出初步的服务架构和服务共享集成模式。在服务架构的规划中，涉及到服务的分层模型，高层的服务视图和服务目录集规划，服务和业务数据架构的映射关系等。

有了前面这些基础铺垫，在应用架构就相对比较容易了。

首先，应用架构的总体思路是“平台+应用”的架构模式。“平台”既包括IaaS层基础设施平台，也包括PaaS层平台。平台的核心是提供共享的资源和服务，对于IaaS层其重点是提供共享的资源能力，对于PaaS层其重点是提供共享的业务服务，数据服务，技术服务能力。共享本身有包括了两种实现方式，一种是集中化建设后直接能力开发，一种是将其它组件的能力集成进来统一发布出去，这两种模式都属于共享的范畴。

对于IaaS层主要实现虚拟化资源池、弹性计算和存储，而IaaS层之上的平台层规划包括了业务和技术两个方面的内容，因此可以将平台理解为包括了业务平台和技术平台。业务平台提供业务能力开放，技术平台提供技术能力开放。

业务平台和技术平台本身定位要搞清楚，业务平台本身可以是依托构建在技术平台上面的，但是应用本身又既可以访问业务平台，也可以访问技术平台。举例来说，一个ESB平台产品是纯技术平台层面的内容，但是ESB上提供和接入了各种业务服务能力，即变成一个业务平台；一个标准的技术架构和框架是纯技术平台，但是基于这个技术平台我们扩展了各种公有的业务组件和共性基础业务能力，那么这个平台可以上升为一个业务平台。

在实际的企业架构规划中，也可以直接规划为一个大平台，即这个平台既需要提供业务能力，也需要提供技术能力。同时对于提供的业务能力包括了业务协同能力，共享数据能力，共享业务组件能力；技术能力包括了底层资源池能力，技术组件能力等。

在理清平台+应用的思路后，另外一个重点就是理清SOA构建应用的思路，核心就是通过服务解耦业务和技术。平台层提供服务能力，应用需要基于平台层的服务能力去构建，流程需要基于服务的编排去考虑等。这是我们的目标，但是目标落地实施来说相当有难度，那么重点可以放在基本的组件化要求，共享的服务目录库创建。至少需要体现应用是调用了共享服务能力来构建的。

在SOA思想下，彻底打破业务系统的边界，将业务变成一个个独立的业务组件是一个很重要的目标。如果企业架构设计和规划中，还是按照传统的一个个纵向的业务系统去独立规划和建设，那么最终仍然是一个竖井式的烟囱应用。

对于IT基础设施架构和规划，TOGAF是放在技术架构里面来阐述，因此也可以将IaaS层规划放到技术架构里面来。将IaaS和PaaS纯技术平台的规划放到技术架构中考虑。

企业架构规划分析核心逻辑

在前面的分析中，IT规划所遵循的思路主要是：业务驱动IT，围绕价值链分析和优化的核心模型往前驱动。核心过程包括现状分析、差距分析、目标提出、蓝图规划、实施规划等几个关键。

在企业架构规划中，架构分析的入口点，我们认为合理的方式是从整体的端到端流程分析入手，细化到各业务域的端到端，经过不断的流程分解到3-4级流程，最终细化到最底层流程（如EPC流程，它是流程，本身也是业务功能）。另外的一个方式是直接从业务活动信息收集入手，如根据组织架构和岗位职责直接收集业务功能点。第一种方式既看到面又看到点，从上到下层层推进；而第二种方法则是容易只看到点，但无法贯彻整个企业端到端流程。当然，流程分析并不一定能够涵盖所有的业务功能点，因为有些业务功能本身便是最底层的EPC流程，往往并不是从高端的端到端流程分解而来.如用章管理是一个业务功能和EPC流程，但并不一定能够挂接到高端流程上面。这也是端到端流程分析要注意的点，高端流程分析和分解是建立全局思维，但是仍然要借助第二种方法收集完整的业务和活动。

流程到子流程，再到业务活动，业务活动中承载的是业务单据和业务实体。需要对业务实体进行抽离，进行数据层面的数据建模和分析。分析在流程各个阶段和活动中产生的业务实体之间的关联和依赖关系。业务域对应到数据域和数据分类，进一步可以分析到具体的概念模型或逻辑模型。流程分析偏业务操作和事件，而数据正是业务操作的对象。SOA中强调操作和数据解耦，则正好是分析的两个维度。

业务架构中的业务组件划分强调的是业务本身的高内聚和松耦合原则。对于任何一个业务域基本有两种类型，一种是数据驱动型，一种是工单任务型。如资源、资产等核心数据对象，业务操作层面重点是对数据对象实现全生命周期管理。因此业务组件划分基本遵循底层为基础数据支撑层，上层为生命周期管理层，覆盖该数据对象的核心生命周期阶段。这是业务组件划分的一个基本思路。

对于业务架构的构建，特别是我们对某个业务域并没有深入的理解前，最好的方式就是流程驱动分析，抽离数据进行数据建模，然后进行CRUD矩阵分析，分析数据和业务功能的关系。对底层的业务功能进行组合满足高内聚松耦合的原则，然后从底向上的对细粒度的业务功能进行组合，形成高内聚的业务组件。当然在整个过程中往往我们会参考业界标准的业务架构参考模型，如供应链的scor模型，电信行业的etom模型等。

业务架构完成后，将会过渡到应用架构，两者基本是对应的。其中较大的差别点在于业务架构只关注业务，业务本身分为功能性需求，非功能性需求。非功能性需要中包括了平台层面的支撑需求，即应用的集成支撑和数据的集成支撑，公共平台层功能等。另外还包括了纯技术层面的非功能性需求。对于前者需要体现到应用架构中我们往往会分为技术支撑平台和应用支撑平台，技术支撑平台包括了安全，管控等；而应用支撑包含了数据平台，集成平台和流程平台等。应用架构一般会分为支撑层，应用层和决策层。其中的应用层基本可以做到和业务架构一一映射。

服务架构需要考虑业务系统间的集成点。这个集成点的分析我们期望可以将端到端流程结合应用架构中的业务系统，CRUD矩阵分析形成跨业务系统的跨系统交互流程图。这种流程图已不是纯粹业务层面的流程图，而是做系统交互分析的跨系统交互流程图。所有的跨系统交互点则为流程驱动下的业务集成点。而CRUD矩阵分析则帮助我们分析出数据驱动的数据集成点。前者为业务服务为主，而后者即以数据服务为主。两者在分析完备后最终都体现到应用集成架构中。

业务中的平台级和非功能性需求转化到应用架构中的底层支撑层，对底层支撑层中的核心技术进行抽取，最终转化到一个完整的技术架构。技术架构和业务无关，它所提供的是底层技术支撑层能力。

技术架构逐步转化到公共的平台层，提供核心的资源池能力。业务组件本身转化为能力单元，业务组件由平台资源承载，提供业务服务能力。业务服务最终又可以通过灵活的配置形成完整的业务应用。因此我们所说的解耦不仅仅是业务组件间的横向解耦，还包括了业务组件到底层平台，业务组件到上层应用间的纵向解耦。

企业架构规划知识体系构图

在2010年在企业架构，IT规划和SOA方面有了比较多的积累，这些积累来源于项目实践。而我们说的积累一定是项目实践后的抽象总结，对于IT规划和架构知识库的整理是2010年的一个核心工作。对于企业架构中的核心内容流程架构，数据架构，应用架构，基础架构，包括底层的基础设施架构都进行了较系统的梳理，使IT规划和SOA规划的方法论根据完善。而对于SOA规划很多都需要依据IT规划和架构展开，结合SOA实施和治理的内容，完善SOA标准和规范体系。在技术方面，则进一步对规则引擎，CEP，EDA，MDM主数据管理等内容进行学习和总结；进一步梳理SOA，BI，云计算，MDM之间的关系和集成。

参考业界IT规划的参考模型和框架，结合IT规划方法论和实施经验，重新整理了IT规划知识体系。对于横轴主要考虑IT规划的方法论和步骤，具体包括了参考模型，调研阶段，差异分析和匹配，目标架构，实施策略和管控治理六个方面的内容；对于纵轴包括了IT基础设施，业务基础设施，业务流程，数据，技术体系，应用系统，集成架构七个方面的内容。

对于IT咨询的核心基础知识，重新做归纳的话应该包括企业信息化基础，项目管理，流程管理，软件工程这几个方面的基础内容。而其中流程和数据又是核心的核心。流程体现了动态分析的思路，数据体现了静态分析的思路。而分析工具和方法本身涉及内容更多，这些在标准的资料里面都能够找到，关键还是流程和数据，已经由两者提升和抽象后的维度分析。

再谈业务架构

要注意业务架构是一个完整的概念，是有多个架构文档，形式化的图形建模共同完成的。只要是企业内涉及到业务的方方面面，人，事，物，时间，环境等都可以在业务架构描述中找到详细的内容或者其它内容。业务架构不等同于流程架构，流程架构是业务架构的一个部分；业务架构不等同于业务建模，业务建模仅仅是形成业务架构的一种方法；采用形式化的方法清晰的描述清楚企业业务即业务架构要完成的事情。

业务架构的形式可以以价值链或端到端的流程分析为切入点，组织结构和岗位角色建模是业务架构的一个基础内容，在此基础上围绕流程和数据两条线相互交互融合而展开，流程涉及到子流程，业务活动和业务操作；数据涉及到数据域，数据主题和分类，具体数据的概念模型和逻辑模型等。或者可以简单地说为刚开始是基于价值链分析，端到端流程的高端流程建模；在流程分解到一定程度后进入到业务用例分析和建模，业务对象分析和建模。

在流程建模过程中，特别是到分解后的下级流程，仍然是推荐采用EPC事件流程链的方法进行建模。EPC流程图包含了流程活动，事件，岗位角色，业务对象等多个内容并形成一个整体。更加方面对企业内业务流程中的各个关联事物进行全面的理解。所以整个流程建模的思路可以是高端价值链-》传统的流程图-》EPC流程图。

在前面这些过程或活动中，可以形成大量的输出文档和目录清单，包括了流程清单，每个流程的详细活动描述清单（活动，输入，输出，业务对象，岗位角色），业务功能或活动清单，组织信息清单，岗位和角色信息清单，业务对象详细描述清单等。如果仅仅是端到端流程分析来输出，那么这个清单不完整，因为有些业务功能或活动不在端到端流程上面，比如一些业务部门的日常例行管理工作，监控工作，统计分析工作等。这也是业务架构不能单纯的从顶向下完成的原因，为了弥补这个问题，还需要的就是对于企业内的各个业务部门进行业务调研和访谈，了解各个业务部门的业务目标，各个业务岗位的业务职责和工作内容，进一步识别出不在端到端流程和流程分解节点上的内容。由顶向下+由底向上才可能形成一个完整的业务架构需要的内容。

如果仅仅是上述这些内容，那还不是一个完整的业务架构，在ARIS流程建模或TOGAF中都没有专门提到CBM组件化业务模型，这实际是基于SOA的思路做业务架构的一个很关键的内容。业务能力组件化和组件能力服务化。业务组件是企业内部一个高内聚的能够完成核心的一个业务价值的业务能力单元，这个业务组件将以业务服务的方式朝外部提供服务能力。因此各个业务组件之间本身就应该是高内聚，松耦合的。

一个业务组件可以是代表一个业务域，一个业务单元，一个紧耦合的多个业务流程或业务功能的集合，企业价值链或某个业务全生命周期的某一个阶段等。业务组件构成一个完整的业务架构模型，该业务架构模型本身也可以逐层展开和细化。业务架构本身分层，包括IBM的CBM模型的分法(决策，管理，执行层），也可以参考价值链的分层思路(支撑层，核心价值层，决策层）等，如上图示例。

在进行企业架构建模的时候，应该分为哪些大的业务组件，或者说哪些业务功能应该放在一个业务组件里面以保证组件之间能够高效协同是业务架构建模必须关注的问题。在业务架构建模的过程中，特别是对于目标业务架构完全可以参考企业所属于的行业的涉及到的标准模型进行重构和完善，如供应链的SCOR模型，电信行业的eTom模型等。我们在构造这个业务架构图的时候一直强调的就是高内聚松耦合的思路，符合业界的相关参考模型和标准，但是实际执行的时候究竟该遵循什么思路？

在这里一个可行的思路仍然是回归到矩阵分析，这里涉及到矩阵分析比较多，一个个的说明：

业务组件交互矩阵：在该矩阵上横向和竖向都是业务组件，在内容单元格里面是具体的业务交互接口点，通过这个交互矩阵分析是可以全局的看到当前的业务组件划分是否会导致大量的业务接口存在。并分析每个业务接口产生的原因，以进行组件的合并，业务组件中业务功能的转移等。(后续应用集成架构分析的输入)

数据和业务交互矩阵：在该矩阵图上，横向具体的业务组件和业务功能，纵向是具体的业务对象，在内部是具体的CRUD信息，也即是传统的CRUD矩阵分析。在该矩阵分析中的重点是，对于同一个业务对象，CUD操作尽量减少分离，而读操作则可以共享。以减少业务对象数据的多头管理和维护。将统一业务表单和数据的维护尽量控制在同一个业务组件中完成。减少数据间的交互和传递。

流程交互分析矩阵：在该矩阵上面横向是具体的流程信息，纵向是具体的流程活动信息，在这个矩阵图上可以看到同一个流程活动或流程片段往往存在于多个不同的流程。该分析的重要作用是对流程建模中可复用的流程片段或流程活动进行抽象和分析。(SOA服务建模时候需要)

功能业务组件分析矩阵：在该矩阵上横向是具体的业务组件或模块，纵向是具体的业务功能，在该交互分析上重点是分析具体的可复用的业务功能，以对可复用的业务功能进一步进行抽取，形成可复用的服务。(SOA服务建模时候需要)

本文作为TOGAF业务架构各个产出工件形成和交互关系的一个补充，具体TOGAF的业务架构建模很多仍然是停留在标准方法论基础上，而没有具体的操作性指南。反而是类似联邦企业架构FEA给出了一些可以更方便实践操作的方法和案例。

再谈数据架构

首先在TOGAF的ADM方法论中将数据架构部分的内容放在了信息系统架构-数据架构部分，这个方式是不合适的。前面一直强调了企业架构的两条重要线索，一个是流程，一个是数据，这两者都是既涉及到业务架构部分，也涉及到应用架构部分。在最终架构的分析和分解，业务建模到IT实现的转换过程中，自然就会过渡到应用架构部分的内容。

因此再次强调业务架构中也有数据架构部分的内容，只是业务架构中的数据架构的重点在数据域，高层的业务对象和概念模型，在业务架构的端到端流程分析和业务用例建模过程中自然会衍生出对应的业务数据对象和业务对象模型。

数据架构包括两个方面的内容，一个是静态部分的内容，一个是动态部分的内容。

对于静态部分的内容重点在于数据元模型，数据模型，包括主数据，共享动态数据和所有业务相关的业务对象数据的分析和建模。而动态部分的重点则是数据全生命周期的管控和治理。因此不能单纯地将数据架构理解为纯粹静态的数据模型。在业务架构中的数据模型分析重点是主数据和核心业务对象，而应用架构中的数据模型则进一步转换到逻辑模型和物理模型，直到最终的数据存储和分布。

数据分两个层面的生命周期，一个是单业务对象数据全生命周期，这个往往和流程建模中的单个工作流或审批流相关；一个是跨多个业务域数据对象的全生命周期，体现的是多个业务对象数据之间的转换和映射，这个往往是和端到端的业务流程BPM相关。在这里要注意的是，数据虽然是静态层面的内容，但是数据的生命周期或端到端的数据映射往往间接地反应了流程，这是很重要的一个内容。

数据建模的方法包括了面向结构的传统的ER模型分析方法，也包括了面向对象的对象类模型分析方法，两个方法都是可行的数据建模方法。只是传统的ER方法更容易实现向底层物理数据库模型的转换，而面向对象的类建模方法更加容易体现抽象和复用。特别是在企业架构建模中，面向对象和面向结构往往并不是严格区分的，很多时候都会出现两种方法混用的情况，但是重点是要区分每种方法或工具的重点以及解决的问题。

结合数据后相关的矩阵分析相当多，在业务架构阶段重点的矩阵分析是业务对象和业务流程，业务组件，业务功能间的类CRUD矩阵分析；而在应用架构阶段重点则会是逻辑或物理模型对象和具体的应用模块或应用功能间的矩阵分析。两者的思路基本类型，但是只是关注层面不同。前者的重点是主数据的识别和业务组件的分析，而后者的重点是应用功能模块的划分和模块间集成接口的初步分析。

对于数据集成分析根据前面的思路仍然应该分解为两个层面的内容，一个是业务层面的分析，一个是应用和IT实现层面的分析。前置的重点是理清业务流程或业务域之间的业务对象集成和交互，后者的重点是数据如何更好的共享或如果通过类似BI工具或ESB平台来实现数据的集成和交互。在TOGAF的信息系统架构-应用架构中特别要注意应该专门有一块内容来谈应用集成架构，解决的是业务系统和平台层技术组件间的技术集成，集成的实现方法，集成采用的工具技术等。

除了主数据之外，全局共享的动态数据分析仍然是数据模型分析的一个重点。或者说这个分析完成后基本可以找到整个企业端到端流程或某个业务域中的核心领域对象和领域模型。这个分析的重点是方便后续在实现层面进一步的构造通用共享的领域对象服务层，而不是纯粹的数据对象服务层。能够体现领域对象层延续前面讲的由业务-》应用-》集成的架构分析思路是相当重要的。

再谈应用架构

前面谈了业务架构和数据架构，接着谈下应用架构，对于应用架构的描述将参考TOGAF信息系统架构部分的内容，但是不完全相同，总体思路是围绕在IT架构层面来谈应用架构包括的内容。为了区分高层架构(包括多个应用的总体架构）和底层架构（针对单个业务系统的架构），前者采用企业架构中的应用架构这个词，后者采用系统架构这个词以进行区分。

首先说下应用架构中静态的部分，包括了应用功能架构和应用数据架构两个部分的内容，应用功能架构由业务架构中的业务组件架构转化过来，应用数据架构由业务架构中的业务对象数据架构或全局ER模型转化过来。中间会体现出映射关系。

对于应用功能架构可以比较明细的看到和业务架构之间的映射关系，但是要强调的是高层应用架构图中已经会明确地体现出了具体的业务系统，因此业务架构中的业务域业务组件和应用系统间往往不是一对一的关系，其中既存在合并也存在拆分，比如对于采购可能是独立的业务域或业务组件，但是在构建应用系统的时候可能是构建一个大的供应链系统；而财务是一个大的业务域，但是又可能拆分为报账，预算，成本管理等多个业务系统。这个一方面是结合企业实际情况，一方面仍然是考虑系统分解的颗粒度和耦合度。第二点应用架构和业务架构的不同体现在应用架构重点已经是在实现层面，需要实现业务架构朝IT架构层面的抽象和转化，最明细的就是底层可能会抽象相应的基础平台和技术平台，而上层或抽象相应的门户等，这些在业务架构中是绝对不会关心的内容。

业务架构阶段的数据架构重点是业务和领域对象，数据域的划分，主数据的分析和识别，重点是数据的概念模型。而到了应用架构则需要将业务对象转换为数据对象或具体的数据库表对象，应用架构的重点则已经是逻辑模型和物理模型。同时在应用架构阶段已经在分析数据对象和应用系统和应用功能之间的CRUD矩阵，以明确功能边界划分的合理性，以做到更好的系统划分和高内聚。

其次，在业务架构中有流程建模的动态建模部分，在业务架构中往往会从高端流程-》流程分解-》一直在具体的业务用例建模。而到了应用架构中要注意仍然存在动态建模部分，即业务用例-》系统用例-》用例实现，这个可以理解为应用架构中更加细化的动态建模，这个动态建模完全是实现层面的事情了，和本身应用系统的技术架构和分层也密切相关。但是这个过程却相当重要，特别是核心业务用例的用例实现，在这个动态建模过程中会分析和识别出一些细粒度的服务交互。在单个业务系统的架构设计中往往应用到类似序列图的方式来进行用例实现的交互，重心是在分层模型上面，而在应用架构中往往也用到序列图的交互，重心不是在分层上而是在不同的技术组件上的交互，这一点需要明确。

再次，应用架构设计中一个重要内容就是集成架构，集成架构包括了数据集成和业务集成两种，需要区别对待。数据集成架构重点是参考BI架构方式，而业务集成重点则是依照SOA参考架构模式进行。集成架构的分析可以在进行了业务系统划分后识别出业务系统之间所有核心的交互点和接口，作为数据集成或SOA服务的输入信息，也可以进一步对业务系统划分是否合理，是否满足松耦合的条件进行修正。集成和共享是两个层面的内容，集成往往数据落地，而共享往往数据不落地只是提供能力，当你在进行集成分析的时候发现了多点集成和交互的时候，往往都需要考虑能力抽取和下沉到平台，进行能力共享。如下图：

最后，应用架构中包括技术架构的内容，在这里分为多个方面的内容，首先是涉及到支撑企业内所有应用的技术平台层架构方面的内容；其次是整个应用架构中基于SOA参考架构的服务架构的内容；还有就是针对单个应用的类似java的ssh分层架构的内容，对于基础设施架构暂时先不纳入应用架构中的技术架构来考虑。

对于SOA组件化业务架构是对类似ssh分层技术架构的一个加强，而不是互斥的两个东西，再引入SOA参考架构会会进一步强调业务组件，服务组件和技术组件，强调服务能力的抽象，强调服务能力的共享，强调了各个组件之间真正意义上的松耦合，强调部分业务是可以通过服务组合和编排来实现的。

在应用架构的构建中我们引入了云平台和云化的思路，即各个应用系统不是简单的烟囱式的结构，而是从底层基础设施层面开始逐层向上考虑哪些是应用系统共享的技术能力，哪些是可以集中化建设和共享的，对于基础设施层则抽象到iaas层能力，对于技术平台层则抽象到paas层能力。由底层集中化建设的iaas+paas平台来支撑上层松散耦合的多个业务系统或应用模块，这是一种应用架构中体现云计算思路的重点。

应用架构和技术架构

在这里再谈下应用架构和技术架构的关系和边界问题。

首先再说下应用架构，应用架构是和业务架构有强烈的映射关系的一个架构，应用架构要说明的是整体企业内部信息化建设和规划应该分为哪些应用系统去建设，应用系统间的集成关系是如何的。就是我们常说的应用架构和应用集成架构。业务架构只关系核心的业务流程，业务域，业务组件识别出来即可，应用架构在业务架构的基础上多考虑两个事情。

一个是究竟如何来划分业务系统，业务系统和业务组件的划分颗粒度如何？如何满足划分后的业务系统间的高内聚松耦合；

第二个是在业务架构转换到应用架构去规划后续建设实施的时候，应该有哪些内容可复用的识别，将可复用的内容和资源共享的内容下沉到我们说的平台层，将业务系统间需要协同和整合分析的内容上升到我们常说的门户层和BI展示层。解决完这两个问题即完成业务系统朝应用架构的转化。

简单来讲应用架构中的所有点都是应该后续可以规划建设的应用系统或平台。企业后续需要建设一个安全管理平台，虽然和业务无关，但是应该体现在应用架构的PaaS平台层。企业整个应用建设需要考虑IT基础设施资源池虚拟化和整合，需要体现在应用架构的IaaS基础平台层。企业没有这种单独抽出来独立建设的规划，就不用体现到应用架构中，而该点仅仅变化为应用系统中建设需要考虑的一个技术点，直接在技术架构中解决。

我原来一直强调过在产品开发里面的一个重要思路，即分为产品，平台和技术三个层面的内容。如果和这个分类方法对应，则产品和平台都应该体现在应用架构总体框架中，平台本身又分了IaaS层平台和PaaS层平台。而技术则体现在技术架构这个概念里面。即我们谈到技术架构和产品架构，平台架构都是一种松耦合的关系。技术架构本身不能形成平台或产品，而是需要在应用建设，平台建设中考虑究竟需要使用哪些技术，如何使用。产品中需要使用平台，也还需要使用平台中未涵盖的额外技术，平台建设中也需要使用各自关键技术，这些都需要体现在技术架构中进行统一的规划和考虑。

应用架构本身只关心需要有哪些应用系统，哪些平台来满足业务目标的需求，而不会关系在整个构建过程中你需要使用哪些技术；技术架构是接应用架构的技术需求，并根据识别的技术需求，进行技术的选型，并把各关键技术和技术之间的关系描述清楚。大家可以关注下互联网上各自技术架构分享资料，你最多知道一个大的业务场景，其它内容全是采用了什么样的技术，什么样的开源组件，这些技术融合在一起解决了哪些问题。而实际的应用系统长什么样子，有哪些具体的功能点在技术架构中是完全看不到的。

再回来看技术架构，技术架构解决的问题包括了如何进行纯技术层面的分层，开发框架选择，语言选择，涉及到各自非功能性需求的技术点（安全，性能，日志，异常，缓存，消息，大数据量）等需要使用的关键技术。由于我们的应用架构体系本身是分层的，那自然有和其对应的技术架构体系，大的分层包括了SOA参考架构分层模型，小的分层则是单个应用的技术分层多层框架。这些都考虑清楚的剩下的问题就简单了，即根据实际的业务场景模拟来验证各个技术点间的协同，各技术点最终形成技术组件，各个技术组件间也需要高可靠集成。

注：按该思路，当前云原生解决方案整体技术平台，包括了微服务开发框架环境，DevOps过程能力支撑，容器云，微服务治理管控框架等都可以算做技术架构内容。

技术架构是对应用架构的一个完整支撑，应用架构和技术架构都描述清楚后还应该考虑和验证当前技术架构是否可以完整的支撑应用建设。应用架构是给技术架构输入具体的应用建设需求变转换为具体的技术需求点，各个技术点的分析，方案选型，最终形成关键技术清单，关键技术清单考虑应用架构本身的分层逻辑形成一个完整的技术架构图。对于IT基础设施架构我们常常将其纳入技术架构范畴，但是不是全部。对于单个应用系统建设的时候谈到应用本身的MVC模式分层框架更加仅仅是技术架构的一部分内容。

谈SOA和云计算架构设计的关键点

对于SOA和云架构设计方面的内容，前面已经有很多文章涉及到，在这里再重点谈下SOA和云架构设计和传统EA企业架构和单业务系统架构设计之间的一些区别和联系。

SOA和云架构设计更多的是在企业架构的应用架构和技术架构层面，然后才过渡到单个应用的架构设计约束，因此也可以理解为是传统软件架构设计更加上层的一个内容。SOA和云架构设计更加确切点来说应该是基于SOA和云计算思想的架构设计改进，而不是对面向对象架构设计思想的否定。

SOA思想强调的解耦，解耦思想最终落实到架构设计中是业务能力组件化，组件间的交互通过服务接口进行，粗粒度的服务本身就体现了松耦合，解耦不仅仅是组件的应用层，还包括了数据库和数据层都能够自成一套可以独立进行需求，设计，开发，测试和运维的全生命周期管理。另外为了最大限度的解耦，还需要借助消息中间件或服务总线，还需要考虑尽可能将同步服务转换为异步服务设计。

SOA思想强调的粗粒度，在架构设计中需要考虑的是不同的业务系统，组件或模块间只需要暴露需要暴露的服务能力而高内聚的屏蔽内部的数据和业务的复杂性。同时组件之间的交互要尽可能地减少传统意义上的数据库层的数据集成，数据集成和同步一方面是数据多点落地带来的数据实时性和一致性方面的问题，一方面是数据的集成同步导致大量组件内部逻辑外泄。同时尽量在架构设计过程中遵循领域设计和建模的思路，即在数据库上抽象领域对象层，以屏蔽底层数据模型细节。

SOA思想强调的可复用，在传统的架构设计中本身就有一个重要步骤即可复用的组件的抽取，可复用的组件朝外提供的服务能力自然也是可复用的服务，这是其一。传统架构设计中进行完模块和组件划分后，需要考虑组件之间的接口设计，那么在接口设计中需要考虑接口本身的服务化设计，接口本身的可复用性设计。对于底层技术组件或共享数据组件的可复用大家比较容易理解，而对于业务服务的可复用重点则在于可以复用到多个不同的业务场景或业务流程中服务的组合和组装。

SOA思想强调的服务本身的灵活组合和组装，这个内容往往偏EA架构设计层面的内容，即需要从端到端的业务流程层面来识别和分析服务。传统的架构设计往往关注的是一个个核心用例功能点，而服务组装编排关注的则是跨多个业务功能点的流程协同。提出这个的原因也正是，当我们在企业内规划和建设一个全新的系统时候，务必先考虑该系统在整个企业应用架构体系中的位置，该系统和其它业务系统间的横向纵向业务系统关系，然后再过渡到系统内架构设计。

对于单个系统，前面专门有文章谈过基于SOA的架构设计要点，这里再重点描述下即，单个系统能够组件化设计，组件之间能够做到从数据库到应用层相对独立，组件之间只能通过服务接口交互，这个重点解决了组件间的横向协同问题；其次，单个组件的设计建议的方法还是遵循领域建模的思路，最好是在原来的分层技术架构上，增加专门的服务层，即对于单个组件纵向来说也通过服务层来实现底层领域服务逻辑和上层界面展现和服务组装的分离。对于组件纵向可以采用传统API服务接口，而对于组件横向则采用WebService接口来实现进一步的解耦。

从以上分析来说，当我们谈到SOA架构设计的时候，不要一开始就被消息中间件，ESB服务总线等内容误导，如果没有充分地考虑SOA思想内涵并在传统的架构设计中引入SOA思想，那么即使采用了ESB服务总线最终也可能只起到了简单的接口平台的作用。

接着谈下云的思想，云思想的核心是终端能力朝云端的迁移，即集中化。SOA虽然强调了复用，但是这个复用可能还是在原来单个业务系统内部建设，然后再将服务能力共享出来，而云的思想更多的则考虑建设都不在传统的单个系统内部了，而应该集中化建设，能力集中提供，这个集中化提供的地方即平台。

基于这个思想需要注意到的就是对于传统的软件架构设计而言，由于关注的是单个业务系统，可复用的组件或能力还在系统内部，而到了云架构设计阶段，关注的是企业内整个应用和技术架构体系，因此这些可复用的内容从传统的系统内转化到了完全的系统外，这个是云架构设计思想下很重要的一个转变，即准备有了完全独立于系统外的可为多个业务系统提供服务能力的云平台。这个云平台不是简单的IaaS平台，而更多是PaaS层面的流程平台，数据平台，集成平台，技术平台等。

云思想强调无限伸缩，对应到架构设计中即可扩展性，对于传统的架构设计我们更加关注的是组件或接口本身的技术可扩展性，而比较少关注业务系统本身所对应的IT基础设施或平台本身的资源弹性伸缩扩展性，这个在架构设计中也是可以考虑引入的，包括各种分布式存储，分布式处理和计算，数据拆分，对PaaS资源托管平台的统一接入和适配等。

最后，在涉及到云架构设计的时候，需要考虑多租户设计，多租户设计和传统架构设计中的多组织设计还有些区别，租户往往有更加严格的资源隔离和资源流量控制要求，而不仅仅是数据访问上的隔离。还有就是在基于云架构设计中，需要重点考虑自服务模式，即围绕服务全生命周期的管控来考虑云的能力的服务化提供。

（以上内容摘自互联网，如有侵权请联系删除）

对于企业架构规划方法给人最大的一个思考就是将其和SOA，和云计算架构思想的融合，并理清四大架构之间的协同和集成关系。

企业架构规划思想概述

企业架构（Enterprise Architecture EA）是从企业全局的角度审视与信息化相关的业务、信息、技术和应用间的相互作用关系以及这种关系对企业业务流程和功能的影响。从这个定义至少可以看到重要的两点，其一是业务、信息、技术和应用的融合；其二是EA包括了业务和IT两个重要的方面，是从全局考虑业务和IT的集成。企业架构是一个多视图的体系结构，它由企业的业务架构、信息架构、应用架构和技术基础架构共同构成。

业务和IT的融合

IT规划涉及到咨询方法论、流程管理和分析、信息架构、应用系统分析和设计、技术架构、项目管理和实施等众多方面。从企业战略到业务目标，从业务目标到IT目标，从IT目标到应用蓝图，从应用蓝图到分阶段实施落地，任何一个步骤的脱节将导致规划内容无法落地。再完美的规划和架构，如果脱离企业业务目标，都不能带来企业业务价值的提升。

IT规划之难，不在于IT本身，而在于流程；不在于技术本身，而在于业务。

对于IT规划，遵循的思路主要是：从业务到技术，从流程到IT，围绕价值链分析和优化的核心模型驱动。

核心过程包括现状分析、差距分析、目标提出、蓝图规划、实施规划等几个关键步骤。现状分析包括业务现状和IT现状，根据企业战略提出业务目标和发展规划，分析现状和目标之间的差距提出和整理问题集（定义IT建设目标），根据差距和问题给出规划蓝图，根据目标和问题分解到的子目标和子问题以及蓝图规划内容，多维度评估和确定后续的实施规划，定义IT系统建设实施的优先级。这就是IT规划的一般逻辑。

从以上的描述可以看出，整个IT规划始终围绕业务和IT两条主线，业务包括了业务流程，业务数据，岗位组织和角色，业务管控体系；而IT包括了数据架构，应用架构体系，技术架构和平台，基础设施建设。业务驱动IT，端到端业务流程最终落地到应用系统的功能上，业务数据最终映射到数据模型并沉淀到数据库中。

随着各种思路的不断融合，IT规划核心指导思想应该转化为企业架构层面。企业架构的提出，主要是为了解决业务和IT“两层皮”的问题，企业架构的整个方法应该融入到整个IT规划思想中。此外，核心业务模型和业绩标准作为核心指导思想，虽然有裁剪，但是必须参考，如供应链SCOR模型，产品研发IPD方法论，项目管理PMBOK体系，战略和人力资源的平衡记分卡，CRM的4P和4C，财务域的核心模型等。针对不同行业可能又有不同行业的业务标准和模型，如电信行业的eTom模型等。

企业架构和SOA，云计算思想融合

与此同时，在前面基础上再融入云计算和SOA的核心思想，它将很好的解决我们多年前IT规划经验里的多个竖井式IT系统的集中化和协同化的问题。若现在规划仍走以前的老路是不妥当的。那么，今天规划重点在开始之初就应该考虑集中化和协同的问题，将SOA思想融入到IT规划当中。当今的信息化规划，要务必避免出现IT重复建设和信息孤岛，流程断点和业务无法协同的局面。

对于业务架构，其入手点是端到端的业务流程分析和流程分解，然后按照高内聚松耦合原则规划离散自治的业务组件。业务组件本身提供对外的粗粒度服务能力，这些服务能力能够更好地组合，组装或编排满足业务流程的需求。这恰恰就是SOA的核心思想，按此思想进行规划分析，顶层设计和建模，那么对于以后整个企业架构规划来说自然是基于SOA思想。不从流程分析入手的业务架构很难真正说它如何去匹配端到端的业务流程。

在业务架构的分析中，我们同样要随时考虑可复用的业务组件的抽取，可复用的业务功能的抽取，可复用的业务流程片段的抽取，复用的分析和抽取在业务建模阶段应当充分考虑，并不是遗留到应用架构和技术架构阶段。复用本身分业务和技术能力两方面，业务能力层面的复用和业务建模阶段相关。

对于数据架构，其核心不是数据分类和数据域的划分，而是从概念模型到逻辑模型到物理模型的数据建模和分析方法。在云和SOA思想指导下我们需要关注两个方面：一方面是核心主数据和共享数据，另一方面是数据集成和交换。这是建设企业整体共享数据中心的一个基础，存在共享的SID数据中心并提供可共享的数据服务能力本身就可以理解为PaaS平台中一个核心的内容。没有SID数据中心的分析和抽取，那么整个企业架构中的各个组件变成单纯的数据集成和交换，则谈不上共享能力集中化和服务能力云化。这个我们在规划中一定要注意这个问题。

数据架构本身是包括了业务和应用两个层面的内容。数据域和概念模型偏业务，而逻辑模型和物理模型偏应用。其次，为何要将数据架构和业务架构一起分析，核心原因是流程分析和业务架构中，最终的业务功能和活动本身承载了业务对象和数据，这是数据分析和识别的一个基础。数据本身不是凭空来的，而是随着流程和业务活动产生的。

理清以上内容后，我们需要在业务架构和数据架构基础上考虑服务架构，前面的业务和数据架构分析和规划，已基本清楚了具体涉及到的数据服务，业务服务和流程服务，这就可以规划出初步的服务架构和服务共享集成模式。在服务架构的规划中，涉及到服务的分层模型，高层的服务视图和服务目录集规划，服务和业务数据架构的映射关系等。

有了前面这些基础铺垫，在应用架构就相对比较容易了。

首先，应用架构的总体思路是“平台+应用”的架构模式。“平台”既包括IaaS层基础设施平台，也包括PaaS层平台。平台的核心是提供共享的资源和服务，对于IaaS层其重点是提供共享的资源能力，对于PaaS层其重点是提供共享的业务服务，数据服务，技术服务能力。共享本身有包括了两种实现方式，一种是集中化建设后直接能力开发，一种是将其它组件的能力集成进来统一发布出去，这两种模式都属于共享的范畴。

对于IaaS层主要实现虚拟化资源池、弹性计算和存储，而IaaS层之上的平台层规划包括了业务和技术两个方面的内容，因此可以将平台理解为包括了业务平台和技术平台。业务平台提供业务能力开放，技术平台提供技术能力开放。

业务平台和技术平台本身定位要搞清楚，业务平台本身可以是依托构建在技术平台上面的，但是应用本身又既可以访问业务平台，也可以访问技术平台。举例来说，一个ESB平台产品是纯技术平台层面的内容，但是ESB上提供和接入了各种业务服务能力，即变成一个业务平台；一个标准的技术架构和框架是纯技术平台，但是基于这个技术平台我们扩展了各种公有的业务组件和共性基础业务能力，那么这个平台可以上升为一个业务平台。

在实际的企业架构规划中，也可以直接规划为一个大平台，即这个平台既需要提供业务能力，也需要提供技术能力。同时对于提供的业务能力包括了业务协同能力，共享数据能力，共享业务组件能力；技术能力包括了底层资源池能力，技术组件能力等。

在理清平台+应用的思路后，另外一个重点就是理清SOA构建应用的思路，核心就是通过服务解耦业务和技术。平台层提供服务能力，应用需要基于平台层的服务能力去构建，流程需要基于服务的编排去考虑等。这是我们的目标，但是目标落地实施来说相当有难度，那么重点可以放在基本的组件化要求，共享的服务目录库创建。至少需要体现应用是调用了共享服务能力来构建的。

在SOA思想下，彻底打破业务系统的边界，将业务变成一个个独立的业务组件是一个很重要的目标。如果企业架构设计和规划中，还是按照传统的一个个纵向的业务系统去独立规划和建设，那么最终仍然是一个竖井式的烟囱应用。

对于IT基础设施架构和规划，TOGAF是放在技术架构里面来阐述，因此也可以将IaaS层规划放到技术架构里面来。将IaaS和PaaS纯技术平台的规划放到技术架构中考虑。

企业架构规划分析核心逻辑

在前面的分析中，IT规划所遵循的思路主要是：业务驱动IT，围绕价值链分析和优化的核心模型往前驱动。核心过程包括现状分析、差距分析、目标提出、蓝图规划、实施规划等几个关键。

在企业架构规划中，架构分析的入口点，我们认为合理的方式是从整体的端到端流程分析入手，细化到各业务域的端到端，经过不断的流程分解到3-4级流程，最终细化到最底层流程（如EPC流程，它是流程，本身也是业务功能）。另外的一个方式是直接从业务活动信息收集入手，如根据组织架构和岗位职责直接收集业务功能点。第一种方式既看到面又看到点，从上到下层层推进；而第二种方法则是容易只看到点，但无法贯彻整个企业端到端流程。当然，流程分析并不一定能够涵盖所有的业务功能点，因为有些业务功能本身便是最底层的EPC流程，往往并不是从高端的端到端流程分解而来.如用章管理是一个业务功能和EPC流程，但并不一定能够挂接到高端流程上面。这也是端到端流程分析要注意的点，高端流程分析和分解是建立全局思维，但是仍然要借助第二种方法收集完整的业务和活动。

流程到子流程，再到业务活动，业务活动中承载的是业务单据和业务实体。需要对业务实体进行抽离，进行数据层面的数据建模和分析。分析在流程各个阶段和活动中产生的业务实体之间的关联和依赖关系。业务域对应到数据域和数据分类，进一步可以分析到具体的概念模型或逻辑模型。流程分析偏业务操作和事件，而数据正是业务操作的对象。SOA中强调操作和数据解耦，则正好是分析的两个维度。

业务架构中的业务组件划分强调的是业务本身的高内聚和松耦合原则。对于任何一个业务域基本有两种类型，一种是数据驱动型，一种是工单任务型。如资源、资产等核心数据对象，业务操作层面重点是对数据对象实现全生命周期管理。因此业务组件划分基本遵循底层为基础数据支撑层，上层为生命周期管理层，覆盖该数据对象的核心生命周期阶段。这是业务组件划分的一个基本思路。

对于业务架构的构建，特别是我们对某个业务域并没有深入的理解前，最好的方式就是流程驱动分析，抽离数据进行数据建模，然后进行CRUD矩阵分析，分析数据和业务功能的关系。对底层的业务功能进行组合满足高内聚松耦合的原则，然后从底向上的对细粒度的业务功能进行组合，形成高内聚的业务组件。当然在整个过程中往往我们会参考业界标准的业务架构参考模型，如供应链的scor模型，电信行业的etom模型等。

业务架构完成后，将会过渡到应用架构，两者基本是对应的。其中较大的差别点在于业务架构只关注业务，业务本身分为功能性需求，非功能性需求。非功能性需要中包括了平台层面的支撑需求，即应用的集成支撑和数据的集成支撑，公共平台层功能等。另外还包括了纯技术层面的非功能性需求。对于前者需要体现到应用架构中我们往往会分为技术支撑平台和应用支撑平台，技术支撑平台包括了安全，管控等；而应用支撑包含了数据平台，集成平台和流程平台等。应用架构一般会分为支撑层，应用层和决策层。其中的应用层基本可以做到和业务架构一一映射。

服务架构需要考虑业务系统间的集成点。这个集成点的分析我们期望可以将端到端流程结合应用架构中的业务系统，CRUD矩阵分析形成跨业务系统的跨系统交互流程图。这种流程图已不是纯粹业务层面的流程图，而是做系统交互分析的跨系统交互流程图。所有的跨系统交互点则为流程驱动下的业务集成点。而CRUD矩阵分析则帮助我们分析出数据驱动的数据集成点。前者为业务服务为主，而后者即以数据服务为主。两者在分析完备后最终都体现到应用集成架构中。

业务中的平台级和非功能性需求转化到应用架构中的底层支撑层，对底层支撑层中的核心技术进行抽取，最终转化到一个完整的技术架构。技术架构和业务无关，它所提供的是底层技术支撑层能力。

技术架构逐步转化到公共的平台层，提供核心的资源池能力。业务组件本身转化为能力单元，业务组件由平台资源承载，提供业务服务能力。业务服务最终又可以通过灵活的配置形成完整的业务应用。因此我们所说的解耦不仅仅是业务组件间的横向解耦，还包括了业务组件到底层平台，业务组件到上层应用间的纵向解耦。

企业架构规划知识体系构图

在2010年在企业架构，IT规划和SOA方面有了比较多的积累，这些积累来源于项目实践。而我们说的积累一定是项目实践后的抽象总结，对于IT规划和架构知识库的整理是2010年的一个核心工作。对于企业架构中的核心内容流程架构，数据架构，应用架构，基础架构，包括底层的基础设施架构都进行了较系统的梳理，使IT规划和SOA规划的方法论根据完善。而对于SOA规划很多都需要依据IT规划和架构展开，结合SOA实施和治理的内容，完善SOA标准和规范体系。在技术方面，则进一步对规则引擎，CEP，EDA，MDM主数据管理等内容进行学习和总结；进一步梳理SOA，BI，云计算，MDM之间的关系和集成。

参考业界IT规划的参考模型和框架，结合IT规划方法论和实施经验，重新整理了IT规划知识体系。对于横轴主要考虑IT规划的方法论和步骤，具体包括了参考模型，调研阶段，差异分析和匹配，目标架构，实施策略和管控治理六个方面的内容；对于纵轴包括了IT基础设施，业务基础设施，业务流程，数据，技术体系，应用系统，集成架构七个方面的内容。

对于IT咨询的核心基础知识，重新做归纳的话应该包括企业信息化基础，项目管理，流程管理，软件工程这几个方面的基础内容。而其中流程和数据又是核心的核心。流程体现了动态分析的思路，数据体现了静态分析的思路。而分析工具和方法本身涉及内容更多，这些在标准的资料里面都能够找到，关键还是流程和数据，已经由两者提升和抽象后的维度分析。

再谈业务架构

要注意业务架构是一个完整的概念，是有多个架构文档，形式化的图形建模共同完成的。只要是企业内涉及到业务的方方面面，人，事，物，时间，环境等都可以在业务架构描述中找到详细的内容或者其它内容。业务架构不等同于流程架构，流程架构是业务架构的一个部分；业务架构不等同于业务建模，业务建模仅仅是形成业务架构的一种方法；采用形式化的方法清晰的描述清楚企业业务即业务架构要完成的事情。

业务架构的形式可以以价值链或端到端的流程分析为切入点，组织结构和岗位角色建模是业务架构的一个基础内容，在此基础上围绕流程和数据两条线相互交互融合而展开，流程涉及到子流程，业务活动和业务操作；数据涉及到数据域，数据主题和分类，具体数据的概念模型和逻辑模型等。或者可以简单地说为刚开始是基于价值链分析，端到端流程的高端流程建模；在流程分解到一定程度后进入到业务用例分析和建模，业务对象分析和建模。

在流程建模过程中，特别是到分解后的下级流程，仍然是推荐采用EPC事件流程链的方法进行建模。EPC流程图包含了流程活动，事件，岗位角色，业务对象等多个内容并形成一个整体。更加方面对企业内业务流程中的各个关联事物进行全面的理解。所以整个流程建模的思路可以是高端价值链-》传统的流程图-》EPC流程图。

在前面这些过程或活动中，可以形成大量的输出文档和目录清单，包括了流程清单，每个流程的详细活动描述清单（活动，输入，输出，业务对象，岗位角色），业务功能或活动清单，组织信息清单，岗位和角色信息清单，业务对象详细描述清单等。如果仅仅是端到端流程分析来输出，那么这个清单不完整，因为有些业务功能或活动不在端到端流程上面，比如一些业务部门的日常例行管理工作，监控工作，统计分析工作等。这也是业务架构不能单纯的从顶向下完成的原因，为了弥补这个问题，还需要的就是对于企业内的各个业务部门进行业务调研和访谈，了解各个业务部门的业务目标，各个业务岗位的业务职责和工作内容，进一步识别出不在端到端流程和流程分解节点上的内容。由顶向下+由底向上才可能形成一个完整的业务架构需要的内容。

如果仅仅是上述这些内容，那还不是一个完整的业务架构，在ARIS流程建模或TOGAF中都没有专门提到CBM组件化业务模型，这实际是基于SOA的思路做业务架构的一个很关键的内容。业务能力组件化和组件能力服务化。业务组件是企业内部一个高内聚的能够完成核心的一个业务价值的业务能力单元，这个业务组件将以业务服务的方式朝外部提供服务能力。因此各个业务组件之间本身就应该是高内聚，松耦合的。

一个业务组件可以是代表一个业务域，一个业务单元，一个紧耦合的多个业务流程或业务功能的集合，企业价值链或某个业务全生命周期的某一个阶段等。业务组件构成一个完整的业务架构模型，该业务架构模型本身也可以逐层展开和细化。业务架构本身分层，包括IBM的CBM模型的分法(决策，管理，执行层），也可以参考价值链的分层思路(支撑层，核心价值层，决策层）等，如上图示例。

在进行企业架构建模的时候，应该分为哪些大的业务组件，或者说哪些业务功能应该放在一个业务组件里面以保证组件之间能够高效协同是业务架构建模必须关注的问题。在业务架构建模的过程中，特别是对于目标业务架构完全可以参考企业所属于的行业的涉及到的标准模型进行重构和完善，如供应链的SCOR模型，电信行业的eTom模型等。我们在构造这个业务架构图的时候一直强调的就是高内聚松耦合的思路，符合业界的相关参考模型和标准，但是实际执行的时候究竟该遵循什么思路？

在这里一个可行的思路仍然是回归到矩阵分析，这里涉及到矩阵分析比较多，一个个的说明：

业务组件交互矩阵：在该矩阵上横向和竖向都是业务组件，在内容单元格里面是具体的业务交互接口点，通过这个交互矩阵分析是可以全局的看到当前的业务组件划分是否会导致大量的业务接口存在。并分析每个业务接口产生的原因，以进行组件的合并，业务组件中业务功能的转移等。(后续应用集成架构分析的输入)

数据和业务交互矩阵：在该矩阵图上，横向具体的业务组件和业务功能，纵向是具体的业务对象，在内部是具体的CRUD信息，也即是传统的CRUD矩阵分析。在该矩阵分析中的重点是，对于同一个业务对象，CUD操作尽量减少分离，而读操作则可以共享。以减少业务对象数据的多头管理和维护。将统一业务表单和数据的维护尽量控制在同一个业务组件中完成。减少数据间的交互和传递。

流程交互分析矩阵：在该矩阵上面横向是具体的流程信息，纵向是具体的流程活动信息，在这个矩阵图上可以看到同一个流程活动或流程片段往往存在于多个不同的流程。该分析的重要作用是对流程建模中可复用的流程片段或流程活动进行抽象和分析。(SOA服务建模时候需要)

功能业务组件分析矩阵：在该矩阵上横向是具体的业务组件或模块，纵向是具体的业务功能，在该交互分析上重点是分析具体的可复用的业务功能，以对可复用的业务功能进一步进行抽取，形成可复用的服务。(SOA服务建模时候需要)

本文作为TOGAF业务架构各个产出工件形成和交互关系的一个补充，具体TOGAF的业务架构建模很多仍然是停留在标准方法论基础上，而没有具体的操作性指南。反而是类似联邦企业架构FEA给出了一些可以更方便实践操作的方法和案例。

再谈数据架构

首先在TOGAF的ADM方法论中将数据架构部分的内容放在了信息系统架构-数据架构部分，这个方式是不合适的。前面一直强调了企业架构的两条重要线索，一个是流程，一个是数据，这两者都是既涉及到业务架构部分，也涉及到应用架构部分。在最终架构的分析和分解，业务建模到IT实现的转换过程中，自然就会过渡到应用架构部分的内容。

因此再次强调业务架构中也有数据架构部分的内容，只是业务架构中的数据架构的重点在数据域，高层的业务对象和概念模型，在业务架构的端到端流程分析和业务用例建模过程中自然会衍生出对应的业务数据对象和业务对象模型。

数据架构包括两个方面的内容，一个是静态部分的内容，一个是动态部分的内容。

对于静态部分的内容重点在于数据元模型，数据模型，包括主数据，共享动态数据和所有业务相关的业务对象数据的分析和建模。而动态部分的重点则是数据全生命周期的管控和治理。因此不能单纯地将数据架构理解为纯粹静态的数据模型。在业务架构中的数据模型分析重点是主数据和核心业务对象，而应用架构中的数据模型则进一步转换到逻辑模型和物理模型，直到最终的数据存储和分布。

数据分两个层面的生命周期，一个是单业务对象数据全生命周期，这个往往和流程建模中的单个工作流或审批流相关；一个是跨多个业务域数据对象的全生命周期，体现的是多个业务对象数据之间的转换和映射，这个往往是和端到端的业务流程BPM相关。在这里要注意的是，数据虽然是静态层面的内容，但是数据的生命周期或端到端的数据映射往往间接地反应了流程，这是很重要的一个内容。

数据建模的方法包括了面向结构的传统的ER模型分析方法，也包括了面向对象的对象类模型分析方法，两个方法都是可行的数据建模方法。只是传统的ER方法更容易实现向底层物理数据库模型的转换，而面向对象的类建模方法更加容易体现抽象和复用。特别是在企业架构建模中，面向对象和面向结构往往并不是严格区分的，很多时候都会出现两种方法混用的情况，但是重点是要区分每种方法或工具的重点以及解决的问题。

结合数据后相关的矩阵分析相当多，在业务架构阶段重点的矩阵分析是业务对象和业务流程，业务组件，业务功能间的类CRUD矩阵分析；而在应用架构阶段重点则会是逻辑或物理模型对象和具体的应用模块或应用功能间的矩阵分析。两者的思路基本类型，但是只是关注层面不同。前者的重点是主数据的识别和业务组件的分析，而后者的重点是应用功能模块的划分和模块间集成接口的初步分析。

对于数据集成分析根据前面的思路仍然应该分解为两个层面的内容，一个是业务层面的分析，一个是应用和IT实现层面的分析。前置的重点是理清业务流程或业务域之间的业务对象集成和交互，后者的重点是数据如何更好的共享或如果通过类似BI工具或ESB平台来实现数据的集成和交互。在TOGAF的信息系统架构-应用架构中特别要注意应该专门有一块内容来谈应用集成架构，解决的是业务系统和平台层技术组件间的技术集成，集成的实现方法，集成采用的工具技术等。

除了主数据之外，全局共享的动态数据分析仍然是数据模型分析的一个重点。或者说这个分析完成后基本可以找到整个企业端到端流程或某个业务域中的核心领域对象和领域模型。这个分析的重点是方便后续在实现层面进一步的构造通用共享的领域对象服务层，而不是纯粹的数据对象服务层。能够体现领域对象层延续前面讲的由业务-》应用-》集成的架构分析思路是相当重要的。

再谈应用架构

前面谈了业务架构和数据架构，接着谈下应用架构，对于应用架构的描述将参考TOGAF信息系统架构部分的内容，但是不完全相同，总体思路是围绕在IT架构层面来谈应用架构包括的内容。为了区分高层架构(包括多个应用的总体架构）和底层架构（针对单个业务系统的架构），前者采用企业架构中的应用架构这个词，后者采用系统架构这个词以进行区分。

首先说下应用架构中静态的部分，包括了应用功能架构和应用数据架构两个部分的内容，应用功能架构由业务架构中的业务组件架构转化过来，应用数据架构由业务架构中的业务对象数据架构或全局ER模型转化过来。中间会体现出映射关系。

对于应用功能架构可以比较明细的看到和业务架构之间的映射关系，但是要强调的是高层应用架构图中已经会明确地体现出了具体的业务系统，因此业务架构中的业务域业务组件和应用系统间往往不是一对一的关系，其中既存在合并也存在拆分，比如对于采购可能是独立的业务域或业务组件，但是在构建应用系统的时候可能是构建一个大的供应链系统；而财务是一个大的业务域，但是又可能拆分为报账，预算，成本管理等多个业务系统。这个一方面是结合企业实际情况，一方面仍然是考虑系统分解的颗粒度和耦合度。第二点应用架构和业务架构的不同体现在应用架构重点已经是在实现层面，需要实现业务架构朝IT架构层面的抽象和转化，最明细的就是底层可能会抽象相应的基础平台和技术平台，而上层或抽象相应的门户等，这些在业务架构中是绝对不会关心的内容。

业务架构阶段的数据架构重点是业务和领域对象，数据域的划分，主数据的分析和识别，重点是数据的概念模型。而到了应用架构则需要将业务对象转换为数据对象或具体的数据库表对象，应用架构的重点则已经是逻辑模型和物理模型。同时在应用架构阶段已经在分析数据对象和应用系统和应用功能之间的CRUD矩阵，以明确功能边界划分的合理性，以做到更好的系统划分和高内聚。

其次，在业务架构中有流程建模的动态建模部分，在业务架构中往往会从高端流程-》流程分解-》一直在具体的业务用例建模。而到了应用架构中要注意仍然存在动态建模部分，即业务用例-》系统用例-》用例实现，这个可以理解为应用架构中更加细化的动态建模，这个动态建模完全是实现层面的事情了，和本身应用系统的技术架构和分层也密切相关。但是这个过程却相当重要，特别是核心业务用例的用例实现，在这个动态建模过程中会分析和识别出一些细粒度的服务交互。在单个业务系统的架构设计中往往应用到类似序列图的方式来进行用例实现的交互，重心是在分层模型上面，而在应用架构中往往也用到序列图的交互，重心不是在分层上而是在不同的技术组件上的交互，这一点需要明确。

再次，应用架构设计中一个重要内容就是集成架构，集成架构包括了数据集成和业务集成两种，需要区别对待。数据集成架构重点是参考BI架构方式，而业务集成重点则是依照SOA参考架构模式进行。集成架构的分析可以在进行了业务系统划分后识别出业务系统之间所有核心的交互点和接口，作为数据集成或SOA服务的输入信息，也可以进一步对业务系统划分是否合理，是否满足松耦合的条件进行修正。集成和共享是两个层面的内容，集成往往数据落地，而共享往往数据不落地只是提供能力，当你在进行集成分析的时候发现了多点集成和交互的时候，往往都需要考虑能力抽取和下沉到平台，进行能力共享。如下图：

最后，应用架构中包括技术架构的内容，在这里分为多个方面的内容，首先是涉及到支撑企业内所有应用的技术平台层架构方面的内容；其次是整个应用架构中基于SOA参考架构的服务架构的内容；还有就是针对单个应用的类似java的ssh分层架构的内容，对于基础设施架构暂时先不纳入应用架构中的技术架构来考虑。

对于SOA组件化业务架构是对类似ssh分层技术架构的一个加强，而不是互斥的两个东西，再引入SOA参考架构会会进一步强调业务组件，服务组件和技术组件，强调服务能力的抽象，强调服务能力的共享，强调了各个组件之间真正意义上的松耦合，强调部分业务是可以通过服务组合和编排来实现的。

在应用架构的构建中我们引入了云平台和云化的思路，即各个应用系统不是简单的烟囱式的结构，而是从底层基础设施层面开始逐层向上考虑哪些是应用系统共享的技术能力，哪些是可以集中化建设和共享的，对于基础设施层则抽象到iaas层能力，对于技术平台层则抽象到paas层能力。由底层集中化建设的iaas+paas平台来支撑上层松散耦合的多个业务系统或应用模块，这是一种应用架构中体现云计算思路的重点。

应用架构和技术架构

在这里再谈下应用架构和技术架构的关系和边界问题。

首先再说下应用架构，应用架构是和业务架构有强烈的映射关系的一个架构，应用架构要说明的是整体企业内部信息化建设和规划应该分为哪些应用系统去建设，应用系统间的集成关系是如何的。就是我们常说的应用架构和应用集成架构。业务架构只关系核心的业务流程，业务域，业务组件识别出来即可，应用架构在业务架构的基础上多考虑两个事情。

一个是究竟如何来划分业务系统，业务系统和业务组件的划分颗粒度如何？如何满足划分后的业务系统间的高内聚松耦合；

第二个是在业务架构转换到应用架构去规划后续建设实施的时候，应该有哪些内容可复用的识别，将可复用的内容和资源共享的内容下沉到我们说的平台层，将业务系统间需要协同和整合分析的内容上升到我们常说的门户层和BI展示层。解决完这两个问题即完成业务系统朝应用架构的转化。

简单来讲应用架构中的所有点都是应该后续可以规划建设的应用系统或平台。企业后续需要建设一个安全管理平台，虽然和业务无关，但是应该体现在应用架构的PaaS平台层。企业整个应用建设需要考虑IT基础设施资源池虚拟化和整合，需要体现在应用架构的IaaS基础平台层。企业没有这种单独抽出来独立建设的规划，就不用体现到应用架构中，而该点仅仅变化为应用系统中建设需要考虑的一个技术点，直接在技术架构中解决。

我原来一直强调过在产品开发里面的一个重要思路，即分为产品，平台和技术三个层面的内容。如果和这个分类方法对应，则产品和平台都应该体现在应用架构总体框架中，平台本身又分了IaaS层平台和PaaS层平台。而技术则体现在技术架构这个概念里面。即我们谈到技术架构和产品架构，平台架构都是一种松耦合的关系。技术架构本身不能形成平台或产品，而是需要在应用建设，平台建设中考虑究竟需要使用哪些技术，如何使用。产品中需要使用平台，也还需要使用平台中未涵盖的额外技术，平台建设中也需要使用各自关键技术，这些都需要体现在技术架构中进行统一的规划和考虑。

应用架构本身只关心需要有哪些应用系统，哪些平台来满足业务目标的需求，而不会关系在整个构建过程中你需要使用哪些技术；技术架构是接应用架构的技术需求，并根据识别的技术需求，进行技术的选型，并把各关键技术和技术之间的关系描述清楚。大家可以关注下互联网上各自技术架构分享资料，你最多知道一个大的业务场景，其它内容全是采用了什么样的技术，什么样的开源组件，这些技术融合在一起解决了哪些问题。而实际的应用系统长什么样子，有哪些具体的功能点在技术架构中是完全看不到的。

再回来看技术架构，技术架构解决的问题包括了如何进行纯技术层面的分层，开发框架选择，语言选择，涉及到各自非功能性需求的技术点（安全，性能，日志，异常，缓存，消息，大数据量）等需要使用的关键技术。由于我们的应用架构体系本身是分层的，那自然有和其对应的技术架构体系，大的分层包括了SOA参考架构分层模型，小的分层则是单个应用的技术分层多层框架。这些都考虑清楚的剩下的问题就简单了，即根据实际的业务场景模拟来验证各个技术点间的协同，各技术点最终形成技术组件，各个技术组件间也需要高可靠集成。

注：按该思路，当前云原生解决方案整体技术平台，包括了微服务开发框架环境，DevOps过程能力支撑，容器云，微服务治理管控框架等都可以算做技术架构内容。

技术架构是对应用架构的一个完整支撑，应用架构和技术架构都描述清楚后还应该考虑和验证当前技术架构是否可以完整的支撑应用建设。应用架构是给技术架构输入具体的应用建设需求变转换为具体的技术需求点，各个技术点的分析，方案选型，最终形成关键技术清单，关键技术清单考虑应用架构本身的分层逻辑形成一个完整的技术架构图。对于IT基础设施架构我们常常将其纳入技术架构范畴，但是不是全部。对于单个应用系统建设的时候谈到应用本身的MVC模式分层框架更加仅仅是技术架构的一部分内容。

谈SOA和云计算架构设计的关键点

对于SOA和云架构设计方面的内容，前面已经有很多文章涉及到，在这里再重点谈下SOA和云架构设计和传统EA企业架构和单业务系统架构设计之间的一些区别和联系。

SOA和云架构设计更多的是在企业架构的应用架构和技术架构层面，然后才过渡到单个应用的架构设计约束，因此也可以理解为是传统软件架构设计更加上层的一个内容。SOA和云架构设计更加确切点来说应该是基于SOA和云计算思想的架构设计改进，而不是对面向对象架构设计思想的否定。

SOA思想强调的解耦，解耦思想最终落实到架构设计中是业务能力组件化，组件间的交互通过服务接口进行，粗粒度的服务本身就体现了松耦合，解耦不仅仅是组件的应用层，还包括了数据库和数据层都能够自成一套可以独立进行需求，设计，开发，测试和运维的全生命周期管理。另外为了最大限度的解耦，还需要借助消息中间件或服务总线，还需要考虑尽可能将同步服务转换为异步服务设计。

SOA思想强调的粗粒度，在架构设计中需要考虑的是不同的业务系统，组件或模块间只需要暴露需要暴露的服务能力而高内聚的屏蔽内部的数据和业务的复杂性。同时组件之间的交互要尽可能地减少传统意义上的数据库层的数据集成，数据集成和同步一方面是数据多点落地带来的数据实时性和一致性方面的问题，一方面是数据的集成同步导致大量组件内部逻辑外泄。同时尽量在架构设计过程中遵循领域设计和建模的思路，即在数据库上抽象领域对象层，以屏蔽底层数据模型细节。

SOA思想强调的可复用，在传统的架构设计中本身就有一个重要步骤即可复用的组件的抽取，可复用的组件朝外提供的服务能力自然也是可复用的服务，这是其一。传统架构设计中进行完模块和组件划分后，需要考虑组件之间的接口设计，那么在接口设计中需要考虑接口本身的服务化设计，接口本身的可复用性设计。对于底层技术组件或共享数据组件的可复用大家比较容易理解，而对于业务服务的可复用重点则在于可以复用到多个不同的业务场景或业务流程中服务的组合和组装。

SOA思想强调的服务本身的灵活组合和组装，这个内容往往偏EA架构设计层面的内容，即需要从端到端的业务流程层面来识别和分析服务。传统的架构设计往往关注的是一个个核心用例功能点，而服务组装编排关注的则是跨多个业务功能点的流程协同。提出这个的原因也正是，当我们在企业内规划和建设一个全新的系统时候，务必先考虑该系统在整个企业应用架构体系中的位置，该系统和其它业务系统间的横向纵向业务系统关系，然后再过渡到系统内架构设计。

对于单个系统，前面专门有文章谈过基于SOA的架构设计要点，这里再重点描述下即，单个系统能够组件化设计，组件之间能够做到从数据库到应用层相对独立，组件之间只能通过服务接口交互，这个重点解决了组件间的横向协同问题；其次，单个组件的设计建议的方法还是遵循领域建模的思路，最好是在原来的分层技术架构上，增加专门的服务层，即对于单个组件纵向来说也通过服务层来实现底层领域服务逻辑和上层界面展现和服务组装的分离。对于组件纵向可以采用传统API服务接口，而对于组件横向则采用WebService接口来实现进一步的解耦。

从以上分析来说，当我们谈到SOA架构设计的时候，不要一开始就被消息中间件，ESB服务总线等内容误导，如果没有充分地考虑SOA思想内涵并在传统的架构设计中引入SOA思想，那么即使采用了ESB服务总线最终也可能只起到了简单的接口平台的作用。

接着谈下云的思想，云思想的核心是终端能力朝云端的迁移，即集中化。SOA虽然强调了复用，但是这个复用可能还是在原来单个业务系统内部建设，然后再将服务能力共享出来，而云的思想更多的则考虑建设都不在传统的单个系统内部了，而应该集中化建设，能力集中提供，这个集中化提供的地方即平台。

基于这个思想需要注意到的就是对于传统的软件架构设计而言，由于关注的是单个业务系统，可复用的组件或能力还在系统内部，而到了云架构设计阶段，关注的是企业内整个应用和技术架构体系，因此这些可复用的内容从传统的系统内转化到了完全的系统外，这个是云架构设计思想下很重要的一个转变，即准备有了完全独立于系统外的可为多个业务系统提供服务能力的云平台。这个云平台不是简单的IaaS平台，而更多是PaaS层面的流程平台，数据平台，集成平台，技术平台等。

云思想强调无限伸缩，对应到架构设计中即可扩展性，对于传统的架构设计我们更加关注的是组件或接口本身的技术可扩展性，而比较少关注业务系统本身所对应的IT基础设施或平台本身的资源弹性伸缩扩展性，这个在架构设计中也是可以考虑引入的，包括各种分布式存储，分布式处理和计算，数据拆分，对PaaS资源托管平台的统一接入和适配等。

最后，在涉及到云架构设计的时候，需要考虑多租户设计，多租户设计和传统架构设计中的多组织设计还有些区别，租户往往有更加严格的资源隔离和资源流量控制要求，而不仅仅是数据访问上的隔离。还有就是在基于云架构设计中，需要重点考虑自服务模式，即围绕服务全生命周期的管控来考虑云的能力的服务化提供。

（以上内容摘自互联网，如有侵权请联系删除）