Your Platform Is A City Not A House

Very often in software development you hear that we need to re-platform. The reasons for this are all the usual suspects: Too much tech debt, hard to scale, too long to make simple changes, no longer in a supportable technology, etc..

..and often all very true. However beware of the following

• All platforms contain masses of functionality, often there are internal tools, workarounds or external dependencies that are part of the platform and deeply embedded in an organisation’s ways of working making it unexpectedly hard to change people’s behaviour.
  Result: Despite a new system people resist changes and continue to use the old processes meaning the old systems are never retired resulting in two “legacy” platforms!
• The problem was miss-understood: We though we needed a new platform but if we had looked harder we would have seen that we could have invested differently and solved the problem another way.
  Result: Your call centre software scales but you should have invested in making you app easier so people do not need to call
• Key customers are dependent on functionality in the legacy where the effort is uderestimated to replicate in the new platform
  Result: Either the customer goes or you have to maintain the legacy platform anyway to keep the customer
• Your re-platforming was successful but at the expense of making your product better for your customers
  Results: Your platform is now perfect for your needs 2 years ago, but all your customer's are now with another platform because you stopped building for their needs

There is no denying that platforms need replacing and improving but remember

Your platfrom is a city. You cannot just tear it down and replace it. Much better to solve the problem area by area.

It seems so obvious that there should not be a big bang or an all or nothing approach, but so often this is what is advocated for at the start of a re-platforming but it always seems to end in tears!

Avoid the tears:

• Don’t replace the whole back office, just fix the most used screens/Userr journeys.
• Build a new tech stack in parallel for high traffic functionality.
• Replace an API, but leave the rest alone for now
• Keep the number of use cases and people you need to re-train small then expand out

Before you now it the majority of your users will be seeing new screens, engineers should be happier as some of the more problematic components are gone.

Sure there will still be some sketchy areas that only a few people go to. But if they are clearly sign posted and the visitors know what they are doing perhaps it is OK to accept it in the short to medium term just like not everywhere is a city perfect!