Posts Tagged ‘IT’
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.
Nick Malik posted this response to my previous post on governance and decision rights. In it, Nick claims that what I posted was a workable set of decision rights, which I partially agree with. He made three comments on quotes from my post, and it is the third where I disagree. He stated:
“If we focus on creating policies” — And here really is the confusion. What are those policies called? They are called “decision rights.”
While a policy can be statement of decision rights, such as “All solution architectures for projects costing more than $X must be approved by Enterprise Architecture,” they don’t have to be and I argue that the majority shouldn’t be. A policy like “All services must be entered into the registry/repository at the time they are identified.” is not a decision right, rather, it is a statement of expected behavior. If followed (in conjunction with other policies), the expectation is that the goals will be achieved, such as reduced redundant implementations of business logic. If goals aren’t reached, you need to revisit policies and processes, or even the people involved.
Decision rights are certainly part of governance, but a view that makes them the defining part is wrong, in my opinion. If we focus too much on decision rights and not enough on decisions, we are at risk of creating fiefdoms of power that perpetuate the negative, command and control view of governance. If we focus on policies that enable anyone to make the correct decisions, I think that is a better position for success.
Shameless plug: Want to learn more on SOA Governance? Check out my book by the same name, available now for pre-order and generally available in late October 2008.