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