ThoughtWorks
  • 联系我们
  • Español
  • Português
  • Deutsch
  • English
概况
  • 工匠精神和科技思维

    采用现代的软件开发方法,更快地交付价值

    智能驱动的决策机制

    利用数据资产解锁新价值来源

  • 低摩擦的运营模式

    提升组织的变革响应力

    企业级平台战略

    创建与经营战略发展同步的灵活的技术平台

  • 客户洞察和数字化产品能力

    快速设计、交付及演进优质产品和卓越体验

    合作伙伴

    利用我们可靠的合作商网络来扩大我们为客户提供的成果

概况
  • 汽车企业
  • 清洁技术,能源与公用事业
  • 金融和保险企业
  • 医疗企业
  • 媒体和出版业
  • 非盈利性组织
  • 公共服务机构
  • 零售业和电商
  • 旅游业和运输业
概况

特色

  • 技术

    深入探索企业技术与卓越工程管理

  • 商业

    及时了解数字领导者的最新业务和行业见解

  • 文化

    分享职业发展心得,以及我们对社会公正和包容性的见解

数字出版物和工具

  • 技术雷达

    对前沿技术提供意见和指引

  • 视野

    服务数字读者的出版物

  • 数字化流畅度模型

    可以将应对不确定性所需的数字能力进行优先级划分的模型

  • 解码器

    业务主管的A-Z技术指南

所有洞见

  • 文章

    助力商业的专业洞见

  • 博客

    ThoughtWorks 全球员工的洞见及观点

  • 书籍

    浏览更多我们的书籍

  • 播客

    分析商业和技术最新趋势的精彩对话

概况
  • 申请流程

    面试准备

  • 毕业生和变换职业者

    正确开启技术生涯

  • 搜索工作

    在您所在的区域寻找正在招聘的岗位

  • 保持联系

    订阅我们的月度新闻简报

概况
  • 会议与活动
  • 多元与包容
  • 新闻
  • 开源
  • 领导层
  • 社会影响力
  • Español
  • Português
  • Deutsch
  • English
ThoughtWorks菜单
  • 关闭   ✕
  • 产品及服务
  • 合作伙伴
  • 洞见
  • 加入我们
  • 关于我们
  • 联系我们
  • 返回
  • 关闭   ✕
  • 概况
  • 工匠精神和科技思维

    采用现代的软件开发方法,更快地交付价值

  • 客户洞察和数字化产品能力

    快速设计、交付及演进优质产品和卓越体验

  • 低摩擦的运营模式

    提升组织的变革响应力

  • 智能驱动的决策机制

    利用数据资产解锁新价值来源

  • 合作伙伴

    利用我们可靠的合作商网络来扩大我们为客户提供的成果

  • 企业级平台战略

    创建与经营战略发展同步的灵活的技术平台

  • 返回
  • 关闭   ✕
  • 概况
  • 汽车企业
  • 清洁技术,能源与公用事业
  • 金融和保险企业
  • 医疗企业
  • 媒体和出版业
  • 非盈利性组织
  • 公共服务机构
  • 零售业和电商
  • 旅游业和运输业
  • 返回
  • 关闭   ✕
  • 概况
  • 特色

  • 技术

    深入探索企业技术与卓越工程管理

  • 商业

    及时了解数字领导者的最新业务和行业见解

  • 文化

    分享职业发展心得,以及我们对社会公正和包容性的见解

  • 数字出版物和工具

  • 技术雷达

    对前沿技术提供意见和指引

  • 视野

    服务数字读者的出版物

  • 数字化流畅度模型

    可以将应对不确定性所需的数字能力进行优先级划分的模型

  • 解码器

    业务主管的A-Z技术指南

  • 所有洞见

  • 文章

    助力商业的专业洞见

  • 博客

    ThoughtWorks 全球员工的洞见及观点

  • 书籍

    浏览更多我们的书籍

  • 播客

    分析商业和技术最新趋势的精彩对话

  • 返回
  • 关闭   ✕
  • 概况
  • 申请流程

    面试准备

  • 毕业生和变换职业者

    正确开启技术生涯

  • 搜索工作

    在您所在的区域寻找正在招聘的岗位

  • 保持联系

    订阅我们的月度新闻简报

  • 返回
  • 关闭   ✕
  • 概况
  • 会议与活动
  • 多元与包容
  • 新闻
  • 开源
  • 领导层
  • 社会影响力
博客
选择主题
查看所有话题关闭
技术 
敏捷项目管理 云 持续交付 数据科学与工程 捍卫网络自由 演进式架构 体验设计 物联网 语言、工具与框架 遗留资产现代化 Machine Learning & Artificial Intelligence 微服务 平台 安全 软件测试 技术策略 
商业 
金融服务 全球医疗 创新 零售行业 转型 
招聘 
职业心得 多元与融合 社会改变 
博客

话题

选择主题
  • 技术
    技术
  • 技术 概观
  • 敏捷项目管理
  • 云
  • 持续交付
  • 数据科学与工程
  • 捍卫网络自由
  • 演进式架构
  • 体验设计
  • 物联网
  • 语言、工具与框架
  • 遗留资产现代化
  • Machine Learning & Artificial Intelligence
  • 微服务
  • 平台
  • 安全
  • 软件测试
  • 技术策略
  • 商业
    商业
  • 商业 概观
  • 金融服务
  • 全球医疗
  • 创新
  • 零售行业
  • 转型
  • 招聘
    招聘
  • 招聘 概观
  • 职业心得
  • 多元与融合
  • 社会改变
云转型技术策略技术商业

The Lost Promise of Cloud

Brandon Byars Brandon Byars

Published: Apr 26, 2017

Cloud and Platform-as-a-Service (PaaS) offerings can provide significant business advantages when deployed in a way that accelerates application delivery. However, placing the decision-making authority of cloud purchases solely in the infrastructure department often achieves incremental efficiencies at the cost of long-term business results. The greatest benefit of these technologies comes from the organizational changes they allow.


Disintermediation through technology is one of the great themes of our times. Even historically "safe" markets are being disrupted, from taxis (Uber) to banks (Bitcoin) to cable companies (Netflix) to auto dealerships and gas stations (Tesla). Only 61 companies on the Fortune 500 from 60 years ago remain on it today. Software is eating the world, and changing consumer expectations. No company is immune from these changes.

Nearly 20 years ago, Clayton Christensen published The Innovator’s Dilemma, in which he described the essential tension that pushed successful companies like Microsoft along a path from market disruptor to market protector. Despite their innovative roots, the urge to sustain their market position creates an organizational ethos that stifles further innovations.

Many of these organizations—including Microsoft—have woken up to the dangers and are now using their financial clout to embrace the next disruption. But this doesn’t guarantee success. The sheer size and complexity of large, successful organizations make this kind of change hard.

Those who have done it most successfully have done so by focusing on the technological underpinnings of a delivery platform independently of innovation itself. Amazon was one of the most successful eCommerce sites in the world when it introduced Amazon Web Services (AWS) in 2006 as a completely unrelated infrastructure offering. AWS emerged from the infrastructure department’s desire for decentralization to better support internal development. It’s now Amazon’s most profitable division.

Netflix disrupted Blockbuster using a fairly low-tech approach: mailing movies to customers instead of trying to attract customers to stores. Netflix built a delivery platform that has spurred repeated innovations through a laser focus on technical agility. This included introducing streaming movies, despite the disruption to its own business model. Netflix architects credit much of their technical dexterity to the migration to the AWS cloud ecosystem in 2010.
 
Determining the technology approach to deliver innovation is a central concern for modern business executives.
One of the most common approaches is to align IT and business initiatives. While this is indeed a worthwhile goal, an MIT Sloan Management Review article called Avoiding the Alignment Trap in IT shows the unexpected consequences of such an approach taken naively.

The researchers confirmed the standard expectation that companies with high alignment between business and IT do quite well in the presence of an effective IT organization, with an average of growth rate of 35% over three years and reduced overall IT spending. However, high alignment proved disastrous in the absence of a reliable engine of execution in IT, with a negative top-line growth and significantly more IT spending. The data strongly suggest that focusing on IT effectiveness should take priority over focusing on business alignment.
Figure 1: Typical impacts of the alignment trap
Building a strong delivery capability is therefore as much a business concern as it is an IT concern. As Amazon and Netflix have demonstrated, the cloud plays an important role, but before defining how the cloud fits into your technology strategy, it’s important first to define the tradeoffs successful platforms make.

Optimize for Speed Over Cost

Forrester wrote about these tradeoffs in a report called Faster Software Delivery Will Accelerate Digital Transformation, starting with the advice to “go fast or go home.” The authors point out that “application delivery capability has now become the essential enabler of an organization’s digital business strategy".

Forrester’s analysis is backed up with top-line business results. For the past few years, Puppet Labs has used surveys backed with statistical analysis to look for correlations between application delivery approaches and various technology and business results. Their 2015 State of Devops Report showed that “high-performing IT organizations deploy 30x more frequently with 200x shorter lead times; they have 60x fewer failures and recover 168x faster”.

That’s a stark contrast to McKinsey’s popular two-speed IT advice that you have to choose between speed and stability. The Puppet Labs report found no statistical significance to differences in results between greenfield systems of engagement and back-end systems of record (including COTS packages), further challenging McKinsey’s assumptions. The previous year’s report showed even more eye-opening top-line business correlations: “firms with high-performing IT organizations were twice as likely to exceed their profitability, market share, and productivity goals”. This reinforces the results seen in the effective-IT quadrants of the Alignment Trap, but provides additional insights into the tradeoffs we make to get there.

Based on such data and its own analysis, Forrester recommends abandoning the idea of two-speed IT. It argues that DevOps, combined with loosely coupled architectures and cross-functional organizational structures, are the keys for improving both the speed and quality of delivery. These are the building blocks of a solid execution engine for innovation. These are the principles of your delivery platform.

Far too many organizations focus on cost optimizations, which ensures low IT effectiveness despite their best efforts. Business and technology leaders need to start by optimizing for speed and quality first, and cost second, if they want to improve the performance of technology. Lost opportunity costs you more than increased unit costs of delivery activities. This simple tradeoff has important implications on how we define our cloud strategy in our delivery platform.

Your Delivery Platform Requires A Different Organization

Nearly 50 years ago, Melvin Conway wrote that “organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations". Now known as Conway’s Law, this insight dictates how we should allocate responsibility to increase our application delivery capability, and the role that cloud and PaaS offerings play.

Remember the key principles of your delivery platform: DevOps, loosely coupled architectures, and cross-functional teams. The primary reason so many organizations find it challenging to embrace these principles is because, as Conway’s Law predicts, their communication structures—such as the ticketing system used for infrastructure provisioning—constrain them to solving yesterday’s problems when IT was seen as simply a cost center.

It’s not pay-for-use that makes AWS revolutionary: it’s transforming ticket-based infrastructure support to development self-service. By exposing APIs for developers to provision their own virtual infrastructure, the cloud supports a fundamental re-routing of the communication structures of an organization.

By redefining the boundary between infrastructure and development teams, infrastructure-as-a-service (IaaS) and PaaS support cross-functional teams at scale. The traditional approach of application teams creating tickets to shared services for infrastructure created artificial silos between infrastructure and application.

Monitoring, for example, was often considered an infrastructural concern, and database schema design was often a battleground between the DBAs who owned the operations of the databases and the application teams that used them. These silos significantly slowed down application delivery, as now, per Conway’s Law, the application itself has had to adjust to the increased complexity of the communication structures of the organization.

Unfortunately, as long as we look at software delivery through traditional organizational structures, such dysfunctions remain the inevitable outcomes, and our application will spend more time waiting to be released than in development. Layering a PaaS into your IT department while maintaining the same organizational silos is completely missing the point.

At the most fundamental level, it is not cloud or a PaaS that unleashes your delivery platform potential; it is the organizational restructuring those technologies unlock. Reading ACM’s interview with Amazon’s CTO Werner Vogels from 2006 (the same year AWS was launched) reinforces this point. Many low-performing IT organizations would relate to the problems Vogels describes in the early days of Amazon’s explosive growth.

It’s clear that many of the transformative changes Amazon went through had one key goal: fundamentally restructuring the organization to allow more ownership and isolation to unlock delivery potential. The famous Amazon push for service orientation defined a cross-functional ownership model that is still controversial ten years later.

"The traditional model is that you take your software to the wall that separates development and operations, and throw it over and then forget about it. Not at Amazon. You build it, you run it. This brings developers into contact with the day-to-day operation of their software. It also brings them into day-to-day contact with the customer. This customer feedback loop is essential for improving the quality of the service" Werner Vogels, 2006.

That ownership model—reinforced by cloud-based self-provisioning—provided development teams tremendous flexibility. As Vogels said: “Developers of our services can use any tools they see fit to build their services. Developers themselves know best which tools make them most productive and which tools are right for the job.”

It is this mindset that birthed the cloud.

Use The Cloud To Change Your Organization

It’s vital to keep this point in mind during the selection process of a private cloud or a PaaS. Often, this decision is handed to one department (usually infrastructure) to evaluate the offerings on the market. This treats the cloud as just another product, no different than the latest hypervisor or orchestration tool, and all but ensures minimal changes to existing ownership structures. Placing the decision in the hands of your development organization has the advantage of coming at the decision from a customer-centric viewpoint. Even so, this will still result in a suboptimal choice if viewed through existing organizational boundaries.

To truly embrace cloud technologies is to also embrace radical shifts in divisions of labor within your IT department. In large organizations, this will never happen by default. It requires executive intervention and the willingness to fight turf wars and break up managerial fiefdoms. This requires both courage and vision, as well as the persistence to continue after early missteps.

By fundamentally changing the role of infrastructure in application delivery, the cloud offers us a case study of disintermediation through technology, but in this case it is disintermediation of departments within your organization. Picking a cloud offering, and a platform-as-a-service on top, can provide just the technical levers needed to build the foundational elements of a delivery platform, but only if you’re willing to change your organization in the process. 

To learn more, visit our Digital Platform Strategy page.
相关博客
云

How We Moved to the Cloud

Sudhindra Rao
了解更多
软件测试

How Can the Cloud Improve your App's Quality? Part I

Max Lincoln
了解更多
软件测试

How Can the Cloud Improve your App's Quality? - Part II

Max Lincoln
了解更多
  • 产品及服务
  • 合作伙伴
  • 洞见
  • 加入我们
  • 关于我们
  • 联系我们

WeChat

×
QR code to ThoughtWorks China WeChat subscription account

媒体与第三方机构垂询 | 政策声明 | Modern Slavery statement ThoughtWorks| 辅助功能 | © 2021 ThoughtWorks, Inc.