你是创新的阻碍吗？

我们的行业时刻在发生变化。但是改变很难的——特别是当你已经建立了一套强大的已经可以满足客户需求和业务目标的 工具 和系统。随着企业寻求进入新市场或满足客户新目标的机会，现有的架构将面临严峻的考验。“当我们采用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?