I’m going to take a quick break from my industry tour of APIs to cover two questions I’ve been asked about quite often recently:

  1. “What is the recommended organization and governance structure for an API initiative?”
  2. “Is this analogous to what we did for Service Oriented Architecture (SOA) Governance?


governance

Before attacking the questions, there is a basic statement about Governance that I have been using for the last 10 years that can help with this discussion. That is,
right-way-wrong-way
“Governance should make it easy for people to do things the right way and hard for people to do things the wrong way”. In general the least intrusive approach to governance that accomplishes this is the best option.

 

Looking at the second question, “Is this (API Governance) analogous to what we did for Service Oriented Architecture (SOA) Governance?” the short answer is “No”. The drivers for SOA were primarily Reuse, Sharing, and Encapsulation. These sound similar to API management but there are some significant differences. The meaning behind these terms for SOA was largely focused on delivery. It was about the effort to deliver a capability, that there would be less to change and to drive the sharing of existing capabilities rather than experiencing duplicate costs to develop nearly identical capabilities. In this environment strong governance was required to drive this behavior because historically people executing projects did not behave this way. Projects or lines of business tended to want to own all the assets they needed and sharing
SharingKinder
was a challenge. Our kindergarten teachers would be ashamed! This led to the need for a relatively heavy governance structure to create and drive the desired behaviors and results.

 

For API initiatives, we could say that we have the same drivers – Reuse, Sharing, and Encapsulation. The difference here is that the focus of these is around Speed for consumers and Reach for the business (see my earlier blog post – here). The existing behavior of the intended consumers of APIs is a desire to consume the APIs, and very much not to duplicate effort. So, there is not a need to try to change this behavior. The need for Speed which would suffer from a heavy governance implementation and the lack of a need to change behavior leads us to a much lighter governance structure for API initiatives.

So, moving to question 1, “what is the recommended organization and governance structure?” A core team should be formed to help drive the initiative. This should include 3 roles:

  • API Business / Product Manager – owns the business decisions (which APIs, entitlement levels, monetization, etc.)
  • API Development Leader – owns the technical aspects of API development
  • Operations Leader – ensures performance, availability, scalability, etc.


organization

The actual number of people assigned does not have to correspond to the number of roles.

The core team is commissioned by an executive steering committee that funds the initiative, commits the necessary resources, and supports the API initiative direction. Of course, the executive committee will want to see progress, so metrics and reporting should be identified.

Within any enterprise there are often many domains which may wish to implement APIs (e.g. supply side vs. sell side, Consumer or Business sales, or Life, Auto, or Home in the insurance industry). The domain owners will work with the API core team to identify the required APIs, internal systems that need to be accessed, and target audiences for the API.

For internal API initiatives, the App development teams will also identify requirements for necessary APIs.

Integration architects and Service owners will also participate in the initiative. However, this should NOT be the team that leads the initiative. If this team is given control of the initiative then the business aspects and simplicity of API definition have less chance to occur.

The aspects that need to be addressed in the governance model can vary with the amount of control that the organization has over the target consumer of the APIs. So, less governance of the initiative is required for internal developers (being part of the same company), than there is for partners or public API initiatives. As most initiatives are starting internally and working their way outward, the required additional governance considerations can be added to the early governance implementation as the initiative grows to new consumer audiences. For example:

  • For internal developers there is less of a concern about versioning, since we can convince the internal developers to move to new versions. This becomes more important as we deal with external developers.
  • Monetization for internal audiences may either not exist or consist of charge backs, where partners or public APIs may need to receive or send funds.
  • Entitlement enforcements may be soft for internal developers, but hard limits for public APIs.
  • The need to address Privacy, Legal and other aspects may grow as the audience moves outward from the company.


success
If you build it they will come – does not work! Communication is always critical. I believe this is the key to success. No matter what your audience for the APIs, they need to be educated on how to find the APIs and consume them. Various techniques such as lunch and learns or hackathons may be used.

Communication is also required to the executive steering committee. This typically relates to established metrics. So, it is important to have set target metrics in advance and communicate the status of the metrics on a regular basis. Technical metrics may also be extremely valuable to look for areas of improvement in your implementation.

This is not intended to be an exhaustive discussion on API Governance, but to show some of the critical areas of focus. I’d be interested in your thoughts and happy to discuss this further as required.

Connect with me through comments here or via twitter @Arglick to continue the discussion.   You can also read my earlier blogs.

 

 

Join The Discussion

Your email address will not be published. Required fields are marked *