企业的数字化转型实践中，笔者一直坚持的原则就是“先业务后IT”，也就是IT要对准业务，IT是承接业务及业务战略的。要做数字化转型，要有整体业务视角，也就是业务架构，架构就是数字化思维，只有业务架构先行，IT架构才能做到有的放矢。
业务架构与IT架构的关系，我们从下图可以窥见端倪：
见笔者前面发的文章>>业务架构沉吟至今的几点思考，如果纯粹谈IT，不是从业务角度分析与设计IT蓝图，只会是变成IT部门的自嗨。
从最近经历的数字化项目，笔者感悟颇深，明显感受到传统企业对数字化的认知、转型路径与方法论的认知上与数字原生企业尚存在着较大的差距，这个正确认知的建立还有很长的路要走。拿业务架构来讲，上到企业高层、下到各级管理者，甚至数字化相关带头人，均未形成对业务架构的正确认知，更别谈业务架构在数字化转型中的决定性的引导作用，甚至直接跨过业务架构就着手开始设计应用架构。
如何做到IT对准业务？还是从企业架构说起。
企业架构（Enterprise Architecture，EA）是对组织复杂度及其变化演进过程进行掌控的顶层方法。是组织的逻辑蓝图，基于背景环境建立组织的完整性、多层次一致的结构化描述。
企业架构始终强调两个对准，即业务对准战略，以及IT对准业务。
应用架构是IT对准业务过程中的重要环节，但是很多企业在数字化转型实践中往往对应用架构设计存在以下误区。
首先，把应用架构等同于应用系统架构或软件功能架构，甚至是组织当前已经部署的IT系统的罗列。我曾经见过很多组织开发的应用架构，都是从当前的IT系统出发，设计面向未来的IT系统迁移路径。这种方法没有从根本上解决组织应用的整体架构设计，更谈不上任何与业务架构的对准。
其次，直接开展应用架构设计。应用架构设计的目标是通过搭建逻辑上的应用蓝图，实现应用对业务的支撑和覆盖，确保业务与IT之间的衔接和对准。如果不从业务架构出发，甚至组织的业务架构没有全面解构，甚至都没有建立，就开始着手设计应用架构，那么应用架构的设计原则和面向未来的应用架构就无从谈起。
第三，应用架构是IT部门的事。这种情况往往存在于IT部门在组织内话语权不强的时候。当组织要开展架构工作，应用架构和数据架构就会被定位为信息化部分的任务，使得应用架构往往得不到很好的论证，变成闭门造车，最后无法达成一致取得共识，也起不到承接业务架构和战略的目的。
事实上，应用架构是业务人员和IT人员都要参与的工作，作为一名IT Leader和企业架构师既要懂业务，还要懂IT，怎么才算懂业务，最起码也要对企业当前的业务架构进行整体解构与研判，这是很重要的一步，现实中，很多IT Leader会直接跳过这一步。当项目要做应用架构设计蓝图与细节时，IT Leader或企业架构师需要领导组织内部的业务和IT人员充分讨论与协调，绝不能把业务和IT进行割裂分开进行设计。尤其是业务流程设计与应用架构设计在数字化项目上应密切互动与通力协作，这样流程建设成果通过应用架构进行落地，可以做到有的放矢，不至于工作感觉不接地气，应用架构就有了准确的输入，架构蓝图才具有可落地的灵魂。
总之，按照架构的正向设计的方法，以“业务与战略对准，IT与业务架构对准“为指导原则，充分认识到业务架构的桥梁连通作用，通过业务架构推动业务与技术的深度融合，应用架构向业务架构看齐，以保证业务、应用、数据的上下贯通，从逻辑上确保业务架构到应用和数据架构的技术路径正确性。
从笔者长期的实践经验来看，企业级业务架构的设计与落地，影响了参加过业务架构设计的业务人员、技术人员，他们的逻辑思维能力、结构化能力、企业级观念和意识、数据思维、业务思维、技术思维，业务与技术融合思维，均发生了明显的改变与提升。所以，业务架构应当上升为企业战略高度，更多地面向业务人员、业务管理者及流程管理者，充当业务与技术之间的桥梁，部门与部门之间的桥梁。当然，业务人员、流程管理者、尤其是企业高层人员应该坚持业务架构理论知识的学习与实践，坚持使用业务架构方法做企业级需求管控，所谓“不谋全局者，不足谋一域”。唯有持续坚持业务架构的思想，才能站在企业全局的高度思考问题，给出更科学的解决方案，整个系统运行才能更加高效顺畅，同时也能杜绝“熵增”将已建好的架构秩序和IT系统回归到混沌状态。
关于企业架构，请翻阅往期文章：
5602
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
