API’s are the New Excel Formula

For those of you who don’t know me personally, or know me well enough, I seem to have a talent for metaphor.

In fact, I think one of the things that I do best is explain complex ideas in ways others can understand, and so that they realize how the idea is relevant to them.

While technically not a metaphor, I really like the idea of comparing API’s to Excel formulas in the context of the “everyone learning to code” trend. It came up in yesterday’s API Management Demystified webinar.

Many businesses run complex models in Excel. In fact, Excel was, in many ways responsible for the JP Morgan Chase “London Whale” that cost them billions. (In my opinion, Excel wasn’t responsible, rather it was a lack of governance that allowed people using Excel to fail in a very big way, but that’s a-whole-other conversation.) James Kwak has a smart article about the importance of Excel to business, and why running a business on Excel is such a mess. James’ key difficulties with Excel:

  • There’s no governance or auditing.
  • There’s no ability to test if the spreadsheet is working (and importantly, if it’s still working).
  • There’s a very low barrier to entry (anyone can create one).

Another thing I’m really good at is being lazy. I abhor inefficiency, and simply refuse to do things twice when they can be automated with just a little extra effort. It’s not just about efficiency, by the way. It’s about art.

When I started my career, I was writing a boatload of proposals for network integration solutions. I totally tricked out Excel. Doing so saved me hours off each proposal, possibly hours a day.

My proposals were art*. Why? I was able to focus on proposal content and the deseign because I had automated so much of the crap-work. Plus, my proposals were simply better because they’d be more correct (I embedded error checking in the spreadsheet each time I made a mistake, so I’d make the mistake only once).

I can’t be the only lazy person out there.

Things have changed since the early 90’s. Today, people are using their mobile devices for everything. In fact, just this morning I took a picture of my wife, my baby, and my iPhone as we were having a family moment! (OK, I’m odd.)

Not everyone is going to want to start their own company. Some lazy people have corporate jobs. And, they will want to write their own applications instead of the spreadsheets that the earlier generation-of-lazy would write.

And, that’s where API’s come in.

API’s will make corporate resources (processes, events, & data) available to lazy people all over corporate America to make things more efficient.

The only thing is, just because “everyone knows how to code” doesn’t mean “everyone understands programming”.

The same challenges that James points out in his article apply with an even greater degree to software.

Why to a greater degree? Because software that uses API’s will be everywhere, not just “locked in Excel”.

That’s where API Management comes in to play.

Companies that want to capture the innovation going on in the mobile & API markets, or that want to take advantage of their most motivated employees (the lazy ones), are going to have to create an environment where problems can be solved with software using digital corporate assets. The only way to do this successfully is to deploy an infrastructure supporting these efforts that delivers governance, lifecycle management, and self-service testing & support.

* I still have some in storage along with the personal letters of thanks from customers.

About Carla Borelli

Carla Borelli has written 28 posts in this blog.


  • Great article and probably understated, in terms of the importance of getting APIs right. Imagine if the same excel mistake (which transformed the level of risk a company was exposed to) was sitting inside a commonly-used API. The problem just grew to be exponentially larger and more complex.

    • Chris!

      Exactly. Funny thing happened, a couple of years ago when API’s were known as Services a guy at a bank had written an HR service. It was secured, and he only shared the WSDL with a handful of people. One of those people included their credentials in the API/library that they created, and all of a sudden there were some 30+ applications using the API service.

      We found that out because we have this magical product that draws pretty pictures based on service calls, identifies consumers, and tracks end-to-end flows (see the reference to “Automatic Transaction Tracking” on that product page).

      The truth is, even the best “catalog” of service assets in the world is out of date as soon as it’s created, so there’s simply no easy way to govern everything that exists. And, because complexity grows non-linearly, we can look at tons of examples where it scales but hasn’t quite fallen off a cliff like would be experienced at most large companies. That’s one thing software companies should be better at, because we know how to write software and create products. But most companies, they just know how to write software, and write more software, and more.

      It’s like the difference between knowing how to code, and understanding programming.


Leave a Reply