Accident
Damage: House smashed, 1 person killed.
Cause 1: Crane overloaded.
Cause 2: Faulty tilt sensor.
Cure: Always test sensor before work.
New health record system
Damage: Fewer patients per hour, 8000 frustrated clinicians . . .
Cause 1: Didn't plan the new work processes
Cause 2: Wanted everything at once . . .
Cures: Problem-oriented requirements,
Deploy part-by-part . . .
The full report (pdf). A short version is published in IEEE Access, 2020: Soren Lauesen: IT Project Failures, Causes and Cures (pdf).
Related data: Overview of failure data (xlsx), and in Danish: Oversigt (xlsx)
Service-oriented architecture (SOA) is often a cause of damage. Actually, it is the only technical damage cause we observed. The paper by Pagaard below, is a detailed investigation of two ways to integrate systems: The ideal SOA and the shared database.
Related sections on this site: Why the electronic land registry failed (below) and:
Acquisition of the EPIC health record system
Christoffer Pagaard, 2017: Service-oriented architecture versus shared database
This paper compares the IT architecture in two large Danish government departments: TAX and STAR (department of labor market, including management of unemployment benefit). Tax uses the ideal SOA architecture where an arbitrary collection of IT systems communicate with services. Data is not replicated, but each system retrieves what it needs from other systems. It may also need to update data in other systems. In contrast, STAR has a shared database managed by the department, but operated and maintained by changing IT suppliers. Around 50 IT systems in government and industry draw on the database with services. They may replicate data, but the reference data are the shared database.
The conclusion is that the shared database has many advantages, e.g. response time, availability and ease of maintenance. It could be improved by using Odata with SQL-like requests, rather than traditional specialized xml-services. Experience from other systems show that maintenance is vastly simplified with Odata. Instead of two parties having to negotiate a service, Odata allows the client party to define the services himself. Security and performance seem to be risks, but in practice it is not worse than the traditional approach.
One factor Christoffer ignores, is the need for testing the integration. When testing a client system, special test data in the server may be needed. However, this data must not disturb the server's normal operation. The testing problem exists in both architectures. When reading the report, the reader should appreciate that Christoffer is almost blind. Download report (pdf, in Danish)