“AI 技术+人才”如何成为企业增长新引擎?戳此了解>>> 了解详情
写点什么

你是创新的阻碍吗?

  • 2018-09-28
  • 本文字数:3619 字

    阅读完需:约 12 分钟

关键要点

  • 文化决定了风险规避和变革阻力。
  • 不应该基于是否有助于抓住现有市场而做出决定,而应该要关注下一步可能出现的情况。
  • 抓住从失败中吸取教训的机会。努力分担责任,设定切合实际的期望,并履行现有承诺。
  • 降低单个失败导致整个行动崩溃的风险。
  • 在内部培养一种以服务为中心的精神。

我们的行业时刻在发生变化。但是改变很难的——特别是当你已经建立了一套强大的已经可以满足客户需求和业务目标的工具和系统。随着企业寻求进入新市场或满足客户新目标的机会,现有的架构将面临严峻的考验。“当我们采用 N 层方法时,就等于是采用了一种灵活的架构。SOA 被认为是能够为我们带来更大灵活性的架构。我们怎么知道采用微服务不会让我们在未来五年内回退到原来的状态?”

在商业领域,特别是在当今快节奏且越来越依赖科技的世界中,关于这一主题存在很多指责和嘈杂的声音。一般的诊断是“老卫兵”,特别是在 IT 领域,变革很难。我参加过无数次会议,每当有人意识到让 IT 团队参与进来需要付出多大努力时,成功的好主意和潜在方法就会被迅速否决。

传统的 IT 团队掌握了现有系统的大部分知识,这给了他们大量应得的尊重和权威。但如果 IT 不拥抱变化,这种情况就不会发生。这对创新来说是一个不可逾越的障碍。

根据我的经验,最好的 IT 人员善于规避风险和抵制变化,因为他们的首要任务是保持一切正常运转。因为技术发展十分迅速,很多 IT 团队发现自己被快速变化所驱使,而过度谨慎可能是反身的。拥抱变革并保持运转的能力在很大程度上取决于所服务机构的性质。很多 IT 团队都被上层管理人员反复无常的想法所淹没,管理层希望他们不仅能够掌握市场上几乎所有技术的专家级知识,而且无论发生什么,都能保持数据流动。如果没有坐在角落里的憔悴的运维人员,没有一个技术供应商会议会是完整的。

组织就像船只——较小的组织可以更灵活,并且可以根据需要快速改变路线而不会有太多麻烦。较大的组织像游轮一样,无法灵活转向。他们需要相当多的精力和计划来进行彻底的改变。这一切都是关于动量守恒和水的摩擦力。以极快的速度改变路线对公司来说是很困难的——就像对人一样,它也会导致混乱。但在这两种情况下,稳定变革进程都应该是可行的和舒适的。

在上面的比喻中,构成水(及其伴随的摩擦)的很大一部分是文化——整个公司的文化,以及在其中发挥作用的亚文化。例如,运维人员对变革有抵抗力,因为他们的绩效不是通过创新来衡量,而是通过性能和正常运行时间来衡量。这培养了一种重视现状的文化。随着这种现实向开发人员转移,你会发现他们的文化变得越来越关注破坏构建过程。这不一定是坏事:它鼓励团队进行强壮的测试并写出更好的生产代码。但是,在新的业务需求或紧迫的最后期限中,即使对于曾经随心所欲的开发者来说,变更阻力也会变得更大。有时候,更明智的做法是坚持安全的做法,避免可能带来风险的创新。

风险规避融入到文化中,通常反映在结构、未说出口的价值观以及支持它的架构上。这种架构非常冗余,通常存在于由组织控制的数据中心内,并处于安全层和抽象层的保护之下。目标是为了保持稳定,但代价却是停滞不前。

对额外复杂性的担忧也会导致规避尝试新技术的风险,即使对于小型非关键项目也是如此。通常,这些项目可以发展成其他系统所依赖的核心功能。具有敏捷思维模式的组织将隔离此类系统,并在 API 背后抽象其功能,但传统的 IT 运营更愿意完全避免它们,因为它们需要知识依赖性,这会让招聘流程复杂化,并增加团队获得专业知识的工作量。这通常会导致扭曲当前的系统和编程语言,用以满足不合时宜的需求,例如使用 cron 脚本运行 Java Applet 来旋转日志。

当市场发生变化时,需要花费更多的时间、精力和成本来拆解这些架构。我们都看到各个领域的领导者落后于更灵活的竞争对手,这要归因于多年来在在系统和态度方面积累的风险规避层(并且具有讽刺意味的是,这样做事为了保持竞争优势)。这就是颠覆的本质。

你无法采用单一架构来解决这个问题。多年来,N 层架构打破了单体大型机,引入了应用程序和数据级的冗余,可伸缩和面向服务的架构解决了分布式代码库所带来的挑战。今天,微服务和 FaaS 架构(例如 AWS Lambda)被誉为最终解决方案,勤劳的组织开始跟风,将这些原则应用于他们的系统上。

这是一种“盲目崇拜”——模仿大公司的最佳实践,盲目地应用它们,并期待同样能够出现奇迹般的效果。在最好的情况下,这样做可能可以带来一点点帮助。在最糟糕的情况下,它会使工作环境变得更加恶劣,因为组织将一组严格的实践替换为另一组,在应用这些原则时通常并不完全理解其目的或如何适应组织的独特需求。

最好的组织是那些将敏捷作为核心价值和目标的组织。不应该基于是否有助于抓住现有市场而做出决定,而应该要关注下一步可能出现的情况。不要试图去预测未来,而是开展“假设性”游戏(如果……会怎样)。

例如,如果可穿戴设备卷土重来会怎样?这对你的企业来说意味着什么?机遇在哪里?你当前的架构将如何解决它?要做到这一点你需要做些什么?

我经常使用 API​​作为回答这个问题的答案,而且有充分的理由。精心设计、管理良好的 API 与特定用例相分离,彼此独立运行,并且能够单独扩展,帮助创建数据访问环境,以便在出现新技术时快速适应新技术。但 API 只是最终能够决定成功的大系统上的一个很小的层。

文化往往比技术更重要。你奖励成功并惩罚失败吗?更有前景的敏捷是庆祝成功、分析失败,并要求组织对每个人进行批判性研究,以便推动整个组织向前发展。这也意味着,如果你只能提供两个 9 的可用性而不是七个,并让你的系统可以优雅地处理停机时间,是可以被宽容的。

这与 Facebook 早期的口头禅“快速行动和颠覆”不同——他们上市后就放弃了这个口头禅。这是一个鲁莽的口头禅,他们也只是部分遵循。相反,我的建议是“刻意移动,拥抱失败并从失败中吸取教训”。可能看起来不那么吸引眼球,但确实是一种更现实的操作方式,可以促进增长并改进你的开发和部署过程。

当然,不要因为一粒老鼠屎坏了一锅粥。IT 仍然需要优先考虑优化性能和正常运行时间。没有人愿意成为将企业推向成功的贡献者链中的薄弱环节。但这也意味着需要提供一种能够优雅失败并快速恢复的架构,同时尽可能多地提供有关其性能的信息。

这是采用微服务架构的关键优势之一。通过将代码库和服务分解为多个相互通信的小型独立应用程序,可以降低一个小故障可能导致整个系统崩溃的风险。你还需要注意可能导致级联故障的服务间连接。每个微服务不仅应该对自己控制的区域负责,在其他服务失败时它也应该能够优雅地失败。这意味可以将进程内数据保存在某处,等待故障服务重新上线时就可以快速获取;为最终用户提供错误信息,让他们可以采取其他行动(例如,解释如何自行解决问题或将问题发给支持团队);积极监控性能问题,并在出现问题时提醒相关团队(“DevOps”意味着开发人员也随叫随到);记录所有相关信息,便于后续快速获取和评审。

如果你卡在了经历了多年制度化风险规避的遗留系统上,那么仍然存在一线希望。现代 ESB 工具可以帮助你将单体抽象为微服务、缓解故障,并让你的系统可以优雅地降级。使用这些工具,你可以开始识别问题系统,并根据需要进行替换和现代化,而无需花费太多时间完全重写整个系统。

与此同时,所有新的开发可以采用更灵活的范例,例如通过现代 Web 服务 API 进行通信的微服务架构。传统的运营角色必须从谨慎的看门人转变为以客户为中心的服务提供者,主要客户就是你自己的内部开发团队。在真正的 DevOps 环境中,所有技术利益相关者都应该共同获取这些系统专业知识。任何人都不应该只是一种或几种技术的专家——每个人都应该至少了解驱动系统所需的所有技术。例如,如果你认为自己是 Java 程序员,而不是通用的“程序员”,那么在你的职业生涯中,仍然有很多东西需要你学习。

变化是好的,但需要通过业务目标和资产现实来缓和。仅仅采用流行的敏捷策略是不够的——你必须调整自己的文化,找到最适合你组织的敏捷模型。等待的时间越长,被比你动作更快的人取代的风险就越大。

积极的变化可以是自上而下的,也可以从开发团队开始。你必须迅速获得每个人的支持,并建立一种文化,将失败和成功视为平等的学习机会,使其成为整个组织的习惯,才能确保长期的成功。

仔细反省并确保你和你的人不会成为众所周知的信天翁并不会有什么害处。考虑什么是不可能的,以及为什么——但不要有任何关于潜在成本、混乱和灾难的反思性理由。问问自己,“你是创新的障碍吗?”

关于作者

Robert Zazueta担任数字平台战略全球总监,为 TIBCO 及其客户提供有关数字化转型的战略建议、指导和思想领导力。他拥有超过 15 年的 Web 开发经验和 4 年的业务开发经验,他开发、设计、使用、支持和管理各种 API 和合作伙伴集成。他还负责维护 NARWHL.com,该网站描述了构建适应性 API 的设计框架。

查看英文原文 Are You the Barrier to Innovation?

2018-09-28 18:241328
用户头像

发布了 731 篇内容, 共 432.0 次阅读, 收获喜欢 1996 次。

关注

评论

发布
暂无评论
发现更多内容

阿里云贾少天:大规模云服务器高效使用及管理实践

阿里云弹性计算

阿里云 云栖大会 云上运维

DevEco Device Tool 3.0 Beta2新版本发布,新增可视化Trace工具和Perf性能分析工具

HarmonyOS开发者

OpenHarmony

Tableau Day1: 完成第一个可视化

贾献华

Tableau 1月月更

区块链数字藏品平台开发,区块链+数字藏品激活传统文创

电微13828808271

在线JSON转HTML工具

入门小站

工具

ReactNative进阶(二):ReactNative 项目文件结构介绍

No Silver Bullet

React Native 1月月更

Spring 如何解决循环依赖问题?

CRMEB

(1-3/3)团队OKR的设定

mtfelix

300天创作 无限生长 2022Y300P

一个cpp协程库的前世今生(十)调度的流程

SkyFire

c++ cocpp

「offer来了」面试中必考的15个html知识点

星期一研究室

html html5 css3 前端 html/css

JVM到底该学些什么?

蝉沐风

JVM 虚拟机 学习路线

查收新年礼物 | DevEco Studio 3.0 Beta2发布,20个新变化,等你升级

HarmonyOS开发者

HarmonyOS

“群舰效应”与商业市场大航海

脑极体

设计模式【7】-- 探索一下桥接模式

秦怀杂货店

Java 设计模式 桥接模式

今晚直播:展望2022,操作系统将走向何方?

OpenAnolis小助手

操作系统 国产操作系统 龙蜥社区

当前端渲染遇上边缘计算

火山引擎边缘云

04 Prometheus之配置步骤及容量规划

穿过生命散发芬芳

Prometheus 1月月更

微博评论高性能高可用计算架构

ren

基于区块链和web3.0的全新社交协议Coo Social首发上线虎符创新区

区块链前沿News

Hoo 虎符交易所 coo Web3.0

浅谈ThinkPH5.0和5.1的反序列化利用链分析

网络安全学海

黑客 网络安全 信息安全 渗透测试 安全漏洞

应收账款的界定

whatever

供应链金融 保理

Java后端学习笔记

小太阳

Java 学习笔记 学习路线

Kafka的灵魂伴侣LogiKM(1)之集群的接入及相关概念讲解

Kafka中文社区

龙蜥社区2021年度运营委员会会议顺利召开

OpenAnolis小助手

龙蜥社区

三星堆遗址

wood

300天创作 三星堆

Linux之find命令的参数详解

入门小站

Linux

科尼数字科技张彬:云设计系统助力行业数字化转型

阿里云弹性计算

阿里云 弹性计算 年度峰会

开源实践 | 六棱镜基于 OceanBase 选型探索与实践

OceanBase 数据库

OceanBase 开源 OceanBase 社区版 客户案例

🏆【Alibaba中间件技术系列】「RocketMQ技术专题」带你一起去探索RocketMQ服务架构的线程模型分析

洛神灬殇

RocketMQ SpringCloud Alibaba Alibaba技术 Apache RocketMQ

Elasticsearch 多种跨机房灾备方案对比与实战解读

Se7en

Python猫 2021 文章小结,翻译竟比原创多!

Python猫

Python

你是创新的阻碍吗?_文化 & 方法_Robert Zazueta_InfoQ精选文章