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 David Bressler

David Bressler has written 15 posts in this blog.

David is 'Director, Solutions' focused on the Financial Services Industry spe­cial­iz­ing in SOA, mobile, & cloud inte­gra­tion archi­tec­ture. He is an expe­ri­enced tech­nol­o­gist who leads peo­ple and orga­ni­za­tions to the tech­nol­ogy their busi­ness demands, with­out the frus­tra­tion they expect. David has par­tic­i­pated in more than 10 tech­nol­ogy IPOs, merg­ers, acqui­si­tions, and spin-outs. He has worked in over 25 coun­tries help­ing gov­ern­ments and com­pa­nies imple­ment tech­nol­ogy that increases their capa­bil­i­ties and results. David is an accom­plished pub­lic speaker and facil­i­ta­tor with a knack for cre­atively explain­ing com­plex ideas in a way that is meaningful to his audience. David has an MBA in inter­na­tional busi­ness from NYU Stern School of Busi­ness where he grad­u­ated with dis­tinc­tion. David is also an accom­plished ath­lete and coach; he is an expe­di­tion cave and ship­wreck diver, holds black belts in 3 mar­tial arts, and as a mem­ber of the US Karate Team, a two-time medal­ist in the 1989 World Mac­cabiah Games in Israel.

4 Comments

  • 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.

      David

Leave a Reply


 

Switch to our mobile site