在大数据和数据科学的新时代，对企业而言，一定要有与业务流程保持一致的中心化数据架构，该架构能随业务增长而扩展，并随技术进步而发展。
一个成功的数据架构可以使数据的各个方面清晰明了，从而使数据科学家能够高效地处理可信的数据并解决复杂的业务问题。
架构还能帮助组织做好必要的准备，以利用新兴技术迅速抓住新的商机，并通过管理整个企业中的复杂数据和信息交付来提高运营效率。
与信息架构、系统架构和软件架构相比，数据架构相对较新。数据架构师的角色也很模糊，落在了高级业务分析师，ETL开发人员和数据科学家的肩膀上。尽管如此，在本文中，作者将用“数据架构师”(Data Architect)来指代那些为组织设计数据架构的专业数据管理人员。
说到架构，我们经常会想到与建筑架构做类比。传统的建筑架构师会规划、设计和审查建筑物的建造。设计过程包括与客户充分沟通收集需求，了解当地的法律和环境限制，并与工程师、测量师及其他专家合作，以确保设计在预算之内可行。
这项工作的复杂性实际上与数据架构师的角色非常相似。但是，两个架构师角色之间存在一些基本差异：
- 建筑物架构是自上而下的设计，而数据架构通常是将已存在的组件或系统集成。
- 建筑设计师在建造建筑物之前必须了解全部建筑要求并规划建筑范围。数据架构的范围更为广泛且易更改。因此，成功的数据架构设计应该是灵活的且有预见性的。
- 建筑架构师具有严格的教育和专业要求，并且应该在商业、艺术、结构物理和建筑材料方面有深入研究。而大多数数据架构师来自IT背景，在几家公司或行业中具有专业经验，并且对业务的接触不多。因此，他们应该意识到自己的设计可能存在偏差，需要根据组织中业务和技术专家的反馈来调整设计。
- 建筑设计几乎都是针对从头开始建造的新建筑物的。因此，建筑架构师可以完全根据新要求和新材料进行规划和设计。数据架构师没有这种优势。他们很少能从头开始，但是在为未来进行设计时需要了解现有的平台和数据库。
虽然存在这些差异，但数据架构师仍然可以向建筑架构师学习，尤其是采用自上而下的方法来改进数据架构设计方面。很多机构都缺乏系统、集中的端到端的数据架构设计。下面列出了一些主要原因：
- 一个公司有多个IT部门，他们各自使用各自的数据标准和架构工作。
- 应用程序和流程是根据单个业务需求构建的，没有可遵循的数据架构标准。
- 数据架构师的角色仅关注有限的技术领域，并且对数据业务知识的了解也有限。
- 管理IT项目时，在设计阶段不考虑数据架构，数据科学家和工程师无需遵循一致的数据管理流程即可编写代码。
由于存在这些不足，所以我们经常会看到一家公司的数据系统脱节，并且团队和部门之间存在差距。这些差异导致系统性能低下，需要进行大量交接工作，在生产数据出现问题时要花很长时间才能排除故障，缺乏在整个系统中找到正确解决方案的责任感，并且缺乏评估产品变化影响的能力。
最后，在迁移脱节的系统或重新设计下一代平台时，可能要花费大量精力进行分析和研究。
考虑到所有这些因素，一个成功的企业需要具有以业务流程和运营设计为基础的自上而下一致的数据架构。特别是，就像建筑架构师所做的那样，企业数据架构师需要先在概念级和逻辑级构建蓝图，然后再将技术应用于详细的应用程序设计和实现。
1.基于业务流程和运营的概念级数据架构设计
在现代IT中，业务流程是由数据实体，数据流和应用于数据的业务规则共同支持和驱动的。因此，数据架构师需要具有深入的业务知识，其中包括财务、市场营销、产品以及业务流程(例如健康、保险、制造商和零售商)等特定行业的专业知识。
然后，他才能够通过设计代表每个业务域的数据实体和分类法以及业务流程下的数据流，从而构建正确的企业级数据蓝图。在此概念阶段尤其需要考虑和计划以下几个方面：
- 核心数据实体和数据元素，例如关于客户、产品、销售的数据。
- 客户和顾客所需的输出数据。
- 要收集、转换或引用的源数据以生成输出数据。
- 每个数据实体的所有权以及如何根据业务用例使用和分配它。
- 要应用于每个数据实体的安全策略。
- 数据实体之间的关系，例如参考完整性、业务规则、执行顺序。
- 标准数据分类和分类法。
- 数据质量、操作和服务水平协议(SLA)的标准。
设计的概念级别由支持每个业务功能的基础数据实体组成。蓝图对于成功设计和实施企业和系统架构及其未来的扩展或升级至关重要。
在很多机构中，这种概念设计通常被嵌入到由单个项目驱动的业务分析当中，而没有从企业端到端解决方案和标准的角度进行指导的方法。
2.逻辑级数据架构设计
由于要考虑使用哪种类型的数据库或数据格式，这种设计有时称为数据建模。它将业务需求与基础技术平台和系统联系到一起。但是，考虑到数据建模者的角色，大多数机构仅在特定数据库或系统中设计数据建模。
通过考虑适用于每个数据库或系统的标准以及这些数据系统之间的数据流，应采用集成方法开发成功的数据体系结构。特别是，以下五个领域需要以协同方式进行设计：
（1）命名约定和数据完整性
数据实体和元素的命名约定应一致地应用于所有数据库。同样，如果相同数据须驻留在多个数据库中，则应加强数据源及其引用之间的完整性。最终，这些数据元素应属于数据架构中概念设计中的数据实体，然后可以根据业务需求协同准确地对其进行更新或修改。
（2）数据归档/保留策略
如果在生产的最后阶段才经常考虑或建立数据归档和保留策略的话，将会导致资源浪费，不同数据库之间的数据状态不一致，以及数据查询和更新的表现不佳。为了加强数据完整性，数据架构师在以操作标准为基础的数据架构中定义数据归档和保留策略。
（3）隐私和安全信息
隐私性和安全性成为了逻辑数据库设计的重要考虑因素。虽然概念设计已经定义了哪个数据成分属于敏感信息，但逻辑设计应在具有受限访问权限、受限数据复制、特定数据类型和安全数据流的数据库中保护机密信息，以保护信息安全。
（4）资料复制
数据复制是要顾及三个目标的关键因素：
1)高可用性。
2)避免通过网络传输数据的性能。
3)低耦合性以最小化下游影响。
但是，过多的数据复制会导致混乱、数据质量差和性能下降的结果。任何数据复制都应由数据架构师检查，并应遵循一定原则和纪律。
（5）数据流和管道
在此级别上，应明确定义数据在不同数据库系统和应用程序之间的流动方式。同样，此流程与业务流程和数据架构师概念级别中提到的流程一致。此外，应在逻辑设计的集成视图中考虑数据摄取的频率、流水线中的数据转换以及针对输出数据的数据访问模式。例如，如果上游数据源是实时的，而下游系统主要被用于具有重索引的聚合信息的数据访问(例如，对于频繁更新和插入来说成本很高)，则需要在两者之间设计数据管道，以优化性能。
持续治理是数据架构成功的关键
由于数据架构反映并支持着业务流程，因此当业务流程发生更改时，数据架构就可能会发生改变。随着基础数据库系统的更改，数据架构也需要进行调整。因此，数据架构不是静态的，而是需要进行连续管理、增强和审核的。因此，应采用数据治理来确保在启动每个新项目时正确设计和实现企业数据架构。
结论
在成功的数据架构中，以业务流程为基础的概念设计是最关键的要素，其次是逻辑设计，该逻辑设计强调所有数据库和数据管道之间的一致性、完整性和效率。在建立起数据架构后，机构可以查看哪些数据驻留在何处，并确保数据的安全、有效存储和正确处理。
同样，当一个数据库或组件发生更改时，数据架构可以帮助机构快速评估影响并指导所有相关团队进行设计和实施。最后，数据架构是企业系统的实时文档，要保证它是很新的，并提供清晰的端到端图画。
综上所述，反映端到端业务流程和操作的整体数据架构对于保障公司在经历重大变化(如收购、数字转换或向下一代平台迁移)时快速高效地前进至关重要。
