Todd Biske: Outside the Box

Archive for the ‘Microservices’ Category

Kin Lane, the API Evangelist, had a really good post on maturing an API program, with the not-so-brief title of “I Have An API Deployed, And A Base Presence Established, What Can I Do To Help Me Get The Word Out?” You should definitely go read that because there’s some really good advice there.

What was very clear to me is much of what Kin and others talk about is essentially turning your API into a product and applying the discipline of product management. Set goals, identify your prospects, create marketing material, highlight the success of your customers, understand your competitors, provide good support, etc. I think it’s important for the technical audience to understand that these concepts aren’t new, even though they might be new to the technical crowd. As I know from my own experience, we technologists will flock to new technology just because it’s a shiny new thing to try out.  Unfortunately, that doesn’t make for a good product strategy.  Just as a blog of mine a long time ago on communications suggested bringing a communications expert onto your IT team, it’s also a good idea to have someone with product management experience work with you on your API program efforts.

The one thing in Kin’s post that I had a slight disagreement with was his section on goals.  While his goals were valid, these are really secondary goals to what is absolutely the number one goal: revenue.  Now, I’ve read enough of his other posts that I know he gets this, but I don’t think it can be emphasized enough.  I began my career in development and have always been on the IT side of the house, and for many, many reasons that I won’t go into in this post, too many people in IT really don’t understand the revenue models of their companies.  So, if you don’t understand how your API program will impact revenue, go back and figure it out.  You may be able to charge directly for API use and fund your own operations. It may be less direct revenue, such as how Walgreens’ photo APIs eventually result in revenue through in-store photo printing, rather than a fee for API use. Growth in new users might be great, but if there isn’t a revenue model, it will eventually become a cost sink.  One only needs to look at the number of press releases about public APIs being shut down to understand the importance of this.

All in all, Kin’s post is really, really good.  It calls out a number of specific things to do when your product is an API, so follow these things but also complement your efforts with some general purpose product management knowledge and you’ll be in a position to make good decisions.

TechTarget has published another one of my “Ask the Expert” columns.  In this one, I offer up my thoughts on the differences between a Microservices Architecture and a SOA.  In a nutshell, I think the microservices trend has moved things in the right direction, a direction that many of the SOA pundits were espousing back in the mid-2000’s.  Regardless of what we were saying, however, there’s no denying that the reality of SOA back then was still more of service enabled architecture then service oriented architecture.  Give my thoughts a read, and feel free to post comments and questions in the discussion section over there.