第1个回答 2022-07-29
架构（EnterpriseArchitecture，EA）是对组织复杂度及其变化演进过程进行掌控的顶层方法。是组织的逻辑蓝图，基于背景环境建立组织的完整性、多层次一致的结构化描述。架构始终强调两个对准，即战略和业务的对准，以及业务和IT的对准。
应用架构是业务与IT对准过程中的重要环节，但是很多组织在架构实践中往往对应用架构设计存在以下误区。
首先，把应用架构等同于应用系统架构或软件功能架构，甚至是组织当前已经部署的IT系统的罗列。我曾经见过很多组织开发的应用架构，都是从当前的IT系统出发，设计面向未来的IT系统迁移路径。这种方法没有从根本上解决组织应用的整体架构设计，更谈不上任何与业务架构的对准。
其次，直接开展应用架构设计。应用架构设计的目标是通过搭建逻辑上的应用蓝图，实现应用对业务的支撑和覆盖，确保业务与IT之间的衔接和对准。如果不从业务架构出发，甚至组织的业务架构都没有建立，应用架构的设计原则和面向未来的应用架构就无从谈起。
第三，应用架构是信息化部门的事。这种情况往往存在于信息化部门在组织内话语权不强的时候。当组织要开展架构工作，应用架构和数据架构就会被定位为信息化部分的任务，使得应用架构往往得不到很好的讨论和验证，变成闭门造车，最后无法达成一致，也起不到承接业务架构和战略的目的。
事实上，应用架构是业务人员和IT人员都要参与的工作，作为一名架构师要既懂业务，还要懂IT，当架构深入到应用架构设计细节时，架构师需要领导组织内部的业务和IT人员充分讨论协调，绝不能把业务和IT进行割裂分开进行设计。
今天介绍的项目，就是从组织战略和业务架构出发，面向集成供应链和智能制造模式下的业务变革，开展应用架构和数据架构设计的架构实践案例。
按照架构的正向设计的方法，以“战略和业务架构对准，业务架构和IT架构对准“为指导原则，本项目制定了整体项目技术路径，保证业务架构和应用架构、数据架构的上下贯通，从逻辑上确保业务架构到应用和数据架构的技术路径正确性。
当然，上图中描述的技术路径颗粒度是远远不够的。架构项目都是从宏观到微观，从全局到细节的设计思想。所以本项目制定了更加详细的技术实施路线。从顶层战略目标需求测度分析定义开始，确定业务能力需求，设计业务考核测度，从而指导未来业务模式变革。在业务能力需求识别之后，要对AS-IS业务架构进行梳理分析，确定与满足战略目标业务能力需求的问题差距分析，并同时对现状应用架构和数据架构AS-IS支撑情况进行梳理分析，之后基于对战略目标业务能力需求与当前业务问题及差距分析，进行TO-BE业务架构设计，并根据未来业务架构的需求构建对准支撑的TO-BE应用架构与数据架构。TO-BE架构设计完成后，根据TO-BE业务架构和TO-BE IT架构设计形成详细的实施工作包（迁移规划）以及实施路线，指导具体的组织变革、流程改进以及IT系统建设，支撑驱动AS-IS架构到TO-BE架构的演变，进而完成架构落地。见下图。
通过上面的详细的技术路径，我们实现了针对TOGAFADM开发方法的细化，并从业务架构出发，以业务架构中的业务服务为接口，衔接业务架构和应用架构；以业务对象为另一个接口，衔接业务架构和数据架构。从而保证了应用架构和数据架构的设计起点是在业务架构的设计结果的基础上，逐步推导形成的。这种从业务架构开始，分析细化至应用架构和数据架构的技术路径，是在项目中对TOGAF ADM的补充和细化，我们称之为“W模型开发方法”。
在上面的架构项目技术路径基础上，项目又详细设计了各阶段应形成的架构制品，以及各项制品之间的联系，作为对TOGAF内容框架的细化和补充。见下图。
由于篇幅所限，本项目虽然是一个完整的从战略到业务架构，再到应用架构和数据架构的完整实践案例，但本文不再详述业务架构和数据架构的具体设计方法。感兴趣的朋友可以参考本系列的其他文章了解相关内容。
在应用架构开发过程中，本项目又提出了应用架构的“设计-调整-迭代”三步实施方法。因为无论多么资深和经验丰富的架构师，都不能担保应用架构设计结果的一次性正确，这就需要用科学的方法不断开展校对和验证，通过架构迭代逐步完善架构成果，最终达成满足各级利益攸关者需求，并在组织范围达成一致。见下图。
按照上述总结的应用架构设计方法，应用架构可以用逻辑上的应用和应用组件来定义组织完整的应用逻辑蓝图。
应用组件（ApplicationComponent）是满足业务服务需求的模块化、可部署、可重用、可替换的组成单元，封装了行为和数据等实现过程并提供了一系列可用的接口，可独立运行、独立部署，应用组件可嵌套。
应用（Application）是为了满足IT治理需要，在逻辑层面根据特定业务需求确定的应用组件/应用功能的组合边界，应用中所包含的应用组件之间存在较高级别的互操作性，一个应用承载选型、实施、部署等方面的治理要求。在实现层面，应用可以与软件系统实体对应。
那么具体是如何从业务架构推导出应用架构的呢？见下图。
本项目还结合TOGAF架构制品的要求，完成了应用交互矩阵开发，并针对发现的问题进行了改进。
还完成了应用架构和数据架构的分析制品，如应用数据交互矩阵，也称UC矩阵，并针对发现的问题进行了改进。
最终以TO-BE业务架构为基准，参考行业典型参考模型，设计形成组织联盟层、组织管理层、生产管理层、控制执行层四层结构的应用架构，并基于AS-IS应用架构给出了迁移规划。
本项目中还详细介绍了应用架构原则的设计技巧，以及针对业务架构的缺陷项分析、冗余性分析、白盒测试（应用组件依赖性分析）和黑盒测试（应用逻辑场景分析）等内容。
如果想进一步了解本项目详细技术路径、实施过程、架构制品等内容，请关注企业架构实践案例系列课程。