TOGAF由国际标准权威组织The Open Group制定。The Open Group于1993年开始应客户要求制定系统架构的标准，在1995年发表The Open Group Architecture Framework (TOGAF) 架构框架。TOGAF的基础是美国国防部的信息管理技术架构(Technical Architecture for Information Management: TAFIM)。它是基于一个迭代(Iterative)的过程模型，支持最佳实践和一套可重用的现有架构资产。它可让您设计、评估、并建立组织的正确架构。TOGAF的关键是架构开发方法（Architecture Development Method: ADM）: 一个可靠的，行之有效的方法，以发展能够满足商务需求的企业架构。——百度百科
读完《业务架构 应用架构 数据架构实战》一书，对数字化转型浪潮下的企业架构有了新的理解，这样一套架构并不是凭空想象出来的，而是通过TOGAF方法逐步细化得到的。在TOGAF中定义了业务架构、数据架构、应用架构和技术架构，每个层次都有相应的方法来完成架构设计。
让我感触最深的是数据架构。为什么感触深，是因为我负责的管控OTN中数据的设计存在各种各样的问题，已成为了管控OTN架构的一个明显短板，严重影响了产品的一致性与性能，也是架构改进的重点方向。
我认为目前管控OTN中数据设计遇到的各种问题，其实是因为我们的设计人员缺乏数据设计的方法，大家不知道怎么去设计合理的数据，基本上是以下集中方式：
- 继承，上一代产品是怎么做的，我就怎么做，这样肯定没错。
- 遵从，设备数据什么样，我就什么样，这样肯定能对上。
- 混合，把继承与遵从揉到一起，来什么样的我都不怕，也导致数据结构越揉越大，越来越复杂，越来越耦合。
从我的描述不难看出，我们的数据设计最大的问题没有理解数据是用来做什么的，或者说究竟我的业务流程应该使用哪些业务数据，而是将数据作为一个附属产物而不是核心。这就必然造成我们的数据常常出现：
- 冗余，这不是最严重的问题，大多数时候我们能容忍冗余。
- 平铺，数据没有结构全部展开，大量无用的信息影响效率。
- 数据关系不清楚，无效的多张表联合查询，导致效率低下。
- 数据字段含义错误，因为没能真正理解，开发使用和改动都容易“踩雷”。
在TOGAF中，数据架构是企业架构的一个重要组成部分，它承接业务架构，并作为应用架构设计的参考甚至基础。具体在架构实践中，仅仅依靠TOGAF中的数据架构设计内容是远远不够的，需要结合DAMA、IRP等方法，基于组织前期的业务架构设计成果进行开发，对组织的核心数据对象进行了识别和定义，并从数据统一存储、统一管理的角度设计了数据资源分类框架，规划了各数据对象在业务、应用系统中的分布，最终形成企业数据架构。
用《业务架构 应用架构 数据架构实战》书中的例子来看下具体是怎么做的。业务驱动的数据建模被细分成多种粒度，首先是巨粒度，这个粒度会使用UC矩阵进行发现数据域、识别数据类型。接下来是粗粒度，借助业务流程图识别数据实体。通常我们到这一步就结束了，认为已经把业务流程相关的数据设计清楚了，但实际这一步离设计清楚还有很大的差距。TOGAF不会停着这里，它继续向下进入到中粒度，功能特性驱动数据实体、属性、关系模型的细化，到这里我相信代码已经浮现出来，开发人员已经能够清楚地明白数据与数据之间的关系了。TOGAF还有细粒度分析，关注到业务规则驱动模型细化，这步通常是我们忽视，也导致我们的代码总有很多隐藏起来的“小秘密”，这些秘密平时不会有问题但是一旦出问题，定位起来就会非常困难，也就是我们常常抱怨的模型不完整、模型质量差、不断改模型、改程序。
这本书解答了我一直在思考的问题，即如何通过一些方法的组合来保证软件架构设计中的输出物能更加准确地反映业务。各个层次介绍的方法非常值得推广，在读完此书后，我已经要求部门所有的SA和TL都要把这本书作为23年的必读书籍，并且要组织读书心得交流和代码实例讲解，以此作为23年部门开发人员架构能力提升的开端。
网友评论