1. Blog

7 ways to make it easier to change your backend system

Definition of a backend system

Another name for the database and associated value-adding online processes which help you to run your organisation.

The life cycle of a backend database

There is an inevitable life cycle to any backend system, which has been known to run something like this:

Year 1

  • A growing and unavoidable realisation that you need a new backend system
  • Try and communicate to your in-house team – or more often with people outside your organisation and culture – your vision for the new system, how you imagine the future, what is important to you.
  • Put it out to internal consultation, because you don’t know exactly how everyone uses the system on a day-to-day basis
  • The deeper you dig and the more people you ask, the more issues and workarounds that you unearth. People seem to be using Microsoft Excel more than they’re using your system!
  • At some point you decide to stop asking people. The scope goes from being fairly straightforward to actually being rather complex.

Year 2

  • Decide who is going to do the work for you
  • Scope the requirements of the new system. This work is hampered by your busy period, staff holidays and the festive season. Your plans to get all this done for Christmas 20XX begin to fade.
  • Confirm the functionality and officially sign-off the technical specification and functional specification.

Year 3

  • Everything goes quiet whilst you get the thing built. Start to realise what you’ve missed out of the original specification and start negotiating for a few things to be added, hopefully for the original price if we invite you to the Christmas party.
  • System is launched 3 months later in your quiet period. Deal with all the teething issues, staff retraining, and see the system bed in. People start to like the new system and start to forget the old one, except those people who were involved in specifying the old system, who will never forget it

Year 4

  • Complete the additional work which was destined for Phase 1, but which got left behind due to time or budget constraints
  • Everyone is happy and don’t know how they coped with the old one

Years 5 to 7

  • You stop making any further changes to the system, because frankly it’s already cost enough money, and it should be fine by now. People need to stop complaining.
  • Staff begin using workarounds as the business continues to evolve
  • Work-arounds start becoming much more prevalent. Microsoft Excel is open on most desktops most of the day. You don’t spot it.
  • New staff are inducted with a mixture of formal “This is how to use the system” and informal “This is how we use the system”.

And you’re back at Year 1.

Whilst this clearly can’t be the case in all organisations, it is a picture I have encountered in many. More often than not, the overwhelming urge to run for the hills at the thought of going through the whole process again is enough to stretch things out for at least another three years. With the realisation of the need for change at 10 years, that could be 12 years before the new system is introduced.

7 Ways to make it easier to change your backend system

1. Don’t stop evolving

From the timescale above you can see how the moment you stop developing your system is the moment that people start working around it. Perpetually listening to those people on the front line ensures you stay as responsive as possible to your clients. Not everyone agrees on the way forward, and some people are much more constructive in their recommendations for change than others. Over the long term, it’s possible to recruit people who are more comfortable with a perpetual change model, and are hired not only to use the system, but to spot incremental ways of improving it.

2. Pick your partners well

If you don’t have an in-house team and you need to go outside the organisation for your coding expertise, it’s great where possible to pick a bunch of people who have experience working within your industry and also who you get on with and trust. And it’s all very well them being friendly during the sales pitch. Try and spend more time with them than that, as it’s a long journey you’ll be taking together. Like any busy bus ride will tell you, you need to be sitting next to the right person.

3. Start the process before you have a problem

Not only should the finetuning be ongoing, but you should never stop updating your background technology either. These days it’s getting much easier with a dazzling array of off-the-shelf yet highly customisable systems plus better and better functionality from both bought-in and custom solutions. You’ll still end up wanting to change whole systems down the line, but by keeping your backend stable and working, you’ll be able to plan ahead with a clearer mind.

4. Code in a language which many suppliers can use

Find out what language your coders are using. For example many systems these days are built in php, which is a language that millions and millions of coders know and love. This means that even if you fall out of love with your existing supplier, you won’t be left high and dry, and another organisation can pick up the reigns, but…

5. Don’t let your code base get too tangled

Just like when you move into a house that successive generations have tried to rewire, the more adaptations you make over time, the more spaghetti-like the wiring will become. Where possible, seek out solutions which have a way of standing the test of time. For example, with big off-the-shelf solutions like Salesforce, the frequent and tiny updates mean that your whole code-base can evolve. Custom solutions can be made to work in this way too. Although the codebase of your backend system might be the last thing on your mind, it’s worth remembering that coders as a rule absolutely hate dealing with legacy (old, tangled) code.

6. Remember that your system needs to evolve with your business

You have no way of knowing how your organisation is going to change in the next 7 years. No way at all. You have no current understanding of how your business processes will be working, how your staffing will be arranged, and how sustainable and viable your organisation will be. Therefore it is equally unknown what your backend system will need to be like. Therefore the development, modification and adaptation of your backend system needs to be as dynamic, fluid and agile as your approach to everything else.

7. Budget for the new system from the start

If you’ve taken out a loan on your original system and you’re writing off the debt over umpteen years, maybe the very last thing on your mind is to start putting money aside for the new system. However by refusing to acknowledge that you’re going to have to invest in the future, you do three potentially harmful things. First, you don’t allocate enough to system enhancements in the later years of the life cycle, second, you put off consideration of the new system for too long, third, you risk becoming out of sync with the changing needs of your clients and the marketplace.