业务-应用-数据-技术架构的正向设计方法

Posted 2021-12-03 NeNeChan

企业架构方法一直强调对组织的业务、应用、数据和技术架构进行全面、正向的设计，从而实现组织战略和业务对准，以及业务和IT的对准。但是很多项目都很难真正做到这一点。其原因有三：

对架构的理论掌握不到位。学习TOGAF有助于建立架构思维，但还远远不够，即使通过了TOGAF鉴定级认证，也需要通过具体的项目实施，不断反思TOGAF的内容，并加以剪裁和补充才能逐步形成具体的架构项目实施方法。

缺乏合适的落地方法和工具。架构强调正向设计，业务、应用、数据和技术架构是从上至下的正向推导，和从下至上的反向承接关系。这就要求在架构项目开始之初，就要规划出架构项目完整的技术路径，并设计出绝大部分项目过程中使用的工具和模板，通过工具和模板保证各个架构之间的逻辑关系，确保各个架构域之间的承接落到实处。

需要项目实施顾问较高的能力。无论架构项目的边界和范围是何种程度，都要求架构实施顾问具有全局思维，既要懂业务，还要懂IT，能高屋建瓴搭建逻辑蓝图，也能深入细节挖掘问题。有些还需要有项目所处行业的背景知识和技能经验。

我们没有寄希望于通过一篇文章或者一个视频就能全面提高架构师的各项能力。事实上，对架构理论的升华和个人能力的提高，都需要在实践中不断磨练，通俗的说，跳进去的坑多了，跳出来的能力就提高了。但是架构正向设计还是有方法和工具的，这些工具对各行各业都有可参考和可借鉴作用。

今天介绍的这家企业属于典型的产品研发型企业，主要从事大型复杂产品的研发。众所周知，复杂产品的研发过程必须不断通过仿真、计算和试验来验证研发理论的正确性，确保设计的结果满足原始需求，并掌握产品的最终性能指标等。产品的研发和试验紧密耦合，过程中采用了大量的三维数字化协同设计与制造技术、基于模型的系统工程（MBSE）技术和数字化仿真运算技术等。

本项目的特点就是通过架构方法，全面构建了业务架构、应用架构、数据架构和技术架构。全面定义四个架构域的项目并不多见，这种项目更需要注重各个架构域之间的逻辑推导和验证关系。

我们在项目论证阶段就规划了各架构域之间的联系（见下图）。从业务架构出发，定义了业务组件、业务数据交互关系和需求测度模型；在对业务组件的功能范围和企业应用集成现状的基础上，设计应用架构，给出了信息化需求目录、业务/数据UC矩阵、应用组合目录和应用交互关系；在对业务组件的数据主题域和数据对象分析的基础上，设计了数据架构，定义了概念数据、数据/应用UC矩阵、数据/业务UC 矩阵、和分析数据主题定义；最后通过对应用架构的应用系统部署情况和数据架构的数据分布情况、数据频率等，定义技术架构，形成了平台分解图、技术标准目录、、技术谱系目录、应用/技术矩阵、环境和位置图等。

一、业务架构

业务架构工作主要目标是根据企业战略愿景，分析业务现状，识别现有业务能力及问题，提出业务改进需求，设计目标业务架构。项目在梳理AS-IS业务架构时，采用5W1H调研表调研信息，同时参考管理程序文件，依据业务组件归集原则，进行现状的组件梳理，并将组件与研制阶段进行对应。同时在梳理业务组件的前提下，通过业务组件的串联形成流程图。

在设计TO-BE业务架构时，通过业务需求分析，并参考外部标杆，识别需要完善或新增的业务组件，形成未来业务组件总体视图。对于发生变化的业务组件，具体变化要求将在业务架构差距分析部分进行详细描述。

在业务架构设计过程中，使用的工具方法包括《5W1H表》、《业务架构差距分析矩阵》等，为应用架构、数据架构和机会及解决方案、迁移规划提供输入。

二、应用架构

应用架构工作主要目标是根据企业现状应用架构需求及业务架构中的数据流分析结果，设计目标应用架构。应用架构的设计起源于5W1H业务调研表中的信息化需求（这是在业务架构设计时就预留的指导应用架构设计的接口）。同时结合业务组件的五要素定义等，以及对现有信息系统进行现场调研了解信息化应用现状，通过分析得出现状应用架构。业务架构和应用架构的设计联系见下图。