再谈数据架构

本篇为杂谈，主要是想谈下企业架构中数据架构部分的一些关键点。

首先在TOGAF的ADM方法论中将数据架构部分的内容放在了信息系统架构-数据架构部分，这个方式是不合适的。前面一直强调了企业架构的两条重要线索，一个是流程，一个是数据，这两者都是既涉及到业务架构部分，也涉及到应用架构部分。在最终架构的分析和分解，业务建模到IT实现的转换过程中，自然就会过渡到应用架构部分的内容。因此再次强调业务架构中也有数据架构部分的内容，只是业务架构中的数据架构的重点在数据域，高层的业务对象和概念模型，在业务架构的端到端流程分析和业务用例建模过程中自然会衍生出对应的业务数据对象和业务对象模型。

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

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

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

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

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

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

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