所谓转型，其实是转的企业整体，是对企业组织、业务、技术形态的系统化重塑，数字化项目可以通过局部试点迭代演化，但是必须是在特定的顶层设计框架下循序渐进地执行。
数字化转型的本质不是it外包或技术研发，而是管理咨询与实施。
数字化转型的对象是企业，也不是某个技术设备或it系统。
因此，讨论数字化以及开展数字化转型工作，必须以“企业架构”为抓手，把“架构”作为一张地图，变设计边做，直至达到所期待的转型战略目标。
架构关乎决策!
没有架构，就找不到转型的方向。同时，缺少架构支撑也很难有效洞察到转型中真正的本质问题。
没有架构的it设计，就像脱缰的野马，迟早会失去控制，很多项目到最后都会变得“南辕北辙”。
通过架构可以告诉我们，技术和业务，以及企业的经营战略目标，到底是一种什么样的影响链路或支撑关系。
通常来说，企业架构包含四个层面的含义，分别是业务架构、应用架构、数据架构以及技术架构。
其中，业务架构对应业务域的需求逻辑，主要描述数字化系统所支撑的业务场景。
业务架构中规定了为达到某个业务目标的具体业务流程，所有的业务相关者的全责关系，也在业务架构中有所指明。
简单讲，业务架构可以回答我们到底为什么(why)要做数字化转型。
而应用架构、数据架构、技术架构属于信息域，表示如何实现业务域需求的it建设框架逻辑，信息域的结构其实回答的是如何做(how)数字化转型的问题。
数据架构是支撑业务流的数据模型、数据流关系，以及相应的数据处理逻辑，从数字孪生的角度来说，数据架构是和业务架构的直接映射对象。业务架构中的要求，都在数据架构中直接反映。
从业务架构到数据架构，就是业务需求到数据需求的关系。
而类似地，应用架构是指软件应用方面的需求，技术架构是支撑软件应用的物理层技术组件需求，二者共同来完成数据架构定义的内容。
不同架构之间彼此互为约束。在建设任何数字化项目时，只要满足特定的架构遵从，就能保证需求不跑偏。
值得注意的是，无论是业务架构还是数据架构、应用架构，都是企业级的需求设计环节，而非项目级的。
一旦提到架构，一定是在谈论一个比较“宏观”的视角，也正是基于这个原因，架构的背后是跨组织、跨业务、跨场景、跨周期、跨领域、跨系统，换句话说，一定是一个“开放”的技术生态。
很多时候，企业在构建一个数字化系统时，就要在这个架构的边界内来完成，很多it系统之间的关系以及系统之间的数据流逻辑，也都是受制于架构的约束。
因此，架构除了指明方向，定义需求之外，还能帮助我们理解一些日常看似困惑的软件体验：
比如，很多在线业务明明可以在一个系统中“顺序”操作完成，但是经常需要很麻烦地登录不同的终端，分别填报不同部分的信息来实现。
从用户体验的角度来说系统亟需整合，优化服务流程，但是为什么现状是冗余的呢?
背后的原因并非是软件设计者或者开发者的局限，而是业务流(业务架构)的约束所致。如果业务域不能得到优化，那么信息域做再多的改进也是无用甚至徒劳的。
从架构的视角，我们更加深刻地理解，为什么说数字化转型其实转的是业务，而不仅仅是技术手段!业务，才是最后一公里关注的问题，也是一切数字化活动开启的缘起!
