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
  • 微服务
  • 平台
  • 安全
  • 软件测试
  • 技术策略
  • 商业
    商业
  • 商业 概观
  • 金融服务
  • 全球医疗
  • 创新
  • 零售行业
  • 转型
  • 招聘
    招聘
  • 招聘 概观
  • 职业心得
  • 多元与融合
  • 社会改变
技术策略技术

Using the ThoughtWorks Technology Radar to track governance

Neal Ford Neal Ford

Published: Jan 30, 2019

Large organizations with lots of technology inevitably face the task of managing and governing their decisions around technology: how long should the organization stay with existing technology, how much experimentation should we invest in, and myriad other questions that balance resources, cost savings, IT strategy, and capabilities. This article investigates some fundamental changes in the attitude about governance, how effective companies do it, and how the ThoughtWorks Technology Radar metaphor helps broadcast guidance.

The birth of the ThoughtWorks Technology Radar is documented in this article by Darren Smith. It started as an internal exercise to help us understand how our clients were adopting technology, and it seemed interesting enough to publish. Over the last few years, we've encouraged companies to use the same metaphor to build their own technology radar as a way of thinking more deeply about technology choices and trends within their organization. Towards that end, we've released a variety of open source tools to assist others in creating their own radar.

Increasingly, we see large companies utilizing the radar metaphor to solve a pervasive problem: how to effectively broadcast guidance decisions about technology to a widely dispersed group of engineers. Large enterprises commonly partition themselves into different divisions, departments, regions, locations, and other inventive partitions to organize the business. Often, these divisions result from mergers and other reorganizing forces, leading to scattered legacy around technology, architecture, and a host of other important technical decisions.
 
Enterprise architects must wrangle this diversity of technology and create a cohesive strategy.

When effective, they look across the portfolio of options within the organization and determine which ones work best, encouraging teams to use the optimal choices. However, the enterprise architect role often carries a negative connotation among the “beneficiaries” of their decisions, often stemming from their choice of the governance model. However, enlightened organizations have recently rethought the role of governance.
 

Three types of governance models

Enterprise architects are tasked with governance around technology choices, a term with unfortunate ambiguities. We see three different governance models active today.


Governance as control

The definition of the word govern, the root of governance, has many facets, and many teams end up using the wrong connotation. One definition of govern includes:
  • to control, direct, or strongly influence the actions and conduct of
  • to exert a determining or guiding influence in or over
  • to hold in check
Unfortunately, many organizations use this control version of governance. In this traditional command-and-control approach, the enterprise architects impose their choices on teams via a heavy-weight governance model:

All new web development should use the most recent version of Angular.

This is a mild case. I’ve seen a truly byzantine software stack (including application server, publishing framework, and industrial strength database) mandated for every project at one large organization until they realized they were over-engineering everything. The motivation for this approach often comes from a deeper motivation about business' attitude towards software: is it strategic or overhead? If the answer is overhead, then enterprise architects leverage a governance model to impose consistency and therefore save overhead cost. For example, if everyone standardizes on Java or ReactJS, then developers are fungible across projects, training and tooling becomes simpler, and the cost is generally lower.

However, the downside to the command-and-control model derives from a one-size-fits-all attitude about building software.
 
Trying to use the same software stack for every problem inevitably leads to mismatches in need and value.

I once worked for a giant enterprise that mandated a standard technology stack dictated by the enterprise architecture team, consisting of an Oracle database, a publishing framework, several XML libraries, a heavyweight J2EE distributed object model, and a host of other complicated moving parts. I was helping their developers debug a problem that was crashing their application server. During the course of the conversation, a  developer admitted that the seven users of the system didn't like it very much. "Seven users!?!" I exclaimed. "Well, it will eventually be as many as 25," he sheepishly admitted. To add insult to injury, the application merely queried the user about information across several forms and issued a project code—it could’ve been written by a high school student in PHP in a few of hours, yet this large enterprise had already spent hundreds of thousands of dollars… and couldn't get it to work. A pervasive problem with the "governance as cost savings" model is forced over-engineering.



Inadvertent overengineering is the natural side effect of a governance as control model. Let's say that an enterprise architect has the task of determining a single relational database for their enterprise standard. To perform due diligence, she should visit each team to determine the most challenging data problem, and choose a relational database that can accommodate them. Then, she must find the team that has the biggest reporting challenge, and choose a reporting solution that meets their needs. The same goes for integration architecture, messaging, NoSQL databases, and every other technology in the enterprise. However, the side effect is that now each team must deal with the maximally complex solution for every category. For example, for the relational database, the tool that can solve the most challenging problem imposes needless complexity on the teams that have mundane data storage and retrieval needs (which is likely more common). By forcing each team to standardize on a single tool in each category, an enterprise architect forces the maximum complexity in every category onto every team.

While cost savings is often a key goal of the governance as a control model, the unfortunate irony is that the cost of development and maintenance skyrockets due to over-engineering simple problems.

Many modern architectures, including lots of microservices projects, have adopted a different model, using governance as guidance.


Governance as guidance

The other definition of govern holds the better interpretation for modern software projects:
  • to serve as a precedent or deciding principle for
Rather than try to impose the same technology stack on every team, we see more enlightened enterprise architects prefer guidance to the traditional governance model. This approach is commonly practiced in many microservices architectures, where each service may utilize a unique technology stack. Architects on these projects focus entirely on what capabilities a particular service might need rather than adhering to a standard. For example, the administration part of the application might need modest scaling capabilities compared to the transactional part of the system.

However, even disparate technology stacks need commonality around operational concerns such as deployment, monitoring, logging, and a host of other desirable coupling points. To that end, the microservices community has popularized service templates and service meshes to handle the operational coupling necessary for functioning software.

The microservices model is the opposite of the consolidation model from the command and control world. While it has advantages around isolating architectural concerns, it also flies in the face of traditional approaches. Many companies strike a happy medium in what we've named Goldilocks governance.  


Goldilocks governance

In our book Building Evolutionary Architectures, we named a governance model after the Goldilocks fairy tale because architects following it strive for the same outcome as the eponymous girl in the fairy tale: finding the "just right" level of guidance versus control.

Having a unique technology stack per development team creates a lot of overhead and little chance at reusing assets, team member skills, operational support, and a host of other headaches. Thus, enterprise architects at many large enterprises have adapted a more nuanced approach that splits the spectrum between the previous "one size fits all" model and the "wild west" microservices model.

In the Goldilocks Governance model, enterprise architects choose several suitable technology stacks and assess which one suits new project development best. For example, a company may decide on small, medium, and large supported technology stacks and steer projects towards them accordingly. That allows some interchange between projects for teams and technology while still trying to avoid imposed over-engineering.

Of course, the Goldilocks model doesn’t prevent determined enterprise architects from still imposing overly rigid control. However, it hopefully encourages them to think about the value of technology on a more local project level, resisting the urge of over homogenization at the enterprise level.

Regardless of which governance model enterprise architects use, most companies face a challenge on how to broadcast their findings; that's where the ThoughtWorks Technology Radar comes in.

Broadcasting governance

A correlation exists between company size and difficulty in communicating detailed information across it. Enterprise architects in large companies struggle with how to let developers know what works, what is untried, and what should be avoided.

The Technology Radar provides a great mechanism to broadcast this information company-wide. When you use the ThoughtWorks Build Your Own Technology Radar tool, it creates a website that features a hyperlink per blip, creating a great doorway to more information about this technology or technique. Because each blip is a link, we have seen teams build impressive resources behind links.

For example, let's say a company is experimenting with a Bob's Web Framework. Enterprise architects need to verify if this framework handles the kinds of common applications they need, supports operational constraints, plays nicely with existing technology choices like security, and a host of other considerations. They allow three teams to build applications using the new framework, documenting their progress under the relevant blip on their governance radar. When developers ask about Bob's Web Framework, they can point to the ongoing experiments and preliminary results broadcast via the radar.

Our ring categories partition the adoption model for technology, but enterprise architects can easily re-purpose them to indicate governance levels. For example, several of our clients have constructed a radar for governance, using the existing categories to indicate the following:

 
Adopt Technique or technology proven to work within this enterprise and is well supported
Trial Promising tool or technique that we're experimenting with on one or more projects. Several of our clients include links to projects in the experiment so that readers can delve into more detail
Assess Promising new tool or technique that enterprise architects are evaluating for potential experiments. This includes things under active research
Hold Just as in the ThoughtWorks Radar, hold doesn't mean "abandon immediately" but rather "don't start new projects using this". Hold indicates that the enterprise has deprecated this tool or technique, and offers better alternatives


We have seen enterprise architects use the Trial ring to set WIP (Work in Process) limits for new experiments by various teams. That way, they allow organic experimentation at the team level with clear visibility to other teams and harvest the successful experiments for the Adopt ring.

Using the Radar, enterprise architects and others who shepherd technology choices can show others their current thinking. Rather than a document that broadcasts to the outside world what a company's choices are, this radar acts as living documentation for what's trending internally. Our clients who use this approach republish their governance radar on a regular cadence to ensure up to date information.

While enterprise architects undertake this kind of evaluation all the time, developers eventually affected by their decisions find the traditional process opaque. By creating an easy broadcast mechanism via the radar, enterprise architects offer transparency, along with the benefits that follow. For example, developers who have experience with some technology may interject their experiences, good or bad, into the conversation. Using the radar to highlight experiments turns a former ivory tower exercise among architects into a social collaboration between any interested parties, yielding a better diversity of opinion. We encourage enterprise architects using the radar as governance to facilitate discussion and transparency for their decision process.

The ThoughtWorks Technology Radar metaphor allows many interpretations. The idea of using it as a governance model came from our clients, but we're encouraging others to utilize it for that purpose because we have seen it become an effective living document. Thus, enterprise architects should revisit this document on a regular cadence: we’ve seen the spectrum from weekly for some clients to quarterly for others work, depending on how much transparency and engagement they seek.

Technology Radar

Don't miss our opinionated guide to technology frontiers.

Subscribe
相关博客
技术策略

Birth of the Technology Radar

Darren Smith
了解更多
职业心得

Using the Tech Radar to boost your career

Gareth Morgan
了解更多
技术策略

Build Your Own Technology Radar

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

WeChat

×
QR code to ThoughtWorks China WeChat subscription account

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