Digital @ Scale

Everyone’s doing it – rushing to make their business more digital.

I know organisations that have assigned hundreds – sometimes thousands – of people to these digital missions. What’s more, they’ve hired or even acquired shiny new offices to house this army of digital drones. And, believe me, stepping inside one of these buildings really does feel like you’re entering a hive full of worker bees. The place is buzzing – but could all of this energy and expense be put to better use?

The answer is an emphatic ‘Yes’. So, let me tell you why…

Bees are social insects. They thrive in large, highly organised colonies with sophisticated channels of communication and precise divisions of labour.

Unfortunately, the same cannot be said for many companies. In a chaotic jumble of good intentions, teams are attempting to digitise every customer journey and product. There is little cohesion. And no sense of shared goals. To me, it looks like a fleet of buses following their own routes with the vague aim of arriving at the same destination, at roughly the same time. It’s a recipe for congestion, frustration, delays and spiralling costs.

But it doesn’t have to be this way.

Anyone embarking on such a journey (and have no illusions, digitisation is a very complicated journey) needs to establish a number of upfront imperatives:

1. Start with a clear idea of where you are all heading. For example, what do companies plan to deliver to customers at the end of the journey? Also remember that goals can be moveable – management may want to push the boundaries and re-define destinations.
2. Provide some stops and comfort breaks along the route – each one should offer something of real value to customers.
3. Create a masterplan and prioritise all the journeys you want to digitise.
4. Develop a standard way of progressing any journey with, as far as possible, the use of common tools.
5. Assess your infrastructure. You may need to repair, replace or modify parts of it to ensure a smoother, faster journey.
6. Look and plan ahead – clear all the key lanes of congestion before people reach them.
7. Keep ‘lanes’ open whilst you are overhauling them. An example of this would be the use of middleware in front of a legacy system that is going to be replaced. Any new digital system should interface with the middleware – isolating it from any remedial work being carried out on the legacy system.
8. Finally, if your aim is to deliver new features on a regular basis (like all of the apps on our phones), then you will need to architect your apps in a very specific way.

It’s a long list of imperatives and, not surprisingly, many organisations choose to focus, at the outset, on just a few of these priorities. I wouldn’t argue with that practical necessity – but I would argue strongly that the 8^th imperative is possibly the most crucial priority of all. If you get it right, you will be able to spin up more work and make the fastest progress.

Let me explain…

The challenge is always to create flexible, extendable apps. This will allow you to release them, at MVP status, in the certain knowledge that you can add new features the instant they become available. And you can do this without having to rewrite any of the code. Effectively, this avoids any need to build monolithic apps that demand changes every time you want to add, alter or subtract a feature. That, I can assure you, is a total pain in the proverbial.

To achieve such flexibility, however, is a dark art. I know because I have recently spent some time with one of the UK’s leading app developers. They have been helping a global bank to develop their next generation of mobile app. It recently launched to national acclaim and an App Store rating of 4.8 – right at the very top of the customer approval scale.

This experience, and I will be happy to share more details and introduce you to the app team, has taught me that there are some absolute fundamentals in design development.

To put it simply, an app must:

• Be developed natively rather than on platforms such as Apache Cordova. This helps to incorporate new phone OS features more swiftly and prevent you having to develop for the lowest common denominator.
• Be highly modularised using code isolation and loose coupling to avoid the knock-on effect of changing code in one particular module.
• Incorporate feature toggling (such as the ability to reverse a feature if a problem is encountered without compromising the integrity of the whole app). The same function allows you to add features without impacting the existing app. There are at least two different ways of achieving this result.
• Follow a style guide to ensure consistency and best practice so that all apps and features appear to have the same design integrity. However, make sure this style guide recognises the different interface styles used on Apple and Android phones.
• Be designed so that any data captured by one feature of the app is made available throughout the app. This eliminates the need to request/capture data more than once.

Follow this path and you will create a far superior app for your customers/users. You will also be able to work – in parallel – on several journeys. This will allow you to implement them in almost any order you choose and so keep the apps fresh and up-to-date.

The alternative is monolithic apps that will suffer if any part fails. Apps that will take much longer to develop and end up being almost impossible to maintain. In short, apps developed by a hive of well-intentioned drones who deliver precious little honey.