数字化转型背景下的应用架构变革思考

字数 2140阅读 1843评论 0赞 3

内容摘要：

数字化转型下，应用架构变革需考虑客户对业务和应用架构的认知问题。研发管理需从信息化向数字化演进，实现业务价值为核心，技术标准化屏蔽复杂性，低代码开发平台需尽可能屏蔽底层技术细节。

当前摘要为AI生成

最近很多项目都涉及客户的业务和应用架构的规划，跟团队也在一起讨论应用的架构演进问题。虽然我们总说，战略决定架构，以需求为核心的架构规划，是要从业务入手，统筹考虑应用和数据架构，从而决定IT架构。这话本身没错，可是我越来越发现我们忽略了一个重要问题，那就是客户对业务和应用架构的认知问题，做IT规划的觉得这事管理咨询和客户自己应该厘清的，做管理咨询的认为这事IT规划和客户业务部门的事情，结果导致谁都不会静下心来认真思考这个问题。我们太过于习惯性的看重管理咨询和IT落地规划，总是忽略中间这部分。

一、碰到了哪些问题

1、传统模式遇到困境

在传统模式下，我们的业务侧是粗放管理的，业务团队单独考虑自身的业务逻辑，进行了大量的重复建设，这种重复建设往往是基于单体架构的。在这种情况下，重复建设导致的成本、效率问题和数据不一致问题一直困扰着我们，这些问题用一个词来概括可能会更凝练，那就是效能。于是我们接受了服务化和中台化的理念，试图寻找突破口。

2、中台和服务化也不是桃花源

我们用中台理念对业务侧做了调整，形成了以中台为核心的业务架构， 中台的核心是“重用”，重用是一种通用逻辑，但是我们会发现只有通用逻辑是解决不了问题的，还需要制度的定制，也就是个性化逻辑。这就会出现一个问题，中台所代表的通用逻辑与前台所代表的个性化逻辑会出现节奏不一致的情况，需要在协同、排期、优先级等问题上作出协调和平衡，存在巨大的沟通成本，这是一个新问题。

伴随着应用架构的演进和中台的发展，我们做了大量服务化改造，形成了很多新的服务。这在技术上也带来了很多新问题和新风险，比如调用链开始变长，运维难度变大，排障变得困难，组件的使用成本开始上升。尤其是到了paas层面，如何使用好众多服务，是一个必须面对和考虑的问题。

在业务、应用、数据的数量和复杂度都快速增长的一个大背景下，解耦是我们始终需要考虑和面对的一个问题。

我做业务和应用的架构变革，如果只从架构升级改造本身出来，就会有点“头疼医头脚疼医脚”的意思。从上分析可以看出，我们的症结都指向了一个问题，那就是研发管理。

二、研发管理需要从信息化向数字化演进

1、从信息化走向数字化

当前阶段，研发管理的主流模式已经实现了信息化，基本告别了小作坊时代，通过平台和工具的使用，主要实现了项目协作、应用开发、交付部署等等几部分功能。项目协作主要解决工单管理和流转以及知识沉淀等，应用开发主要是通过工具的提供完成各工种工作，交付部署主要是把成果发布上线交付运维。

传统的做法是基于工具和流程管控的模式，只是用工具代替了人工，从本质上说还是人为核心的。 我们好像更关注过程而不关注这些过程所产生的数据对企业的价值。我们一直说的业务数字化，在这方面没有得到体现。这些信息和数据成为了一个一个孤岛散落在各流程和各环节。因此打破研发管理层面的数据孤岛，是解决研发管理数字化的关键。

工具和平台的使用实现的是流程管控，解决的是局部效率的问题，尤其是资源调度的效率，但这并不代表整体交付效率的整体提升，我们要做的是从工具流程为核心向业务价值为核心转型。这可能不好理解，容易走向务虚。简单说，应该分成三步走，第一是局部效率的提升，重点还是大量自动化工具的使用以及过程数据的积累和沉淀；第二是实现整体高效交付，核心思想是实现业务、产品和研发的目标一致化，通过数据实现过程整体可控；第三是实现持续改进，主要是根据可视化的结果，进行可量化的持续改进。这里面关键就是数据链接到研发的价值链管理上去。

2、以技术标准化屏蔽复杂性

传统应用和研发过程，需要从物理基础设施开始关注，从设备类型、资源提供方式、中间件选型到技术路线和架构方式都需要逐一落实，也就说技术关注平面是在物理基础设施这层，这层之上的东西都要关心。

随着新技术的使用，确切的是通过技术标准化实现了资源到服务的转换。虚拟化和云屏蔽了资源类型的差异，从差异化的物理资源统一成了标准化的云资源，Paas和分布式基础环境实现了中间件层的标准化，DevOps实现了开发环境的统一和标准化，智能运维实现了运维监控的整合和标准化，也就是说云原生应用构建了一个新的技术关注平面，我们不用再去关心各种资源的细节和差异性。不断推进技术的标准化建设，推动IT从资源建设向服务提供转型，这也是持续提升研发整体效能的关键手段。

3、说说低代码研发

有人说低代码研发是潮流，很多客户也在关注。 希望通过研发工具和平台已经抽象出来的一些通用代码，通过可视化的操作快速创建所需的功能组件，加快软件研发的进度。这无论对客户还是软件开发商来说都是好事，也是提升效率和效能的重要手段。 其实无论低代码还是0代码，都是APaaS的范畴，是应用全生命周期的一个环节，但是代码量的降低，并不意味着工作量的降低，这对业务架构和应用架构的灵活性和敏捷程度提出了更高的要求，所以说架构还是永远都是第一位的。

从这个角度来说，低代码开发平台应该为开发者尽可能屏蔽底层技术细节、减少不必要的技术复杂度，并支撑其更好地应对业务复杂度，满足灵活通用的业务场景需求，这是一个低代码开发平台所应该尽到的核心职责。

数字化转型应用架构

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

数字化转型背景下的应用架构变革思考

添加新评论0 条评论

文章目录展开目录

作者其他文章

相关文章

相关问题

相关资料