CIO 如何制定低代码 / 无代码战略
低代码/无代码平台有可能改变应用的创建方式,让最接近客户和业务用户的人,能够更好地交付解决方案和用户体验,并且将所需技术团队的干预降至最低。
有一个令人担忧的预测:到 2025 年,全球范围内 IT 技能匮乏、导致无法解决紧迫业务难题,这家导致每年高达 3900 亿美元的损失。而低代码/无代码(LCNC)是解决这些难题、缓解由此给 CIO 们造成负担的项目积压问题的关键解决方案之一,而且现在正是一个很好的时机。
低代码/无代码平台有可能改变应用的创建方式,让最接近客户和业务用户的人,能够更好地交付解决方案和用户体验,并且将所需技术团队的干预降至最低。
全球各地的 CIO 们都对低代码/无代码带来的机会感到兴奋,他们相信,低代码/无代码可以提高敏捷性,缩短实现价值的时间,减小技能差距和 IT 面临的压力。然而,有近四分之一的 CIO 仍然害怕影子 IT 问题猖獗,以及由此可能给安全性和解决方案质量产生影响。
这些担忧背后最可能的原因是,这些组织尚未调整好他们的运营蓝图和运营能力以完全接受和利用低代码/无代码所能实现的分布式创新。
许多企业仍然在努力采用敏捷性和 DevOps 来加速软件开发生命周期,因此低代码/无代码提供了比以往任何时候都快得多的交付速度。
低代码/无代码需要新的运营模式
CIO 们要充分利用低代码/无代码平台,就需要采用与该技术潜力相匹配的新运营模式,而且这些运营模式必须平衡好创新、稳定和扩展的需求,不仅仅是对业务,还要对于技术,因为所有这些都是会同时发生的。
实现自助服务式的“全员皆可开发”,将让 CIO 能够赢得业务和现有专业代码开发者的青睐。
CIO 及其 IT 组织需要成为关键业务变革和创新的推动者,而不是充当技术守门人,在这个新环境中,企业及其技术团队可能有四种不同的运营模式:
草根开发者可以解决客户体验问题,同时还是产品 Scrum 团队的一员(主要是草根开发者主导的交付)
由草根开发者领导的 Scrum 团队可以改善业务用户的生产力
由专业代码 Scrum 团队和创新推动者提供的企业控制和服务(IT 主导的交付)
自助服务式解决方案实现 Scrum Master、站点可靠性和发布工程师体验(主要是 IT 主导)
基于这些运营模式,CIO 将可以因为能力被划分为不同类别而从中受益,尤其是那些面向客户、企业或者部门的能力。
这种分类有助于确定最适合交付每个部分应该有怎样的团队构成,例如 IT 组织内新授权的草根开发者和专业代码开发者之间应该如何更好地进行组合。
CIO 们还需要创建新的参与模式,实现 CISO 和首席数据官之间在安全和数据治理方面展开更好的协作,还有那些走在满足客户需求前沿的、精通技术的业务用户。
如今,“业务”和“IT”之间的界限正在迅速消失,那些有远见的 CIO 们有机会重新思考他们应该如何与其他组织展开,以及如何领导他自己的组织。合作和领导他们的组织。低代码/无代码不仅是实现更高生产力的关键因素,也是更快实现目标的一条途径。
首先,CIO 和其他技术领导者应该:
实施新的运营模式
开始将草根开发者纳入 Scrum 团队,但将团队明确划分为专注于用户体验的团队,和支持创新(如端点创建)的团队。
为确保顺利交付,在业务层面培养一个新的解决方案架构师和项目经理小组,让他们负责监督那些基于低代码/无代码的创新。
对技术组合进行细分和合理安排,以适应新的模式
首先对那些迁移到低代码/无代码模式的现有应用进行评估,然后围绕 AI、机器学习和移动体验定义一个支持云的产品组合,打造出一些基本不需要投资、不需要专业代码开发者的解决方案。
划拨预算支持低代码/无代码创新
现有的低代码/无代码平台仍然存在可能导致解决方案使用高流失率的缺点,这主要是因为企业的期望与平台提供商的优先事项之间是存在脱节的。
而且,负责并推动平台供应商公开更多平台内部运作情况(例如了解自动代码是生成的、工作流重新启动等)是符合 CIO 最大利益的。
另一个重点应该是推动支持草根开发者以及简化安全问题。
随着时间的推移,这些运营模式需要不断发展演进,以平衡专业代码开发者和草根开发者所构成的组合,与此同时,CIO 也需要与平台提供商展开合作以推动平台的成熟度。
早期精力应该集中在积极推动安全 API 端点(边缘、SaaS、企业核心)的增长,为由外而内的体验和由内而外的流程交易创建框架,增强平台的可支持性。
咨询热线:+86 400-966-9672
评论