写点什么

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

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

关注

评论

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

Java日记——使用强大的Elastisearch搜索引擎

java易二三

Java 编程 程序员 计算机

国产 etl engine 监控面板 为管理者掌握平台运行情况,决策执行方案提供即时数据支撑

weigeonlyyou

数据库 数据交换 物联网 ETL 云数据迁移

商品推荐系统浅析 | 京东云技术团队

京东科技开发者

算法 推荐系统 推荐算法 企业号 8 月 PK 榜 搜索推荐系统

鸿蒙智联再出发,携手伙伴共赢空间智能化,创造无限可能

HarmonyOS开发者

HarmonyOS

OpenSSL 3.0.0 设计(二)|Core 和 Provider 设计

铜锁开源密码库

开源 开发者 算法 信息安全 密码学

SSM框架——使用MyBatis Generator自动创建代码

java易二三

编程 程序员 mybatis 计算机

北航基于openEuler构建工业机器人操作系统,打造“开箱即用”的机器人基础软件平台

openEuler

Linux 操作系统 机器人 嵌入式 openEuler

产业共振 智能涌现!8月16日飞桨携手生态伙伴带来大模型企业应用创新实践

飞桨PaddlePaddle

人工智能 百度飞桨 百度AI 文心大模型

持续赋能 AI 应用,和鲸 ModelWhale 入选“2023 数字生态500强”优秀案例&解决方案榜单

ModelWhale

人工智能 大模型 数字生态 AIGC

Camtasia 2023 for Mac(视频录制和剪辑软件) v2023.1.2中文特别版

mac

Camtasia2023 苹果mac 屏幕录制软件 视频编辑软件

spring多数据源动态切换的实现原理及读写分离的应用 | 京东云技术团队

京东科技开发者

spring 读写分离 企业号 8 月 PK 榜 AbstractRouting 动态切换

质量指标如何发挥作用?构建质量能力是关键

BY林子

质量指标 质量度量 质量能力

从 Java 11 迁移到 Java 17 的注意事项

高端章鱼哥

Java JVM java17

11. 数据类型 - 字典

茶桁

Python 数据类型 字典

大模型AI人才培养研习会,上海、武汉站同期招募!

飞桨PaddlePaddle

人工智能 百度飞桨 文心大模型

JSP的内置对象

java易二三

编程 程序员 计算机

透过源码,捋清楚循环依赖到底是如何解决的!

江南一点雨

Java spring

买量业务福音:自有App运行小游戏

FinFish

小游戏 App运行小游戏 游戏买量

GPT-4助力数据分析:提升效率与洞察力的未来关键技术 | 京东云技术团队

京东科技开发者

数据分析 ChatGPT4 企业号 8 月 PK 榜

明道云联合Kyligence结合示范性场景应用

明道云

Java中final、finally和finalize的区别

java易二三

Java 程序员 计算机 final

哪些项目管理工具领跑2023年中国市场?全新榜单揭秘

爱吃小舅的鱼

项目管理 项目管理软件

MES和ERP的区别

优秀

ERP mes mes和erp区别

NKD:容器云集群与 OS 一体化运维利器

openEuler

Linux Kubernetes 云原生 操作系统 openEuler

选择FastAPI或Flask:Python Web开发框架的终极指南

Apifox

Python flask 框架 web开发 FastApi

12. 数据类型 - 集合详解

茶桁

Python 集合 数据类型

移动云操作系统改造技术实践分享,跨操作系统云主机迁移优化(一)

openEuler

Linux centos 操作系统 迁移 openEuler

分享实录 | 将 NGINX 打造成功能强大的 API 网关(上)

NGINX开源社区

nginx 微服务 k8s API api 网关

研发提测前测试到底能做些什么 | 京东云技术团队

京东科技开发者

测试 测试开发 企业号 8 月 PK 榜

头像生成App 欢迎试用 | AIGC

AIWeker

人工智能 AIGC Stable Diffusion

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