写点什么

新书问答:Software Wasteland

  • 2018-05-21
  • 本文字数:3961 字

    阅读完需:约 13 分钟

关键要点

  • 几乎所有企业信息系统的实现成本都超额了。
  • 大部分超额成本可归因于复杂性。
  • 当你有数百或数千个复杂的应用程序时,完全陷入了我们所说的以应用程序为中心的困境。很多大公司将大部分 IT 预算用于集成。
  • 解决办法是转向以数据为中心,其中集成的核心模型应该比新增功能具有更高优先级。

在“ Software Wasteland ”一书中,Dave McComb 探讨了导致应用程序开发出现浪费的原因、如何进行变更成本的可视化以及以数据为中心将如何帮助减少浪费。

InfoQ 读者可以阅读 Software Wasteland: A Tale of Two Projects 的选节

InfoQ 采访了 McComb,讨论了有关信息系统行业的浪费情况、为什么以应用程序为中心的方法会如此流行、组织怎样对应用程序开发和维护问题进行可视化,以及如何解决问题、逆向工程将如何帮助我们降低复杂性,以及已经成功减少软件浪费的组织怎样防止出现倒退。

InfoQ:你为什么写这本书?

Dave McComb:我们居然会对企业信息系统行业的不良行为给予奖励,这让我感到很困扰。系统集成商或应用软件公司的能力越差,所赚的钱就越多,只要他们能说服客户说反生产力是必需的。如果你能说服客户说一个项目需要花费 1 亿美元,那么说明你的这个项目需要几百个人做好几年时间。但如果人们都知道这个项目由五人在六个月内就可以完成,那么就不会发生这种浪费。

InfoQ:这本书的目标读者是谁?

McComb:这本书专为参与企业系统项目的赞助、选择和管理的高管而设计。这本书的目的是帮助客户对已成为常态的浪费行为发起挑战。

InfoQ:信息系统行业的浪费情况有多糟糕?

McComb:有些系统的花费超过实际需要 1000 倍,这实在令人感到尴尬。大多数人都听说过 Healthcare.gov,但很少人知道,迄今为止它花费了 21 亿美元(原始预算为 9370 万美元),甚至更少人知道原本只要花费不到 100 万美元就可以做好(而且比现在要好得多),而这正是 HealthSherpa 已经实现的事情。 Healthcare.gov 最终还是采用了很多由 HealthSherpa 开发的设计元素。

加拿大轻武器注册处被作为价值 200 万美元的项目出售(成本为 1.19 亿美元,抵销收入为 1.17 亿美元)。它耗资 20 亿美元,在退役前注册了 800 万支枪。

大多数类似的故事都出现在政府部门,部分原因在于它们更容易成为公司的目标,而且它们中的大部分都处于政府备案材料中。

私人公司往往付出很高的成本,但从他们的大型应用程序和集成项目中获利却很少。我们知道有两家大公司发起了价值 10 亿美元和 2.5 亿美元的整合项目,但最终却不了了之。

美国航空航天局曾经以 600 美元的单价够买锤子(后来事实证明,锤子的价格只有 15 美元,其他费用花在了内部研发支出上,更糟糕的是,研发费用是按照物品项来计算的)。

大多数个体应用程序项目的费用比实际要高出 10% 到 100%。但是,我们所说的问题比仅仅修复一个个体应用程序项目更复杂,项目所在的生态系统才是问题所在。

InfoQ:是什么导致了这种浪费?

McComb:许多公司希望向以数据为中心的方向转变,而有些则自称自己已经是以数据为中心的。但实际情况是,他们可能会构建一个以数据为中心的个体应用(即先设计数据模型,然后再添加应用程序和功能)。但如果你构建(或购买)1000 个以数据为中心的应用程序,你的公司将拥有 1000 个中心,也就是说,等于没有中心。

问题是,只要你脑子里想的是以应用程序为中心的方法,那么每个问题看起来都像是另一个孤岛项目。

InfoQ:为什么以应用程序为中心的方法会如此流行?

McComb:我将这种思维的持续存在归因于四个方面:习惯、不知情、不正当的激励和缺乏纪律。习惯可能是最大的原因,几十年来,人们一直以应用为中心的方式构建系统,老习惯很难改掉。很多人不知道还存在其他的方式,所以就不会做出任何改变。系统集成和应用软件行业存在非常不正当的激励措施。无论多么低效,他们构建的每一个系统都能赚到很多钱。最后,很多人没有意识到,这不是你购买的商品,也不是你实现的短期项目。在很长一段时间内,需要严格的纪律(不是钱的问题,而是连续性)来约束。我在为下一本书所准备的案例中,他们都花了至少五年时间才实现了一个相当成熟的以数据为中心的架构。

InfoQ:你在书中探讨了一些尚未实现的应用程序开发方法,例如面向服务架构和 API、敏捷、云和人工智能等。你能否详细说明它们为什么没能提供解决问题的方法?

McComb:可悲的是,这些技术中的大部分都可以用在实际当中。但因为它们大多是按照以应用程序为中心的思想来实现的,所以最终妨碍了自己。以 SOA 为例,以数据为中心的 SOA 通常通过创建“规范消息模型”来实现,这非常有效。每个应用程序参与者都符合规范,那么架构就会给我们带来好处。但据我观察,只有不到 5%的 SOA 实现符合规范,它们中的大多数允许应用程序注册自己的 API,最终变成了通过总线进行交互的对等接口。

InfoQ:组织可以做些什么来可视化应用程序开发和维护的问题?以及如何着手?

McComb:仪表盘是最直观的可视化工具,它会根据应用程序和变更类型显示出变更成本。 IBM 的“正交缺陷分类”算是开了一个好头,不过你也可以从更简单的地方着手,比如通过以下方式对变更进行分类:

  1. 修复导致运行失败的代码
  2. 美学变更
  3. 在表单中添加或删除字段
  4. 在数据库中添加或删除字段
  5. 更改约束或验证机制

与我们合作的一家公司做出了一种关键类型的变更,即合并同一子行业中两家规模相似的公司。其中一家公司拥有非常成熟的以数据为中心的架构和文化,另一家公司则拥有数百个不同的应用系统。在一个应用程序中,最简单的系统变更类型或许就是更改枚举值的下拉列表。这两家公司都必须在其国家下拉列表中增加“南苏丹”一项。以数据为中心的公司将其添加到参考数据中,并重新生成相关的表单或代码。这个变更只发生在一个地方,并按照月度发布计划发布出去。另一家公司则花了将近 6 个月的时间才找到所有对国家代码的引用,而修改所有受影响系统则花了更长的时间。

这或许就是最简单的应用程序变更,复杂一点的可以是添加新的数据字段,这个时候就需要修改表单、报告、事务和 API。我们与一家劳工赔偿保险公司合作,他们在一项诉讼中败诉,如果受伤的工人因为伤情导致失业,则他们需要向工人做出部分健康保险理赔。在以数据为中心的环境中,这只是一个简单的变更,可能只需要花几个星期添加新的数据元素(雇主为员工的健康保险支付了多少费用),将该元素添加到某些表单和报告中,更改一些流程(向雇主核实信息)并添加算法用于确定需要赔偿的部分(是否兼职,季节性因素等)。但由于受影响系统的复杂性太高,实际花费了数百万美元。

正如我在书中所说的,了解变更成本的企业将变得更明智。

InfoQ:有什么办法可以帮助组织解决问题?为什么它们能够奏效?

McComb:我们已经看到了有些企业变成了以数据为中心,并在没有使用语义技术的情况下克服了应用孤岛的诱惑,但这并非可以轻松实现的。它主要使用了一种集中式核心模型,它足够简单且易于理解,完全覆盖到了共享概念,并且足够灵活,以便能够在企业中演化。对我们来说,语义建模和图数据库似乎是实现这一目标最快捷的方式。语义模型提供了领域概念的正式(机器可读)定义。与传统的概念模型不同,语义模型基于 Web 标准,并且可以直接实现。它不需要翻译成逻辑和物理表格。 Google、LinkedIn 和 Facebook 等科技公司的所有核心数据都保存在图数据库中(例如 Google 的知识图谱和 Facebook 的开放图谱)。图数据库本质上更加灵活,不需要提前定义所有模式(在关系型数据库中就需要),并且每个类不需要具有相同的属性。语义模型可以直接在符合标准的图数据库中实现,如 Allegrograph、MarkLogic、Virtuoso、Stardog 和 Oracle 12g。

InfoQ:逆向工程如何帮助我们降低复杂性?

McComb:实际上,大多数现有的遗留系统具有非常少的原生复杂性和大量的意外复杂性。换句话说,一个拥有 1000 万行代码的遗留系统可能只有几千行算法代码,但却有成千上万甚至几十万行的验证和约束逻辑代码,而这些其实可以很容易地使用参数和模型驱动的开发方式来替代。问题是,原本那点复杂性被这这数十万行代码所带来的负担放大了。这种负担就像是在开始露天开采之前必须去除的低品位矿石,这似乎是一个很恰当的比喻。如果你使用逆向工程软件来查找并隔离这个问题,那么就已经算是帮了自己一个大忙。不幸的是,逆向工程通常只是被用于从一个遗留系统迁移到另一个“新”的遗留系统。

InfoQ:对于已经实现减少软件浪费但想防止出现倒退的组织,你有什么建议?

McComb:没有一家已经实现了减少软件浪费的公司希望出现倒退,但有些公司确实出现了倒退。管理层变更或收购中经常发生的事情会导致管理层不了解信息系统的经济性。更糟糕的是,他们经常深陷错误的信念,比如认为打包解决方案始终是最需要去做的事情。

主要的防御不是技术性的,而是政治性的。你需要着重强调新方法可能带来的价值,并确保人们意识到他们已经逃离但有可能会再次返回的复杂性陷阱。以数据为中心的方法还远未成为主流,并且会在企业内部和外部存在许多诋毁者。很多人仍将受其威胁,无法睡个安稳觉。

关于本书作者

Dave McComb 是 Semantic Arts 的总裁和联合创始人。Semantic Arts 是一家专业的服务公司,致力于帮助企业为采用优雅、语义化、以数据为中心的解决方案。客户包括 Morgan Stanley、Dun & Bradstreet、Sentara Healthcare、Procter & Gamble、LexisNexis、Goldman Sachs、Sallie Mae,以及十多个州和联邦机构。

在创办 Semantic Arts 之前,McComb 领导了 Andersen Consulting(其中一部分发展成为埃森哲)的主要企业应用项目,并在 Velocity Healthcare Informatics 开创了模型驱动开发。McComb 在模型驱动开发领域拥有四项专利,除了“Software Wasteland”之外,他还出版了“Semantics in Business Systems”,并且经常演讲,十分高产。

查看英文原文 Q&A on the Book Software Wasteland

2018-05-21 19:2214408
用户头像

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

关注

评论

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

收藏!这些 IDE 使用技巧,你都知道吗

阿里巴巴云原生

Java ide 云原生 API 调度

Kafka 架构中 ZooKeeper 以怎样的形式存在?

李尚智

Java 消息中间件

纯干货 | 详解 HDFS 3.x 新特性-纠删码

五分钟学大数据

大数据 hdfs 28天写作 3月日更

力扣(LeetCode)刷题,简单题(第19期)

不脱发的程序猿

程序员 LeetCode 28天写作 算法面经 3月日更

Python 中文编码

依旧廖凯

Python 28天写作 3月日更

JAVA已经呈饱和趋势了吗?

cdhqyj

Java 程序员 工作 IT

36 Kr | 打造企业统一数据安全入口,「图尔兹」想用新思路解决数据安全问题

BinTools图尔兹

数据库 sql 数据安全 权限 数据库管理工具

区块链电子合同应用落地--区块链电子合同签约

13530558032

Linux内核 设备树操作常用API

赖猫

Linux Linux内核

2021网络系统流行架构

杨东冬

架构 网关 ebpf cilium envoy

2021最新分享:阿里内部总监手码的“Redis学习手册”风靡全网

比伯

Java 编程 程序员 架构 面试

不吹不黑聊中台

Geek_dn82ci

云计算 中台 企业架构

OCE等你加入

滴滴云

云计算 私有云 滴滴夜莺 Obsuite

币管家量化交易软件开发|币管家量化交易APP系统开发

系统开发

职场里,对数据库要有敬畏之心!

Simon

MySQL 数据库

Python 语言基础变量获得变量类型

HoneyMoose

关于MPI-IO,你该知道的

焱融科技

存储 HPC 焱融科技 文件存储 分布式存储

Alluxio 助力 Kubernetes,加速云端深度学习

阿里巴巴云原生

人工智能 大数据 容器 云原生 k8s

音视频之opengl渲染图片

赖猫

音视频

平安智慧社区建设方案,平安小区的系统功能

13530558032

Java程序员福利!2021年最新17套完整版一线大厂面试真题

Java架构追梦

Java 架构 面试 金三银四

LDAP身份认证管理最佳实践

龙归科技

服务器 ldap 客户端

分布式事务与解决方案

一个大红包

28天写作 3月日更

实习记录-埋点测试

YUKI0506

高考大数据:全国31省高考难度,哪个才是地狱模式?

不脱发的程序猿

大数据 数据分析 28天写作 高考难度 3月日更

mongodb 源码实现系列 - Mongodb write写(增、删、改)模块设计与实现

杨亚洲(专注MongoDB及高性能中间件)

MySQL 数据库 mongodb 架构 分布式数据库mongodb

【LeetCode】分割回文串 II Java题解

Albert

算法 LeetCode 28天写作

数据库定时备份linux篇

xiezhr

数据库 Linux Shell 数据备份 3月日更

如何招聘一名产品经理

马踏飞机747

互联网 产品经理 招聘 职场成长

智能炒币机器人软件开发|智能炒币机器人APP系统开发

系统开发

WebRTC 音视频同步原理与实现

阿里云CloudImagine

阿里云 音视频 WebRTC 流媒体 视频云

新书问答:Software Wasteland_Book Review_Ben Linders_InfoQ精选文章