In 2005, my employer embarked upon an ambitious systems renewal project. The IT director aimed to make a mark by replacing our existing IT systems with a brand new solution. As the story goes, the IT director had visited Oracle headquarters near San Francisco. He could get a steep discount on the Oracle ERP solution. I wasn’t a firsthand witness, but several colleagues gave similar accounts. And so, it could be the truth. ERP can administer an entire business. It is a total-for-everything solution, but only if you model your business the way ERP prescribes. In other words, every department must change how it conducts its affairs. It is like a straitjacket. That makes ERP awkward to use.

It wasn’t a good idea to purchase an enterprise solution without first considering whether you need it. But instead of the IT director admitting he had bought the ERP on a whim and writing off the license fee, which would have been a minor loss of a few hundred thousand euros, perhaps, he sought to justify the purchase. Possibly, the IT director wanted to save face, but you wouldn’t expect that kind of vanity from a religious person like him. Business consultants came to assess the quality of our IT systems and to write a report proposing a solution. Unsurprisingly, the report stated that our systems were obsolete and that we should switch to Oracle ERP to save lots of money. And now I spill some beans. These outdated systems were still doing fine fifteen years later.

A strategic information planning phase preceded the project. Cap Gemini business consultants organised brown paper sessions where employees could help identify the business requirements. It was different from what I had learned as a student. I had a good grade, but as a student, I was naive and believed good grades mattered. We had to list our components by writing them on brown paper and sticking them to the wall. The consultants would then call them ‘services’. I wrote the word database on brown paper and stuck it to the wall, and the Cap Gemini business consultant concluded that we needed a database service. That didn’t seem like a proper strategic business analysis to me. Anyone could paste the word ‘service’ after a component’s name. It dawned upon me that it might not end well. Cap Gemini charged over €150 per hour for its consultants, who dressed in suits, leading managers to believe it possessed expertise in strategic information planning.

There were political troubles early on. A Cap Gemini project leader left because she didn’t share the IT director’s vision. He surrounded himself with yes-men. And you can’t have competent people standing in the way. In the Information Planning course at the university, we learned that you must first define the business requirements and then select a solution based on these requirements. It can save you a lot of trouble. The business consultants did the opposite, trying to justify a choice already made. Over time, it grew into an all-encompassing megalomanic plan. Most departments didn’t want the IT department dictating their operations. And so, the consultants planned to supplement the Oracle ERP with several special-purpose modules. Making special-purpose software would render ERP pointless, as the whole point of using ERP was to avoid building such software.

We didn’t dive into the deep end without first testing the waters, so we initiated a pilot project to develop a basic ERP-based system. It was a brand-new system for administering Plukze, a law that allowed the government to confiscate criminals’ assets. Plukze was a straightforward bookkeeping system, and ERP can keep books well, so the pilot succeeded. It was like sending a rocket into the sky and then, after a successful test, deciding to put a man on the Moon. That is an entirely different ballgame.

They trained me to become an ERP system administrator, and then I started as a junior under the guidance of an experienced administrator who was a temporary hire from a software consultancy firm. Once, I made a mistake by putting a database index on maintenance while the ERP system was running. The ERP proved more sensitive to regular database maintenance than the Designer/2000 systems, so it began to malfunction. I mentioned my index maintenance as a likely cause. We restarted the system, which resolved the issue. I remarked that I hadn’t anticipated the problem as regular systems could handle such an operation, which implied criticism of the new system. For all kinds of ordinary operations, the ERP had lengthy instruction sets that you could find on the Oracle support website.

You couldn’t do maintenance work while the system was operational, not even simple, unintrusive things that other systems could deal with. The situation is comparable to Windows failing after moving a file to another directory, and the solution is to restart the computer. You wouldn’t expect it. I had yet to learn that. Yet the ERP was the IT director’s pet project, and it hung in the balance, so everyone was on edge. The project leader, likely fearing for his career, complained about me to higher management, labelling me unfit. I had been open about my mistakes and views, but that is quite problematic in a politically charged environment. They took me off the project. Fear was in the air. A circulating story was that the IT director had once threatened a manager in the lift who had openly disagreed with him during a meeting.

After the pilot proved a success, the enterprise systems renewal project took off. Once it had started, Oracle began to determine its direction. Oracle consultants soon found that we needed additional solutions from Oracle and, of course, the latest technology. Some of these technologies were still in the marketing phase and had not yet proven to work. Our decision-makers, the architects and managers, agreed. So when the special-purpose software proved cumbersome and inadequate, they tried new ideas, such as using BPEL, a business process model language, on top of ERP. This way, the business model could be tailor-made while still using ERP, or so they promised.

No one had done that before, for good reasons, as it turned out. Captain Kirk might have ventured there, but more cautious captains who cared for their crew and ship wouldn’t have. The consultants were there to make money for their employers by making the customers happy, so they tried the idea. Those who were critical would undoubtedly be first in line for a Professional Skills course. Despite working in information technology, I was never keen on using new technologies. Do not use them more than necessary. And so, I had no smartphone until 2020, and I only got one because my employer gave me one to log in to systems from home during the coronavirus pandemic lockdowns. By then, functioning in society without one had become practically impossible.

The project’s pointlessness began to demoralise me. Goals were constantly changing as ideas were always failing. IT employees became stretched to their limits for years in a row. Software releases that took one person and a few minutes with Designer/2000 took hours or even days, and required a dozen specialists working according to a script of up to fifty steps. Working late or on weekends became a regular occurrence, including ordering pizza, Chinese food, or other food, since you can’t bring the system down for so long during office hours. The database administrators bore the brunt of the pressure as the job role expanded to everything related to Oracle. Everything we did was Oracle, so database administration became the focal point for all the advanced stuff. And that began to take its toll, and I started to suffer from stress and repetitive strain injury.

My colleague Kees, the tech genius, was kind and always helpful. You could call him at home anytime, and he would help you. One evening, a year before the system renewal project had started, it seemed that I had messed up a database during a maintenance operation. I called him at home. He came over and helped me check it. But Kees was too helpful. He enthusiastically jumped on every crazy plan our management came up with. He was an innovator and loved new technologies. That made him the darling of management. I lagged behind Kees, but the other database administrators couldn’t keep up at all. It was like having a Trojan horse in our department as the project pushed more and more unmanageable technology into it. Kees didn’t look after the department’s interests but the project’s. The things he invented and built had to be kept up and running by the others. Kees didn’t take many notes, but was always willing to help us. Indeed, the entire system’s renewal project might have collapsed had Kees gone missing.

Our managers had no clue what they were doing and believed that more advanced technology like Oracle RAC clusters would fix things, but that only aggravated our troubles. RAC was pointless, required additional knowledge, and was still prone to failures, even though much less than previously, as the technology had matured and the new systems were on Unix. And so, I would sometimes sarcastically note, ‘The most reliable RAC cluster is one with one machine.’ That was the same as not having RAC at all. Pesky problems piled up on my desk. I constantly had to learn new skills. Project leaders pressured me to work on plans that were bound to fail. That couldn’t go on. I wanted to help people, but it was better not to fix other people’s problems or work on ideas that would fail. People were creating problems at a much faster pace than I could fix them. There was too much work, and most of it was pointless.

The escalating stress compelled me to make radical changes, focusing on the most critical issues while avoiding those that were pointless or doomed to fail. Whenever multiple project leaders pressured me, I referred them to my manager, saying, ‘He should set the priorities.’ Whenever a colleague tried to bequeath his pesky problem to me, I explained how he could fix it himself. ‘It begins with using Google,’ I said repeatedly. At the time, not everyone used search engines. Many still relied on their knowledge, manuals, and support from Oracle. Google has helped me solve more issues faster. Often, someone else has had the same problem and posted the solution on the Internet. But if you solve more problems, you get even more. It was a learning opportunity. If you solve other people’s problems, they stop thinking for themselves. I had to stop doing that.

As things spiralled out of control, our management decided we needed more qualified database administrators. Our salaries were too low to attract the right people, so they gave the new hires and Kees a higher salary grade while leaving me out. They also increased the number of temporary positions. The headcount went from four to fourteen database administrators. And still, we couldn’t handle the workload. Kees was a brilliant technician, and despite that, or perhaps partly because of that, things went downhill.

Kees was quicker on the job than I was, except for one notable occasion when a system administrator had wiped out a disk containing several crucial databases. It caused a crisis, prompting all the database administrators to scramble and restore the data, bringing the systems back online. I was the first to develop a working procedure for restoring databases and getting them back online, which the others then used. It doesn’t seem a mere coincidence. It was the third major crisis that the database administrators had to fix.

Temporary hires came and went. One of them was Ronald Oorlog. His last name means war, and he was ill when the World Peace temporary tattoo from the candy vending machine ended up in my hands. Rene H was the one who often joked about a master copy of the ERP system containing the settings, quoting a line from The Lord of the Rings, ‘Master precious… master precious…’ Another, Chris, told me he had met Jesus in his effort to evangelise me. He said it as if he had encountered Jesus in person. In hindsight, it was a noteworthy coincidence.

As things spiralled out of control, our management decided we needed more qualified database administrators. Our salaries were too low to attract the right people, so they gave the new hires and Kees a higher salary grade while leaving me out. They also increased the number of temporary positions. The headcount went from four to fourteen database administrators. And still, we couldn’t handle the workload.

Yet another colleague, database administrator Raoul, had roots in the former Dutch colony, Suriname. He once made a surprisingly frank statement. He worked for his uncle, he told me, who also came from Suriname. Apart from him, his uncle only hired Dutch people. ‘That is because the Dutch are more reliable,’ he added, ‘They do the job as agreed. You don’t have to check on them.’ That probably was true. Otherwise, he wouldn’t have said it. Surinamese don’t take life as seriously as the Dutch. The Dutch might call the Surinamese relaxed or even lazy, as many of them seem to think you can do what you failed to do today tomorrow. Don’t read this as only criticism. Doing nothing is better than doing something stupid, which we were busy doing at the time.

The year 2008 neared its end, and things took an unexpected turn. God seemed to have a message for me. Long-lasting stress can cause psychosis, so here is the probable cause. My perspective on what mattered changed profoundly. The job became a sideshow, and most of what we did at work was pointless. It was time to set the right priorities, cut my working hours and work on the project I gradually came to name ‘The Plan For the Future.’ Despite that, my performance at the job remained acceptable. We had so many database administrators that database administration became a separate department, headed by a manager who knew the job because he had previously been a database administrator.

This manager held me in high regard because I tried to manage the workload by focusing on what mattered and halting foolish plans. In 2011, he called me an example for all the others in front of everyone. He shared my view that Kees acted like a Trojan horse, causing trouble for the database administration department. Even fourteen database administrators couldn’t handle the workload, indicating that something was seriously wrong. Still, Kees was only a facilitator, not the culprit, because it was the IT director’s pet project, and our systems architects let Oracle drive the agenda. The focus was on new technologies rather than building a functional system. Everyone else went along with it, so sometimes it felt like being the only rational person in an insane environment.

After several years and over 100 million euros spent, the new system finally went into operation. That brand-new system, which had cost so much effort, accepted only incoming messages and acknowledged their receipt. Over a hundred people had worked on it for years. An experienced programmer might build a programme capable of doing only that in one day. It was a bloated set of software and machines with the latest technology, including RAC databases, but it was capable of nothing. The IT director had organised a party in which he proudly announced that we finally had a system made ‘under architecture.’ By phrasing it that way, he made it seem as if architecture was the project’s main objective. It made me think that our architects were incompetent. Those I saw in meetings didn’t dispel that impression, as they spoke vaguely and made simple things seem complicated. It would take me years to nuance that prejudice.

Again, as the story goes, our board then made a politically brilliant move by selling the project to the government in The Hague as a success, arguing that after spending more than 100 million euros, they needed a few million more to fix a few remaining issues. It worked. Appearance can go a long way to hide the facts. The board used that money to hire a software company to rebuild everything in Java. From then on, the ERP handled only financial administration, but they succeeded in making it appear that the new Java software was just an add-on to the ERP. There was so much lipstick that you couldn’t see the pig anymore. The budget was tight, with little money for testing and fixing bugs.

Unsurprisingly, the new Java systems crashed nearly every day, and the problem lists grew so long that no one could keep track of them. The Java systems consumed massive resources and generated large volumes of data, including millions of messages that no one dared to discard. Perhaps you could use them to find out what went wrong. And so much went wrong. These systems were dreadful, not only for us but also for those who used them. They split the database administration department into Oracle Designer 2000 (Boring Old Stuff), the ERP and Java systems (Enterprise Architecture), and the problem-generating department (New Developments), where the cool, advanced stuff happened. We had a say and could give our preferences. I didn’t want to work on the problem systems of Enterprise Architecture, but ended up in that horror show with Sico, since no one else wanted to. So much for having a say in matters. Sico was our ERP specialist, and I had some ERP knowledge, so my fate was sealed.

Over the years, I had grown cynical about everything our board and management were doing. During the crisis and the strategic information planning phase, they had proven to be a bunch of clueless clowns. The systems renewal project confirmed that impression. Only one project succeeded in those years, building an old-fashioned Designer/2000 system. Had we made the other systems using Designer/2000 or its successor, APEX, from the start, it might have cost less than 5% and succeeded. But then again, that was old technology without a future. We switched to Java, which seemed a good choice. My problem was that I looked too far ahead. With Java, you could do much more than with Oracle Designer or APEX, allowing the systems to grow more complex, which would eventually bring us down, or so I surmised. Fifteen years later, that premonition is gradually materialising.

The new Java systems used a hundred times as much memory and disk space as the Designer/2000 systems for doing the same job. That was an understatement. Making a fair comparison was difficult. The outcome of my calculation was 3,000 to 16,000 times as much. However, the new systems initially processed low transaction volumes and would scale up over time. Our architects didn’t see resource consumption as an issue. The price of memory and disks went down over time. Cheap resources make us wasteful. We can do without over 99.99% of the data we store. Imagine that sending an email costs €0.10 per recipient. That would eliminate all wasteful email and spam. And over 99% of the emails I receive, either at work or at home, are not worth reading.

Unsurprisingly, the data storage became overburdened. We were too far ahead of our time. The IT director then fired the manager responsible for data storage, citing that corporations like Google and Facebook can scale up quickly. Only, we weren’t Google, but an insignificant government agency with a few hundred IT employees. I was on leave when it happened, learned about it the following Monday, and thought, ‘The IT director is responsible for the mess. He is the one who should be fired.’ A few hours later, a soccer club, VVV from Venlo, fired its trainer, who had the same first and last name as our IT director.¹ Now that is a remarkable coincidence.

The failed systems renewal project became a learning experience. The government in The Hague had smelled the rat and had sent someone to oversee the CJIB and reorganise it. The IT director had to go. Geert replaced him. He was the manager who had promised to restore my confidence in my employer, but left me out for the promotion that the other senior database administrators received. Geert didn’t have a bureaucratic mindset. Rather than depending on procedures, he gave us responsibility and confidence.

We began working in smaller teams, handling a few systems owned by a single department. As a side benefit, there was less hassling between business units competing for resources. And we began working in smaller steps. That makes software development manageable. This way of working is agile. The symbol of agile is a snail. You know, as agile as a snail. Just kidding. Twenty years earlier, the insurer FBTO had already organised its IT department in a similar fashion, which worked well.

The IT department got its act together under Geert’s leadership. Most other government offices have yet to catch up. Red tape still makes our work harder than it needs to be, but rules aren’t an excuse for evading your responsibilities anymore. This story comes with a few learning opportunities. First, if your vision is wrong, hard work can’t make up for it. Second, you can’t change everything at once. It is better to work step by step. Third, things hardly ever go according to plan. You must make adjustments on the way. Fourth, giving people responsibilities with confidence helps to get the best outcomes. We all make mistakes, and if we can be open about them, we can learn from them. Only those who keep making them are unsuitable for their job.

Latest revision: 6 April 2026

Featured image: Grapevine snail. Jürgen Schoner (2005). Wikimedia Commons. Public Domain.

1. VVV-Venlo ontslaat trainer Van Dijk. Nu.nl (20-12-2010). [link]