ShowHide categories

What is agile, really, and should your payments system be agile?

Future banking

Possibly the most abused term of 2017 already, “agile” is thrown about with complete abandonment. What does it actually mean – both in terms of what the users and abusers think it means, and what impact it has on your operations?

The dictionary puts agile firmly into the world of movement. Predators tend to display agility, as do their prey. It is a curiously unit-less quantity, a measure guided only by the survival of its adopters. Nobody talks about milli-agile or kilo-agile, it is both unitary, and relative. The converse term is clumsy, or perhaps leaden, when applied to the dopey Wildebeest at the back of the herd, being taken down by all those agile lionesses. Agility is all about a sense of balance, an ability to move fast and enough situational awareness to figure out whether you are lunch today, or not.

Absolutely none of these preceding concepts applies to the IT world use of the term. When an IT person thinks about agility, they are primarily thinking about time, not physical movement. When something is agile, it is able to change without massive destructive effect, in a short period of time. Specifically, a period short enough to prevent the marketplace from turning away.

Can payments be agile?

So how does this apply to payment systems? There’s definitely a case to be made for saying that payments are not in the least agile, and that this is how banks like them – and their customers. Vast reserves of banking programs in COBOL demonstrate the actual benefit – and clumsiness – of this class of business activity, now getting on for a half-century in distinctly unagile, deeply dependable operation.

The gotcha clause around agile is that it doesn’t only apply to the IT investment in a business; it applies to the processes, the equipment, the distribution methods, the business model. Pretty much any part of a CEO’s list of pain points can be evaluated for agility, and competitors can turn up and simply take all those toys away, because they have innovated and the market is heading in their direction, not yours. At that point, the criticism of old school IT is that it can’t move fast enough to adapt, and that cloud services inherently can.

The measureless – but comparative – nature of “agile” is little help here. A good cloud payment system displays a high degree of both modularity – many plugins to many APIs, for example – and customisation potential, even in matters as simple as reports. This is against a background in which some accounting products deliberately encrypt their data to actively guard against custom reporting, as a revenue driver for the developer.

So on the one hand it can seem as if hardly any effort is needed for IT to respond to the agility of a business working in a shifting market. But on the other hand, IT can also be thought of as the ice-skater at the end of the whiplash line, with relatively small changes in business practice demanding quite large alterations to IT services.

Even though the word services there just sidesteps a proper and more detailed description, it is accurate, because agility as a target is a powerful driver of a much more measurable attribute.

That’s diversity. Where many large businesses (and large software houses) believe that drawing all functions into ever more centralised, overarching software suites is the right way to exercise control, the true nature of agile business is not that it should be served by fantastically high-IQ abstracted mega-systems, it is rather that a spread of sources of IT functions is the best way to look comfortable when replying to the question “are we agile?”

Some on-premise machines and software (eg: ERP, accounting), some pure hosted (eg: website), and some cloud services (email, offsite backups, test and dev, IoT). Agility then arises by being able to move a business demand from one of those categories, to another.

Which brings us to the verdict, on payment systems and agility. The answer reveals more about this buzzword than it does about a payment system. What you want from payments is a stable, trusted platform (so not agile, then) that acts as a base for ad-hoc queries (is report-writing really agile? In finance software – yes).

Most importantly, when the next PayPal or Bitcoin or Blockchain-oriented third-party link arrives, that stable base has to be flexible enough in code, and well-enough supported that it can quickly adapt. Is it helpful to discuss all this from the perspective of a single measureless term? Only so you can show how unhelpful it is. What’s the point of a measure by which a product can simultaneously pass, and fail depending on the speciality of the assessor?

When someone brings up agility, don’t treat it as a badge of hipness or leading-edge presentation. Treat it as an invitation to be cross examined.