Un-API dinosaurs can't leap the legacy chasm
Don't you just hate it when something you despise turns out to be right? The word "consume" has insinuated itself into the language of internet services in some stupid ways. People don't "consume" content — they watch movies, or listen to music, or watch films. Nor do they "consume" apps. They use them — to book a flight, or buy flowers, or play games.
But the "consumerisation" of services — an ugly word, I know, but move on — is now vital for the success of businesses. Yes, right now, as two very different personal experiences this week showed me.
The first was chasing up payment from an organisation I'd recently done work for. My email prompted an out-of-office message; the relevant person wouldn't be back until next week. So who was covering that person's job and handling payments? Who knows.
Maybe I should be grateful that they'd remembered to set a message at all. But why can't this be automated? The organisation in question has a high-end human resources system. Why can't it automatically set up an out-of-office message the moment that leave is approved?
Featured
Given that the HR system knows who supervises who, and who assists who, why can't it also automatically set up the contents of the out-of-office message — perhaps a default that lists the generic contact email and phone number for that unit?
On a side note, there's also the question of why workflows are built around sending unstructured emails to specific individuals, who may or may not be on leave, or may or may not have even left the organisation. Building office workflows out of unstructured emails is the same architecture as the late 19th century information architecture of typewriters and errand boys, but with a dozen extra layers of complexity that can go wrong. But I'll shout down that rabbit-hole some other time.
Adding that sort of functionality shouldn't need much code. Surely no more than a few dozen lines, even when some subtleties I've doubtless overlooked have been taken care of? People who know HR systems soon dissuaded me of that naive notion, using words like "Oracle", and "SAP", and "IDAM".
SAP and Oracle make it almost impossible to integrate these things, I was told. No, unstructured email it must be, with human minions converting the data from one system's format into another's using their fingers.
My second experience was setting up a crowdfunding campaign in Pozible to resurrect a podcast. With Pozible's newish subscription functions, I could create a funding model much like that for community radio — what Americans call "public radio" — with people committing regular monthly payments. To set this up, however, I'd need an account with payment service Stripe.
Connecting Pozible to Stripe wasn't exactly a complex integration task. I opened my web browser, logged into both, entered the account details of one into the other, and OAuth worked its magic. Done.
It felt like I was working in a different world.
I was.
This wasn't the enterprise IT world of monolithic systems from monolithic global corporations that promised to do everything for your business — or at least "everything" that they'd decided to include, and it's up to you to adapt your business to their way of thinking. Where the vendor will charge you big bucks to arrange for some of their people to come over and adapt your way of thinking to theirs.
It's about big systems, big customers, big money, and big profit margins.
This was the rapidly-evolving cloud world of small pieces loosely joined, where the services provided by the business are exposed as a clearly-defined application programming interface (API). Where everything is so simple that having to "adapt" to their way of doing business doesn't even make sense as a concept — because the business only does one thing, and you either need it or you don't.
It's about many, many small customers, many small transactions and low margins — but just like a supermarket, they make up for it with volume.
"Businesses have to actively reinvent themselves as APIs," futurist Mark Pesce told ZDNet in August 2012. "The world of business in the 21st century looks a lot more like Lego than it does like Monopoly."
Connecting Pozible to Stripe is a clear example. Down the track, when I want to sell something else, maybe I'll want to sell through someone other than Pozible, or take payments through someone other than Stripe — but I can connect and disconnect those things as I need.
What's more, if I'd done this in Enterpriseland, I'd already be tens or even hundreds of thousands of dollars out of pocket. In Internetland it hasn't cost me a cent of my own money yet, because I'm only charged as I use these services. It's only cost me a little bit of my own time, and yet the system can scale up dramatically from where I'm currently playing.
I only had to mention on Twitter that I was connecting Pozible to Stripe, and a Stripe employee was there, offering me help. I haven't started accepting payments yet, but this sort of thing gives me confidence. Even if it all falls in a heap, what have I lost? Just a little bit of my own time.
If legacy businesses want to adapt to this new world, they'll need to change. But can they? Aren't these worlds simply too different? A product manager working through a channel manager so that channel partners can discuss options with a potential customer's executive team — no, that doesn't happen here.
What do all these people do when every single aspect of their day-to-day work can be replaced with the single sentence: "Have a look on our website"?
How will all these people adapt when they're generally older, and have mortgages and school fees to pay, and seek stability? These people are used to setting out-of-office messages saying they'll be back in two weeks. Compare the age profile in these big vendors to, say, the youthful faces of Stripe. There's something to be said in here about energy levels, the ability to learn, appetite for risk, and being a digital native.
If I wanted to build an aircraft, I wouldn't start by getting a steamship, gutting it and adding wings. I'd just build an aircraft. The same goes for trying to turn a legacy IT services vendor into one that's presented as an API.
The legacy chasm, I call it, and dinosaur IT vendors can't jump that gap.
What's more, those dinosaur vendors provide the infrastructure for dinosaur companies. Can those dinosaur companies change? I'm not sure they can. Can you build an aircraft out of steel girders and concrete?
Maybe the message of the API revolution is that it really is better to start from scratch.