In 2005, our government office 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 devout Christian like him. He hired business consultants to assess the quality of our IT systems and write a report to propose a solution. Unsurprisingly, the report stated that our systems were obsolete and that we should switch to Oracle ERP, as that would save us a lot 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 their 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 behind the name of a component. It dawned upon me that it might not end well. Cap Gemini charged over €150 per hour for their consultants, who dressed in suits, leading managers to believe they possess strategic information planning expertise.

There were political troubles early on. A Cap Gemini project leader left because she didn’t share the vision of the IT director. He surrounded himself with yes-men. 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 as they tried to justify a choice already made. Over time, it grew into an all-encompassing megalomanic plan. Most departments didn’t want to have the IT department dictate 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 system using ERP. It was a brand new system to administer Plukze, a law that allowed the government to confiscate the assets of criminals. 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.

I received training to become an administrator of the system. I made a mistake by putting a database index on maintenance while the ERP system was running. The ERP proved to be more sensitive to regular database maintenance than the Designer/2000 systems, and the ERP 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 a simple operation, which implied criticism of the new system. For all kinds of simple actions, the ERP had lengthy instruction sets that you could find on the Oracle support website.

You couldn’t simply reorganise an index or do other database maintenance while the system was running. I had yet to learn that. The environment was politically sensitive because the IT director’s pet project was at stake, so many were on edge. The project leader, likely fearing for his career, complained about me to higher management, labelling me unfit. And so, they took me off the project. Fear was in the air. A circulating story was that the IT director threatened a manager in the elevator who had openly disagreed with him during a meeting. I was open about my mistakes and views, and that didn’t help me.

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, and for good reasons, as it turned out, so even Captain Kirk wouldn’t have gone there. The other consultants, hence those who were not from Oracle, were there to make money for their employers by making the customers happy, so they tried the idea. And if you are critical, you will undoubtedly be first in line for the course Professional Skills. I am a special case. Despite working in information technology, I am not keen on using unnecessary new technologies and try to live without them. And so, I had no smartphone until 2020. By then, functioning in society without one had become practically impossible.

The pointlessness of the project 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 affair, including ordering pizza, Chinese, or other food, as you can’t bring down the system 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 helpful. You could call him at home, and he would help you. One evening, before the system renewal project had started, I once feared I had messed up a vital 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 devised. He was an innovator and loved new technologies, which made him the management’s darling. I lagged behind Kees, but the other database administrators couldn’t keep up at all. It was like having a Trojan horse inside our department as the project pushed more and more unmanageable technology into the department. 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 make a lot of notes, but was always willing to help us. Indeed, the entire systems renewal project might have collapsed had Kees gone missing.

Our managers had no clue what they were doing and believed 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 at a faster pace. 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, except on one notable occasion when a system administrator had wiped out a disk on which several crucial databases resided. 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, as if Jesus had walked around and he ran into him. 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 native Dutch. ‘That is because the Dutch are more reliable,’ he added, ‘They do the job as agreed. You don’t have to check on them.’ I supposed it was true. Otherwise, he wouldn’t have said it. Surinamese don’t take life as seriously as the Dutch. The Dutch might call the Surnamese relaxed or even lazy, as many of them seem to think that you can do tomorrow what you failed to do today. Don’t read this as only criticism. After all, doing nothing is better than doing something stupid.

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 been a database administrator previously.

This manager held me in high regard because I tried to control the workload by focusing on what mattered and trying to halt foolish plans. In 2011, he called me an example for all the others in front of all the others. He shared my view that Kees acted like a Trojan horse, causing trouble to 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 spending over 100 million euros, the new system finally went into operation. That brand new system, which had cost so much effort, only accepted incoming messages and acknowledged their reception. 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 debunk that impression as they spoke vaguely and made simple things appear 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 as a success to the government in The Hague, arguing that after spending more than 100 million euros, they needed a few million more to fix the remaining bugs. 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 in nine months. From then on, the ERP only did the financial administration, but they made it appear that the new Java software was just an add-on to the ERP. The budget was tight. There was no 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 a lot of resources and generated a lot of data, such as 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 up the database administrator department into Oracle Designer 2000, called legacy, the ERP and Java systems, called Enterprise Architecture, and new developments. We had a say and could give our preferences. I didn’t want to work with the problem systems of Enterprise Architecture, but I ended up in that horror show together with Sico, as no one else wanted to. Sico was our ERP specialist, and I was one of the few with ERP knowledge, so I was doomed beforehand.

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 tool APEX from the start, it might have cost less than 5%, and it would have succeeded. But then again, that was old technology, so it had no future. And so, I didn’t foresee at the time that Java would turn out to be the right choice.

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 volumes of transactions and would scale up. 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, and you can see that everywhere around you. We can do without over 99.99% of the data we store.

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. I 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.

Leadership does make a difference. The IT department got its act together under Geert’s leadership. In 2025, many other government offices have yet to catch up. Bureaucratic rules still make our work harder than it needs to be, but today, they aren’t an excuse for evading your responsibilities. And so, this story comes with a few learning opportunities. First, without the right vision, you fail, no matter how hard you work. Second, you can’t change everything at once. You must have a long-term vision. Third, things hardly ever go according to plan. It is better to work in smaller steps towards your goals and make adjustments on the way. And you should give people confidence. We make mistakes. But if we do, we should learn from them to do better next time.

Latest revision: 2 August 2025

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]