3 ms·

This tends to be the case when you need a bug-for-bug re-implementation of the old program, but it isn't stated up front.

by Kamq 4y ago

skissane 4y ago
Sometimes implementations fail for essentially the opposite reason – the new system is too generic and insufficiently close to the original program. One place I worked (a university), they tried to replace their mainframe COBOL system (Fujitsu FACOM GS8400 mainframe [0] [1], along with Software AG's ADABAS database and some use of their Natural 4GL as well) with PeopleSoft Campus. However, PeopleSoft Campus was designed for the US market, and many of its features were rather irrelevant in Australia; conversely, key features needed to cope with Australia's rather different regulatory environment were lacking, forcing the project to reimplement large parts of the original COBOL system as add-on code. PeopleSoft sales (this was in the mid-to-late 1990s, so before Oracle bought them) had painted (whether by intention or ignorance) a fundamentally misleading picture of how suitable the product was for the Australian market. Eventually the whole project was written off as an expensive multi-million dollar failure, and the mainframe COBOL system got a reprieve on its execution. I was still in high school when it happened, but when I worked there several years later, the "PeopleSoft disaster" was a frequently repeated part of local institutional lore. Then, they tried again with a competing system from a local Australian ERP firm (TechnologyOne), running on a Microsoft application stack and Oracle RDBMS; and this time they succeeded in replacing the mainframe COBOL system, in part because (unlike PeopleSoft) it was actually designed for the Australian market. [0] https://www.fujitsu.com/au/about/corporate/history/products/computer/mainframe/gs8600.html https://www.fujitsu.com/au/about/corporate/history/products/... [1] http://museum.ipsj.or.jp/en/computer/main/0088.html http://museum.ipsj.or.jp/en/computer/main/0088.html
- ngcc_hk 4y ago
  Adabas and natural … those were the days my friends. Still have nightmare when it failed and have to fly in expert who actually does not know. …
- Kamq 4y ago
  > the new system is too generic and insufficiently close to the original program I may have been unclear, but this was the scenario I was describing. The need for a bug-for-bug re-implementation is a special case where the acceptable deviation from the original program is quite low.
  - skissane 4y ago
    They didn’t need a bug for bug reimplementation. Their problem was they tried to replace it with COTS software which wasn’t properly localised for their market. That’s more commonly a problem for smaller markets such as Australia, and also a bigger problem in highly regulated sectors such as education and health, where you are forced to deal with all sorts of government regulations which can be rather specific to the sector and jurisdiction you are operating in. The other problem, which is a more common problem with COTS software, is it is easy to be given one impression during the sales process, but then only once you’ve bought it and have started spending money to implement it that you realise how wrong that impression was. I think the people buying it on the customer side were senior university executives (who almost always come from an academic background) and they didn’t have a good enough appreciation for the nuts and bolts of student administration systems-and senior executives being sold on something where they don’t understand the details enough to see why it won’t work is yet another common cause for these kinds of projects to fail.

This tends to be the case when you need a bug-for-bug re-implementation of the old program, but it isn't stated up front.

by Kamq 4y ago

This tends to be the case when you need a bug-for-bug re-implementation of the old program, but it isn't stated up front.

skissane 4y ago

Sometimes implementations fail for essentially the opposite reason – the new system is too generic and insufficiently close to the original program. One place I worked (a university), they tried to replace their mainframe COBOL system (Fujitsu FACOM GS8400 mainframe [0] [1], along with Software AG's ADABAS database and some use of their Natural 4GL as well) with PeopleSoft Campus. However, PeopleSoft Campus was designed for the US market, and many of its features were rather irrelevant in Australia; conversely, key features needed to cope with Australia's rather different regulatory environment were lacking, forcing the project to reimplement large parts of the original COBOL system as add-on code. PeopleSoft sales (this was in the mid-to-late 1990s, so before Oracle bought them) had painted (whether by intention or ignorance) a fundamentally misleading picture of how suitable the product was for the Australian market. Eventually the whole project was written off as an expensive multi-million dollar failure, and the mainframe COBOL system got a reprieve on its execution. I was still in high school when it happened, but when I worked there several years later, the "PeopleSoft disaster" was a frequently repeated part of local institutional lore. Then, they tried again with a competing system from a local Australian ERP firm (TechnologyOne), running on a Microsoft application stack and Oracle RDBMS; and this time they succeeded in replacing the mainframe COBOL system, in part because (unlike PeopleSoft) it was actually designed for the Australian market. [0] https://www.fujitsu.com/au/about/corporate/history/products/computer/mainframe/gs8600.html https://www.fujitsu.com/au/about/corporate/history/products/... [1] http://museum.ipsj.or.jp/en/computer/main/0088.html http://museum.ipsj.or.jp/en/computer/main/0088.html

ngcc_hk 4y ago
Adabas and natural … those were the days my friends. Still have nightmare when it failed and have to fly in expert who actually does not know. …
Kamq 4y ago
> the new system is too generic and insufficiently close to the original program I may have been unclear, but this was the scenario I was describing. The need for a bug-for-bug re-implementation is a special case where the acceptable deviation from the original program is quite low.
- skissane 4y ago
  They didn’t need a bug for bug reimplementation. Their problem was they tried to replace it with COTS software which wasn’t properly localised for their market. That’s more commonly a problem for smaller markets such as Australia, and also a bigger problem in highly regulated sectors such as education and health, where you are forced to deal with all sorts of government regulations which can be rather specific to the sector and jurisdiction you are operating in. The other problem, which is a more common problem with COTS software, is it is easy to be given one impression during the sales process, but then only once you’ve bought it and have started spending money to implement it that you realise how wrong that impression was. I think the people buying it on the customer side were senior university executives (who almost always come from an academic background) and they didn’t have a good enough appreciation for the nuts and bolts of student administration systems-and senior executives being sold on something where they don’t understand the details enough to see why it won’t work is yet another common cause for these kinds of projects to fail.