Guest post by John Falkl. John Falkl is the General Manager of Technical Strategy and Integration at Haddon Hill Group Inc (HHG), an IBM Premier Business Partner. Before joining HHG, John was an IBM Distinguished Engineer and CTO of SOA and Application Services Governance at IBM. He has 35 years of experience across all roles in Information Technology, specializing in SOA, Enterprise Architecture, Middleware and enabling API Management.
Many large enterprises have made valuable investments in SOA and service governance. In fact, implementing API Management on top of a well-established SOA infrastructure is much easier because the service-oriented discipline, processes and measurements are most likely already in place.
But what if you already have a well-established service governance and management process? How can you leverage this to embrace APIs? One way to think about this is just to imagine APIs as external representations of business ‘endpoints’ that are marketed and treated as ‘products’. These APIs most likely are going to consume backend enterprise services similar to how existing internal services do. How can you manage these dependencies, establish service-level contracts, etc.?
Haddon Hill Group has been working on this issue. This capability would provide enhancements to your registry & repository metadata and lifecycle models to include API definitions.
First, establish a very simple API lifecycle model, something like “Identify, Specify, Test, Publish, Deprecate”. This simple lifecycle model is terrific for providing initial lifecycle management for APIs. Then, augment your governance profile to include API definitions like an API service version. This would be the anchor in order to establish contracts to other services thru common mechanisms like service-level definitions (SLDs) and service-level agreements (SLAs). This provides a formal mechanism to track dependencies of APIs on backend services, as well as consolidate important API metadata.
This capability provides an easy way to start governing APIs in a way similar to how services are currently governed. Based on needs, this model can be extended to include all kinds of important information you wish to track.
Haddon Hill Group has built these new definitions and included them in a governance profile for WebSphere Services Registry & Repository (WSRR). We would be happy to provide consultation services to clients with this need.
Don’t let sloppy development practices ruin your API Management program
New API initiatives are a great way to explore increasing new business and exploiting other routes to market. Since the paradigm with APIs is to treat them as outward facing persona representations of your business, it’s critical to make sure the APIs you expose are very efficient, easy to use and well supported. It only takes one or two bad experiences by prospective consumers to tarnish your representation.
With advancements in technologies like REST, programming models are becoming much simpler. WSDLs that were 40-50 lines of code are being replaced by RESTful calls of one to two lines. Since consumer experience counts much more than ever before, you should take the time to analyze your SDLC and devops processes to ensure you are not injecting inappropriate development disciplines into APIs.
As an example, the REST Maturity Model (developed by Leonard Richardson) outlines four levels of maturity for REST: Level 0 (initial, using HTTP as a transport system), Level 1 (Resource focused), Level 2 (exploiting HTTP verbs) and Level 3 (Use of hypermedia controls). This provides for a progression of how to make your RESTful APIs more optimal depending on their needs. You can use various techniques outlines in the model to make your integrations with consuming applications very efficient, and avoid ‘chatty’ types of interactions.
This is just one of many types of focus areas you should consider. The overall point is that since your company is embarking on a new technology initiative to increase business, why not evaluate your use of technology to make sure it’s right for the task?