硬核干货——《中小企业 AI 实战指南》免费下载! 了解详情
写点什么

新书问答: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:2214721
用户头像

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

关注

评论

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

到底什么是自助洗车?来科普下

共享电单车厂家

自助洗车加盟 车白兔自助洗车 什么是自助洗车

自助洗车费用居然比雪糕还便宜?

共享电单车厂家

自助洗车加盟 车白兔自助洗车 自助洗车费用 自助洗车价格

云渲染,设计行业的“新贵”

Finovy Cloud

渲染 云渲染 GPU算力 渲染技术

那一年,春晚拓荒牛背后的故事

优必选科技

机器人

【盲盒APP商城系统】在线拆盒后的功能介绍

WDL22119

盲盒小程序开发 盲盒APP开发 盲盒源码 盲盒H5开发 盲盒系统开发

如何搭建一个知识库网页?

Baklib

如何有效规避代码被“投毒”?

安势信息

许可证 代码安全 开源软件 安全合规检测 开源软件供应链

执行ls /dev/pts为什么这么慢?

BUG侦探

内核 ebpf devpts

让软件开发民主化的低代码

力软低代码开发平台

海外APP推送(上篇):厂商通道与谷歌FCM通道的差异

极光GPTBots-极光推送

Python函数默认参数避坑指南

和牛

测试

【Docker 那些事儿】初始 Kubernetes 容器管理平台(上)

Albert Edison

Docker Kubernetes 容器 云原生 7月月更

SpringBoot到底是什么

华为云开发者联盟

开发 springboot parent

专业创作本华硕ProArt 创16 2022预售,高效创作新旗舰

科技热闻

活动报名|揭露 Apache Doris 数据湖分析技术内幕?稀土开发者大会免费报名中!

SelectDB

数据库 数据湖 云原生 Doris 技术分享

如何实现随叫随到的客户服务

Baklib

自助洗车或许要比自动洗车更干净

共享电单车厂家

自助洗车 自助洗车加盟 车白兔自助洗车 自动洗车

阿里云联合平行云推出云XR平台,支持沉浸式体验应用快速落地

阿里云弹性计算

视觉计算 云XR平台

自助洗车加盟要满足什么条件

共享电单车厂家

自助洗车加盟 车白兔自助洗车

自助洗车为洗车行业注入新活力

共享电单车厂家

自助洗车 自助洗车加盟 车白兔自助洗车 洗车行业市场

龙蜥社区发布首个 Anolis OS 安全指南 为用户业务系统保驾护航

OpenAnolis小助手

阿里云 操作系统 龙蜥社区 sig 统信软件

从云原生到智能化,深度解读行业首个「视频直播技术最佳实践图谱」

阿里云CloudImagine

音视频 直播 视频云

从一线开发到技术总监,你就差一个赶鸭子上架

融云 RongCloud

程序员

架构训练营模块七作业

融冰

ICASSP 2022 | 用于多模态情感识别的KS-Transformer

优必选科技

人工智能 多模态机器学习

王者荣耀商城异地多活架构

intelamd

适合新手的12个Mybatis-Plus常用注解

华为云开发者联盟

后端 开发

结合pyqt5开发办公文档一键转换软件,以后再也不用开会员转文件了

迷彩

打包 7月月更 自动化办公

Pr视频剪辑师如何选笔记本?华硕灵耀Pro16 2022带你玩转内容创作

科技热闻

Starfish OS:以现实为纽带,打造元宇宙新范式

西柚子

怎样才能让企业知识管理发挥出它的真正价值?

Baklib

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