API First: A Business Priority

When people talk about APIs, it's often with respect to developers. Most people on the business side probably don't know what an API is - but they really do need to - so here's a quick (and loose) definition:

An API allows developers to:

• Extend the software you have, so it does everything you need
• Make different pieces of software work together
• Integrate and connect software with other things
• Write new applications using existing technology and data

 Sounds pretty important right?

APIs unlock business initiatives and makes them much more likely to be successful.

Everyone should love APIs!

For me, APIs have significantly changed how we deliver technology - not just how we develop it. Here are a couple of things I've noted from my work at ManyWho.

Radiant Thinking

When you're building software products, the first thing that always comes to mind is the user experience and the user journey. However, it's important that that's not how software is built. That is a very common mistake in the industry - the result? You're locked into a very specific set of ideas rather than having the option to enable a seemingly limitless set.

It's similar to Mind Mapping. I had the pleasure of working with Tony Buzan, who's the leading voice on the subject. I helped design the first versions of iMindMap for him - and a lot of that thinking went into how we build ManyWho.

When Mind Mapping is done properly, it hugely stimulates the mind to think more radiantly. What do I mean by radiant? It makes it easier for your mind to connect ideas and connect memories - the result being that you think more expansively, more deeply, more creatively. You can read more on Mind Mapping here.

In technology and APIs, it's very similar. When products are delivered for a single user experience, that's all you're getting. You don't tend to think outside of that box. When a product is delivered as an API, it unlocks the potential to do so much more. I'll give you an example from a recent customer...

They wanted to deliver an app that helps sales people enter new leads. Stop 1, was a simplified form to enter leads in a very focused app. Not particularly interesting.

Where did we end up?

A messaging solution that texts you 30 minutes before your meeting with focused customer information needed for the meeting. At the meeting it prompts you to take capture new attendee information directly from LInkedIn and take down basic details. After the meeting the app calls you for meeting notes which are automatically transcribed and put into Salesforce, creates follow up tasks, etc. You even have a quick text conversation with the app and it puts that data in the right places. It's like having your own personal executive assistant. No more CRM data entry, it's integrated into how you work, not a job you need to do.

And how much complicated code did we write? None actually. Pretty freakin' awesome. That's the power of APIs and connected platforms. You can get seriously creative in how business problems are solved. You can think much more expressively about how users engage. That's radiant thinking.

Inverted Architecture

Particularly in the BPM and workflow space, there has been a lot of talk about open source and open source workflow products. This is similar to what's happened with technologies such as databases. Though I don't think my thoughts on this apply universally for open source, I think they're pretty accurate for many of the "enterprise" projects.

What's the real business message around open source?

Because you have the code, you can change it. That means you're in control.

There's often also talk about "community support" but very few enterprise projects actually have that kind of engagement (with the clear exception of Apache). It's typically one vendor doing all the work and very few are really helping develop the code.

I had a conversation about the inverted architecture of APIs with an analyst at mwd (they also produced a report on us here) and this idea came out. I'll expand on that a little more...

Very few people are qualified to make changes to a workflow engine, or a database engine (speaking more broadly). You need a large amount of industry expertise to get into the code and confidently make adjustments. And the reality? You very rarely, really never, need to.

Most of the enterprise vendors that talk about open source know this. So what's really happening is that they capitalize the bits you need around the edges. And those often come with hefty price tags. For example: need a particular feature or tool to make your project successful? That's not free. You could code it all yourself from scratch, but that's a huge amount of work. Unfortunately, all too many of these vendors know where the pain points are likely to be and actively omit critical features in the open source distribution. So, you get introduced to this new "not so free anymore" reality too late in the implementation lifecycle. You're half way in, and it all starts to look pretty expensive, pretty fast. These projects are not designed to make you successful with the "free stuff". They're designed to make the vendor money through enhancements and consulting.

With APIs you tend to invert the architecture - particularly when the vendor treats APIs "as the product", not "as a feature of the product".

What does that mean? The core is managed by the vendor to give it cloud scale, security, and ensure it's fully managed. It's the edge stuff that's open and free - because it sits on top of the core APIs. This means all of those "last mile" issues. All of those "this is a bit unusual, but the customer needs it because of their unique situation" issues are much easier to manage.

The reason it's open and free is that the "edge" stuff in your projects are often the things that are specific to your organization or industry. The goodness is that your developers are substantially more qualified to solve the edge problems. It's much easier for you to be successful. It's much more guaranteed that you'll get what you want and need - without the PhD in workflow kernels of database engines.

That's the inverted architecture of APIs. It's most importantly about customer success, not developers.

So hopefully that gives you a little food for thought on APIs. It's time they're treated as a business priority. Not just something for us geeks.

Steve is the CEO of the cloud workflow company, ManyWho. He lives in San Francisco with his wife and three children. When not working to better the world of enterprise application development he can be found amusing his kids with his guitar playing.