English 服务热线: 400-610-7333

数字化转型,为什么一定要谈“架构”? 2024-04-01 15:12  作者或来源:36Kr

在从事数字化转型的实践过程中,我们发现,企业数字化转型总是离不开关于企业架构的讨论。

所谓转型,其实是转的企业整体,是对企业组织、业务、技术形态的系统化重塑,数字化项目可以通过局部试点迭代演化,但是必须是在特定的顶层设计框架下循序渐进地执行。

数字化转型的本质不是it外包或技术研发,而是管理咨询与实施。

数字化转型的对象是企业,也不是某个技术设备或it系统。

因此,讨论数字化以及开展数字化转型工作,必须以企业架构为抓手,把架构作为一张地图,变设计边做,直至达到所期待的转型战略目标。

架构关乎决策!

没有架构,就找不到转型的方向。同时,缺少架构支撑也很难有效洞察到转型中真正的本质问题。

没有架构的it设计,就像脱缰的野马,迟早会失去控制,很多项目到最后都会变得南辕北辙

通过架构可以告诉我们,技术和业务,以及企业的经营战略目标,到底是一种什么样的影响链路或支撑关系。

通常来说,企业架构包含四个层面的含义,分别是业务架构、应用架构、数据架构以及技术架构。

其中,业务架构对应业务域的需求逻辑,主要描述数字化系统所支撑的业务场景。

业务架构中规定了为达到某个业务目标的具体业务流程,所有的业务相关者的全责关系,也在业务架构中有所指明。

简单讲,业务架构可以回答我们到底为什么(why)要做数字化转型。

而应用架构、数据架构、技术架构属于信息域,表示如何实现业务域需求的it建设框架逻辑,信息域的结构其实回答的是如何做(how)数字化转型的问题。

数据架构是支撑业务流的数据模型、数据流关系,以及相应的数据处理逻辑,从数字孪生的角度来说,数据架构是和业务架构的直接映射对象。业务架构中的要求,都在数据架构中直接反映。

从业务架构到数据架构,就是业务需求到数据需求的关系。

而类似地,应用架构是指软件应用方面的需求,技术架构是支撑软件应用的物理层技术组件需求,二者共同来完成数据架构定义的内容。

不同架构之间彼此互为约束。在建设任何数字化项目时,只要满足特定的架构遵从,就能保证需求不跑偏。

值得注意的是,无论是业务架构还是数据架构、应用架构,都是企业级的需求设计环节,而非项目级的。

一旦提到架构,一定是在谈论一个比较宏观的视角,也正是基于这个原因,架构的背后是跨组织、跨业务、跨场景、跨周期、跨领域、跨系统,换句话说,一定是一个开放的技术生态。

很多时候,企业在构建一个数字化系统时,就要在这个架构的边界内来完成,很多it系统之间的关系以及系统之间的数据流逻辑,也都是受制于架构的约束。

因此,架构除了指明方向,定义需求之外,还能帮助我们理解一些日常看似困惑的软件体验:

比如,很多在线业务明明可以在一个系统中顺序操作完成,但是经常需要很麻烦地登录不同的终端,分别填报不同部分的信息来实现。

从用户体验的角度来说系统亟需整合,优化服务流程,但是为什么现状是冗余的呢?

背后的原因并非是软件设计者或者开发者的局限,而是业务流(业务架构)的约束所致。如果业务域不能得到优化,那么信息域做再多的改进也是无用甚至徒劳的。

从架构的视角,我们更加深刻地理解,为什么说数字化转型其实转的是业务,而不仅仅是技术手段!业务,才是最后一公里关注的问题,也是一切数字化活动开启的缘起!

本文来自微信公众号大话数字化转型”(ID:dataminingxmz,作者:数字化刘老师,36氪经授权发布。

该文观点仅代表作者本人,36氪平台仅提供信息存储空间服务。

 

 

 

 

服务热线:400-610-7333 | 邮箱:service@gpos.cn | 电话:8610-82564561/71 | 传真:8610-82564561-8025 | 京ICP备18017976号 | 京公网安备 11010802036102号 Copyright © 2005-2024 Beijing Golden Point Outsourcing Service Co., Ltd. All Rights Reserved. | 北京金支点技术服务有限公司保留所有权利。