成功的数字化转型需要来自内部的破坏,想要拥抱数字化未来的首席信息官们必须经常改变他们的IT运行模式才能实现这一点。没有什么比开发软件和服务更为明显的了。
为了更快地构建软件,首席信息官们开始放弃旧的瀑布式的习惯,转而采用敏捷方法,同业务利益相关方合作,用迭代冲刺的模式更快地构建应用程序。而有一些人则相信通过采用一种名为DevOps的新兴哲学,他们甚至可以进一步加速软件开发工作。
DevOps是“开发”和“运营”的混搭,描述了实现敏捷开发和可扩展运营所需的组织结构、实践和文化。DevOps使软件组装自动化,利用持续集成、开发和部署,改善客户体验,更快地响应业务需求,并确保创新与安全和运营需求相平衡。你可以将DevOps视为使用了类固醇的敏捷开发。
它正在迅速蔓延。Forrester Research的调查显示,在237个接受调查的机构中,有50%的机构表示他们正在实施DevOps。分析师Robert Stroud在研究报告中写道:“DevOps的发展势头正在蔓延至所有的行业。”他表示,“由于我们即将迎来2017年年底,越来越多的询问集中在组织能够如何在压力下成功地提高应用程序和服务的交付速度上——而且不能增加人手。”
由于组织孤岛、文化障碍和变革管理等问题,向DevOps的过渡绝非易事。来自Intuit、大都会人寿(MetLife)和Red Hat的IT高管们介绍了他们在DevOps变革方面的经验,并为希望拥抱DevOps的首席信息官们提供一些建议。 向DevOps转变
对于一家拥有4500名开发人员、而且他们都已经习惯了瀑布式工作方式开发应用程序的软件制造商来说,融合网络安全和DevOps可不是一件容易的事。但是,对于Intuit的DevSecOps总监Shannon Lietz来说,这是她的首要任务。Lietz表示:“这是一种文化上的转变。”她表示:“越是接近客户,开发人员、公司里的其他人的经验就愈加丰富,你的客户也是如此。”
Lietz表示:“科学的奉献精神使DevOps现实可行并取得成功,而我发现试图将科学引入公司是非常困难的。”她表示, “这是一种完全不同的进行方式。”
对大都会人寿(MetLife)而言,引入DevOps与创新携手共进。Alex Seidita是这家拥有150年历史的保险公司的首席技术架构师,Alex表示,在过去几年里,大都会人寿(MetLife)在开始采用DevOps的同时还采用了来自微软和IBM的云服务,并使用了来自Docker的容器技术。
大都会人寿(MetLife)的ModSquad是一个由工程师、网络专业人员和开发人员组成的创新团队,这个团队已经接受了云计算、敏捷开发和DevOps,采用了“快速学习、快速失败、快速交付”的模式。ModSquad的口号是:“你不用等到自己知道了所有的事情之后才开始动手。”
对于容器、微服务和其他工具宗教般的狂热,让Mike Kelly 于2016年8月在DevOps的诱惑下加入了Red Hat。曾在McKesson 担任首席信息官的Kelly厌倦了首席信息官是如何演变成为软件卖家的过程,因此在离开这个职位之后,加入了这家开放源代码软件开发企业。
Kelly表示,企业首席信息官们采购打包软件以确保流程效率,并管理与这些应用程序相关的变化。但是,首席信息官们的手脚被定制软件束缚了,这些定制针对的是太过独特或者难以改变的流程。
在McKesson引入DevOps的Kelly表示:“我总是觉得自己能够完成这些大项目,会有一些人并不开心。” Kelly表示:“有了这些(DevOps、敏捷开发和文化变革),我们现在拥有了众所周知的工具箱中的工具,可以帮助我们解决这些长期以来一直存在的问题。” 实施DevOps的十二个最佳实践
根据他们在向DevOps过渡过程中的亲身实践经验,Lietz、Seidita和Kelly提供了以下建议,以保障DevOps的成功。
将DevOps战略与业务结合起来。确保IT和业务战略的一致性是首席信息官们共同的责任,这一点对于DevOps来说同样重要,如果IT和业务不能够保持一致,项目就会失败。Lietz表示:“如果你不这样做,那你就只是在创造惊喜”——而且很有可能是不受欢迎的“惊喜”。
切入现有的项目。不要将DevOps作为一个独立地科学项目;相反,把它插入到现有的项目中,这样它就有责任遵从通常的交付截止日期。Seidita 表示:“选择一个、两个或三个项目,你可能会冒一点风险,但时间并不是无限的。”Seidita表示:“你希望人们能够冲刺,并最终将结果投入生产。”
心胸宽广。要想让DevOps发挥作用,文化是至关重要的。Seidita表示,要尽可能地包容,这样你就可以“改变心灵和思想”。Seidita补充表示,非常重要的一点是不要排斥人,因为这可能会造成问题。“你必须心胸宽广并且非常包容,这样人们才会觉得他们参与了这段旅程,并为之做出了贡献。”
聚焦让你独一无二的东西。在选择实施项目的时候,要选择那些能够增加价值,并让业务变得与众不同的项目。Kelly表示:“不要试图在你的核心ERP系统上实施DevOps。”
选择经过验证的平台。工具是DevOps的另一个重要组成部分。从配置管理到持续交付平台,选择具有知名网络的工具。Kelly表示,把赌注押在未知的平台上会带来风险。
尝试在内部培养技能。市场上没有足够的DevOps人才,因此你应该吸引整个组织内部有经验的人才。让他们为项目做出贡献。Lietz表示:“他们可以给你一个滚动条来看待事情。”她表示,Intuit研究了“无边界领导”,管理者可以从公司内部抽出自愿参与的团队成员。更多的时候,他们同意提供帮助,是因为他们知道自己正在从事的工作是业务战略的一部分。
避免“划分等级”的问题。许多组织都有喜欢冒险的工程师,他们致力于新兴技术,也会有一些维护传统技术(例如ERP系统)的工程师。这些酷酷的冒险者可能会招致怨恨。Kelly表示:“你必须非常认真地同你的同事进行交谈,向他们解释说这并不是非黑即白的问题。”他说,在传统环境中工作的员工和那些实施DevOps的员工是同等重要的。
时间永远是一个重要因素。不要低估时间的重要性,特别是那些每个季度都要公布财务报告的上市公司。Lietz表示,公司必须致力于为特定的季度创造价值,并让每个利益相关方都专注于学习开发渠道的一部分。IT和业务利益相关方都应该学习,以确保任务和结果之间的一致。
不要看得太远。鉴于DevOps的高速度,一些组织可能会试图解决在遥远的未来才会出现的问题。这可能导致他们错过迭代创造价值的机会,甚至会导致产品召回,浪费每个人的时间。
拥抱故事写作。把它看成是为客户创造价值的蓝图。它从一个动词开始,例如“启用”一个特定的产品功能,以使其变得更加安全。Lietz表示,如果你无法创建一个故事线来描述你计划如何满足你的客户的需求,你可能就不会打造出最好的产品。
避免官僚主义。官僚主义可能会成为DevOps杀手,特别是在那些已经围绕着接订单建立了成熟规则的IT组织中更是如此。Lietz表示:“不要相信有一个方法可以做出决定。” Lietz表示:“实验是关键,一旦你在DevOps融入了官僚作风,DevOps就会失败。”
迭代学习。确保员工为踏上这段旅程做好了准备并且犯下一些错误。Seidita表示:“不要把它们与严格的财务模型联系起来,那样的话你就需要在今天告诉我明年你打算花多少钱。”“要一点点来。” 原创: 记录数字化创新的
|