#业务-应用-数据-技术架构的正向设计方法企业架构方法一直强调对组织的业务、应用、数据和技术架构进行全面、正向的设计，从而实现组织战略和业务对准，以及业务和IT的对准。但是很多项目都很难真正做到这一点。其原因有三：
对架构的理论掌握不到位。
学习TOGAF有助于建立架构思维，但还远远不够，即使通过了TOGAF鉴定级认证，也需要通过具体的项目实施，不断反思TOGAF的内容，并加以剪裁和补充才能逐步形成具体的架构项目实施方法。
缺乏合适的落地方法和工具。
架构强调正向设计，业务、应用、数据和技术架构是从上至下的正向推导，和从下至上的反向承接关系。这就要求在架构项目开始之初，就要规划出架构项目完整的技术路径，并设计出绝大部分项目过程中使用的工具和模板，通过工具和模板保证各个架构之间的逻辑关系，确保各个架构域之间的承接落到实处。
需要项目实施顾问较高的能力。
无论架构项目的边界和范围是何种程度，都要求架构实施顾问具有全局思维，既要懂业务，还要懂IT，能高屋建瓴搭建逻辑蓝图，也能深入细节挖掘问题。有些还需要有项目所处行业的背景知识和技能经验。
我们没有寄希望于通过一篇文章或者一个视频就能全面提高架构师的各项能力。事实上，对架构理论的升华和个人能力的提高，都需要在实践中不断磨练，通俗的说，跳进去的坑多了，跳出来的能力就提高了。但是架构正向设计还是有方法和工具的，这些工具对各行各业都有可参考和可借鉴作用。
今天介绍的这家企业属于典型的产品研发型企业，主要从事大型复杂产品的研发。众所周知，复杂产品的研发过程必须不断通过仿真、计算和试验来验证研发理论的正确性，确保设计的结果满足原始需求，并掌握产品的最终性能指标等。产品的研发和试验紧密耦合，过程中采用了大量的三维数字化协同设计与制造技术、基于模型的系统工程（MBSE）技术和数字化仿真运算技术等。
本项目的特点就是通过架构方法，全面构建了业务架构、应用架构、数据架构和技术架构。全面定义四个架构域的项目并不多见，这种项目更需要注重各个架构域之间的逻辑推导和验证关系。
我们在项目论证阶段就规划了各架构域之间的联系（见下图）。从业务架构出发，定义了业务组件、业务数据交互关系和需求测度模型；在对业务组件的功能范围和企业应用集成现状的基础上，设计应用架构，给出了信息化需求目录、业务/数据UC矩阵、应用组合目录和应用交互关系；在对业务组件的数据主题域和数据对象分析的基础上，设计了数据架构，定义了概念数据、数据/应用UC矩阵、数据/业务UC
矩阵、和分析数据主题定义；最后通过对应用架构的应用系统部署情况和数据架构的数据分布情况、数据频率等，定义技术架构，形成了平台分解图、技术标准目录、、技术谱系目录、应用/技术矩阵、环境和位置图等。
一、业务架构
业务架构工作主要目标是根据企业战略愿景，分析业务现状，识别现有业务能力及问题，提出业务改进需求，设计目标业务架构。项目在梳理AS-
IS业务架构时，采用5W1H调研表调研信息，同时参考管理程序文件，依据业务组件归集原则，进行现状的组件梳理，并将组件与研制阶段进行对应。同时在梳理业务组件的前提下，通过业务组件的串联形成流程图。
在设计TO-
BE业务架构时，通过业务需求分析，并参考外部标杆，识别需要完善或新增的业务组件，形成未来业务组件总体视图。对于发生变化的业务组件，具体变化要求将在业务架构差距分析部分进行详细描述。
在业务架构设计过程中，使用的工具方法包括《5W1H表》、《业务架构差距分析矩阵》等，为应用架构、数据架构和机会及解决方案、迁移规划提供输入。
二、应用架构
应用架构工作主要目标是根据企业现状应用架构需求及业务架构中的数据流分析结果，设计目标应用架构。应用架构的设计起源于5W1H业务调研表中的信息化需求（这是在业务架构设计时就预留的指导应用架构设计的接口）。同时结合业务组件的五要素定义等，以及对现有信息系统进行现场调研了解信息化应用现状，通过分析得出现状应用架构。业务架构和应用架构的设计联系见下图。
为了进一步了解应用对业务的支撑情况，需将梳理出来的AS-IS应用架构与AS-
IS业务架构做出对应关系分析，了解当前信息化支持情况，和尚无信息化条件支撑的情况，为设计TO-BE应用组件的输入。
设计TO-BE应用架构时，需要对信息化需求进行归集并进行功能分析整理，同时利用业务/数据UC矩阵进行应用边界划分和数据流转设计。
在应用架构设计过程中，使用的工具方法包括《业务/数据UC矩阵》、《应用架构差距分析矩阵》等，为数据架构、技术架构和机会及解决方案、迁移规划提供输入。
三、数据架构
数据架构工作主要目标是根据企业现状数据架构需求及业务架构中的数据流转，设计目标数据架构。
确定AS-IS数据架构有四个步骤，包括对现有业务调研，整理业务涉及到的指标，形成主题分析数据；通过业务/数据UC矩阵中数据类，确定AS-
IS数据架构中业务数据；基础数据中以主数据为核心，根据主数据特征，确定主数据。分析主数据的属性，确定主数据的元数据。根据主数据的编码规则，确定编码数据；最后形成AS-
IS数据架构图。
设计TO-BE数据架构也分为有四个步骤，包括根据指标体系，定义TO-BE主题分析数据类别；根据5W1H调研中对业务数据的需求，结合AS-
IS数据架构中业务数据确定TO-BE数据架构中业务数据；在没有业务数据重大变化的前提下，基础数据保持相对稳定；最后推导TO-BE数据架构图。
在确定TO-BE数据架构和AS-IS数据架构的基础上，运用差距分析矩阵，比对AS-IS数据架构和TO-
BE数据架构，确定差距，为机会及解决方案、迁移规划提供输入。
四、技术架构
技术架构工作主要目标是基于现状技术架构、技术标准、业务/应用/数据架构要求，设计目标技术架构。梳理AS-IS技术架构，形成平台分解图和技术谱系目录。
平台分解图主要描述支持信息系统架构运行的技术平台，该图涵盖基础设施平台的所有方面，并提供组织技术平台的概述。技术谱系目录是识别和维护组织在用的所有技术的列表，包括硬件、基础设施软件和应用软件。技术谱系目录是建立其余矩阵和图所依据的基础。
设计TO-BE技术架构时，在AS-
IS技术架构基础上，重点考虑新增业务场景或应用支撑，所需的制定技术解决方案（软硬件、网络等）、基础设备到达运行周期后所需的备选方案（删除数据或新增设备）等，设计TO-
BE技术架构。
五、机会解决方案及迁移规划
机会解决方案及迁移规划工作主要目标是分析业务架构、信息系统架构和技术架构提出的差距分析，设计工作包，并识别工作包相互影响和资源需求，确定优先级，设计迁移规划路线。
根据差距分析结果定义工作包，将业务架构、应用架构、数据架构、技术架构的差距分析结果进行归集汇总，并考虑实施约束（包括企业战略、资源约束、变革阻力等），然后对差距分析结果进行审查和合并，形成一个个工作包。
确定迁移规划时，需要先进行依赖性分析，并进行工作包资源评估。按照迁移规划模板，在迁移规划方案中，需要明确工作包的责任人、前置条件及具体实施路径。作为未来实施治理的输入。
本项目依据TOGAF企业架构方法论，完成了面向试验业务场景的业务架构、应用架构、数据架构和技术架构，并制定了机会解决方案和迁移规划，按照TOGAF理论方法完成了架构设计的全过程，为架构实践提供了有力的实践案例。在项目中完成的TOGAF中定义的架构制品见下图。
如果想进一步了解本项目详细技术路径、实施过程、架构制品等内容，请关注企业架构实践案例系列课程。