Should we think of ourselves as ‘integrators’, rather than ‘developers’?

Should we think of ourselves as ‘integrators’, rather than ‘developers’?

Integration rather than development

This is a thought that I’ve been having a lot recently. And although it’s only a musing, I think it’s an important part of setting the right ethos for a project and subsequently getting a return from a project. So, without further ado, welcome inside my head…

‘Developer’, ‘development’ and similar terms have all become part of mainstream business vocabulary. Software is a huge part of our world these days and so this should come as no surprise. But these terms can imply that we are inclined to develop everything from scratch, which is so 1990’s. Let me tell you a short story…

I went to see a prospective client a while back. They were looking at a fairly ambitious project which involved a web app, mobile app, user management, invoicing, payments, split payments, tax documents, notifications and just about everything other than the kitchen sink. In his mind the development team would build everything from scratch. This was ‘his system’ and he didn’t want to pay to use anyone else’s tools. We’d build this ourselves. When I suggested that this was completely the wrong approach and we should look to tie into existing off-the-shelf solutions where possible, he looked at me like I’d lost my mind. He thought I was there to manage a team of ‘developers’ that would ‘develop’ things.

I hope I haven’t lost my mind. But here’s my train of thought.

Building everything yourself stops the real value from being delivered

The prospective client had a really good idea. I won’t tell you what it is, but it was innovative and I could see it really disrupting an old market. The value didn’t lie in the user management, invoicing, or any of that ‘stuff’. These systems are nothing new and we use them every day. The value was in how these systems came together to solve an old problem in a new way.

But the problem is that it would take so long to develop the behind the scenes systems that the real value wouldn’t be delivered for some time. Plus, these systems are complex projects in their own right – so they’ll probably take several weeks, months or even longer. After which time, lots of money will have been spent, nothing of real value will have been delivered and the opportunity may have been lost.

Why re-invent the wheel?

There are off-the-shelf solutions for so many things these days and they do their job well. You need to process split payments? Try Stripe. You need to have secure user management? Try AWS Cognito. Need to send notifications? Try Twilio. You need tax features? Try Sage. I’m sure you get the idea.

Each of these solutions has millions of pounds (probably dollars) of investment, multiple developers, testers and specialists. Why would anyone want to essentially build a clone of any of these, when their solution probably won’t be as good and will just hinder their long-term goals?

We live in an ‘API economy’ where value is generated by systems working together (passing data between their respective APIs). I argue there’s little to no value generated in building their own version of these systems.

But…I need it to do ‘x,y and z’

This is an argument I have heard before. Some clients have said they want to develop the behind the scenes systems themselves as they have some unique requirements that they are sure won’t be covered by an off-the-shelf solution.

Now, this could (and has been) a well-founded argument, on occasion. However, I would urge anyone to seriously think about whether a specific piece of niche functionality is required, or whether it could be avoided by approaching the problem from a different angle. Custom development takes time, it is expensive and often far more expensive than tweaking a process to fit an existing solution.

Focus on delivering value and quickly

Too many projects get bogged down in delivering nothing of real value. Five, six and even seven figure sums are often spent developing essentially nothing of value. When starting a project, examine where the value lies within the solution. Then turn it on its head and approach it from an integrators’ point of view, rather than from that of a developers’.

Ask, research and evaluate which existing systems could be integrated together with a minimal amount of customisation.

You can then focus on delivering value, which is what it’s all about.