Self developed systems: cheaper, or false economy?

Gerrit Vos

From self-development to standard, off-the-shelf packages to … self-development. Gerrit Vos has followed it all closely and he knows that banks and insurers are still looking for the smartest solution when it comes to system development and management. He has his own thoughts on the subject too.

Up until the 1990s, insurers and banks developed their own systems, buying mainframes and hiring specialists to help with their design and maintenance. They had no choice; there simply weren’t any off-the-shelf packages on the market. DIY was the name of the game.

It was during the 1990s that software companies identified the gap in this market and started developing off-the-shelf packages. One of the first of them to be available on the Dutch market was Life400 by Paxus and the first clients to use it were the then Amev and ABN. The build of these packages was such that they had very little in common with what they replaced. Consequently, software development costs doubled, which was, of course, not supposed to happen.

Outsourced, but still developing

What happened next was predictable; they were outsourced, preferably to low-wage countries like India and China. However, the hoped-for savings did not materialise. So people at the head offices kept developing, much to the delight of the outsourcing parties, who then had even more to do. In the meantime, their rising popularity transformed what were low-wage countries into high-wage countries, so banks and insurers again started looking for alternatives.

Several companies think they have found one in self-development – well, what do you know, we’ve come full circle! Rather than using existing programing languages such as Java or .net, they rely on new tools: Low Code Systems such as Outsystems, Mendix, Betty Blocks and WEM. Their suppliers reckon that you no longer have to be technically savvy to develop such systems; people from the relevant business units can establish what a process should comprise of and then configure it themselves in a Low Code system.

Nobody is too good for off-the-shelf

I’ve seen the initial results of such a back-office system. The straightforward transactions looked pretty good, but the more complex stuff wasn’t included. It would seem that it’s more complicated than the suppliers claim; developing complex systems appears to be a specialism after all. More limited applications (developed by IT specialists) worked fine, after a few adjustments here and there.

Every bank or insurer believes they are unique. And they are. But that doesn’t make them too good for standard, off-the-shelf components or systems. Rather than automatically going for a bespoke solution for a problem, I reckon that organisations should first ask themselves whether they could use standard packages. Personally, I think it makes more sense to adjust processes than standard components or systems. Take the automotive manufacturers, for example. Audi, Mercedes and Lamborghini use the same robots, engines and technologies to produce very different cars.

Core business

The notion that banks and insurers are also IT companies is, in my opinion, as daft as saying that Audi is a robot company. Banks and insurers are there to serve their customers as well as they can with the best products they can offer them. Suppliers of off-the-shelf packages accumulate a great deal of expertise in the real world, which they then translate into new applications. What’s more, they are continuously investing in technological developments, which means they are always up-to-date. I think that IT companies that focus on banking and insurance are well placed to develop the right standard packages. So my advice is to stick to your core business and opt for the most appropriate components and packages. If we all focus on what we are really good at, everyone benefits.

What opportunities do you see?

We are happy to make an appointment. Call us at 0653778749 or send an email to e.hoekstra@itds.nl.

Call me back

"*" indicates required fields

Hidden
This field is for validation purposes and should be left unchanged.

Current