如何避免企业应用生命周期短？
不久前另一个问题< /a> 指的是（可能是都市故事）统计数据
...软件的平均寿命约为3年
当时我想到了以下原因（并且我确信还有更多可能更好的原因）：
一个新的主要系统（ERP、CRM 等）。 ）已实施，并具有“集成”模块来替换旧应用程序。
相同，但没有集成应用程序 - 但现有应用程序不具有适应性（人员离开、技术发生变化、当前 IT 政策发生变化、用户不喜欢现有应用程序。）
您从中获取基本应用程序的公司，以对其进行自定义为您的需求提供服务的公司已经消失。
为或者你不再与他们相处融洽。
现有应用程序的技术“过时”（根据框架供应商/微软/顾问/行业专家/听取管理层意见的新IT经理的说法。）
现有“我们正在逐步淘汰 (Windows 95/Windows 98/Windows 2000/Windows XP/NT)，我们需要我们的应用程序中的匹配技术”。
“我们从（应用程序版本 n）中学到了很多东西，并且我们在第二次/第三次/第四次/n+1 次时会做得更好。”
开发人员/IT 经理/部门副总裁/咨询公司的工作理由。
用户讨厌它。
我们合并/收购了竞争对手/被竞争对手收购，他们的更好。
其中一些是不可避免的（例如，您的公司被收购），但总的来说，这肯定是需要避免的事情。 您的组织是否有意对抗这种综合症？ 您会推荐哪些有效的策略？
A while ago another question referred to the (possibly urban tale) statistic that
... the average lifespan of software is about 3 years
At the time I came up with the following reasons (and I'm sure there are more possibly better ones):
A new major system (ERP, CRM, etc.) is implemented and it has an "integrated" module to replace the old app.
Same, but no integrated app - but the existing app is not adaptable (the people left, technology has changed, current IT policies have changed, users don't like the existing app.)
The company you acquired the basic app from, to customize it for your needs has disappeared.
Or you don't get along well with them any more.
The technology for the existing app is "obsolete" (according to the framework vendor/Microsoft/consultant/industry expert/new IT manager who has management's ear.)
"We're phasing out (Windows 95/Windows 98/Windows 2000/Windows XP/NT) and we need matching technology in our apps".
"We've learned a lot from (App Version n) and we'll do a lot better the second/third/fourth/n+1th time."
Job justification for developers/IT manager/Division VP/consulting company.
The users hate it.
We've merged/acquired a competitor/been acquired by a competitor and theirs is better.
Some of these are unavoidable (e.g. your company gets bought), but overall this is surely smething that needs to be avoided. Does your organization intentionally fight this syndrome? What effective strategies would you recommend?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这就是为什么应用程序需要易于扩展，并且您应该能够轻松添加所有流行语。
如果您有可靠的基础代码，大多数流行语都与 UI 有关（Vista Controls、Ajax、.net、ASP.net 3.5）...
您可以在后端运行 COBOL（我不会） 。
我还要说，当您将内部应用程序与商业应用程序进行比较时，这是不同的，如果您正在开发内部应用程序，则更改可以保证您的工作（如果您知道自己在做什么）。 如果您正在开发商业应用程序，变化是赚更多钱的机会，新功能将使您从现有客户和正在寻找流行语的新客户那里升级，与竞争对手相比，这些流行语可能会成为您的优势。
That's why an application needs to be easy to expand, and you should be able to easily add-in all the buzzwords.
If you have a solid base code, most of the buzzwords are related to the UI (Vista Controls, Ajax, .net, ASP.net 3.5)...
You could be running COBOL in the back-end ( I wouldn't).
I'll also say that this is different when you compare in-house to commercial apps, if you're doing an in-house app, change guarantees your job (if you know what you're doing). If you're doing a commercial app, change is an opportunity to make more money, new features would get you upgrades from existing clients and new clients who are looking for the buzzwords, these buzzword could become your advantage when compared to a competitor.
我目前编写的软件的平均生命周期可能是几天。 （我写了很多脚本，所以我可能是一个异常。;-）但是我使用的核心系统现在可能已经有 15 到 20 年的历史了。 底层操作系统已有大约 30 年的历史。 无论是旧软件还是新软件，本质上都没有什么问题。 事实上，当软件能够适应新用途时，它的老化效果最好。
在功能部分之间建立抽象层可以更轻松地替换系统中的功能。 例如，我们已经在系统上使用了几个不同的磁带库，现在我们正在考虑将来使用磁盘归档。 由于我们系统的“存档”部分位于抽象层后面，因此我们可以相当轻松地替换它，而无需替换系统的其余部分。
如果可能的话，最好也使用标准零件。 这样，如果您遇到一些限制，其他人很可能也会遇到同样的问题，并且更有可能有人会想出解决方案。
The average lifetime of software I write at the moment is probably a few days. (I write a lot of scripts, so I might be an aberration. ;-) But the core system I work with is probably 15 to 20 years old now. The underlying OS is about 30 years old. There is nothing inherently wrong with either old or young software. In fact, software ages best when it's possible to adapt it to new uses.
Having layers of abstraction between functional parts make it easier to replace functionality in a system. For instance, we've gone through several different tape libraries on our system and now we are considering going to disk archives in the future. Since the "archive" portion of our system sits behind an abstraction layer, we can replace it fairly easily without replacing the rest of the system.
When possible, it's also best to use standard parts. That way, if you run into some limitation, it's likely others will have the same problems and more likely someone will come up with a fix.
当收集需求时，有人说“情况 X 总是如此，没有例外”，请使其可配置。 总是会变的，无一例外。
When gathering requirements and someone says "Situation X will always be the case, no exceptions", make it configurable. It will always change, no exceptions.
大多数公司都坚持不了5年。 他们的软件实施预计不会持续那么久。
Most companies don't make it for 5 years. Their software implementations wouldn't be expected to last as long.