A featured contribution from Leadership Perspectives, a curated forum for enterprise technology leaders, nominated by our subscribers and vetted by the CIOApplications Editorial Board.
IBM
Digital Business and APIs - Need to See the Forest and Trees
As I speak to companies about their API initiatives, the first question I ask them is, “What business reason do you have for executing an API initiative?” Typically, I get technical answers or specific APIs they have built, but not a desired business result.
Conversely speaking about becoming a digital business, I get great answers on business drivers—“improving customer experience through better user interactions”. “Great! How do you plan to execute to accomplish this?” No answer or point projects on web and mobile.
Random Trees
Often IT leads the API Journey in the beginning. There is nothing wrong with this. The web was driven by IT first, later the business became involved, and finally business became the leader. A similar maturity pattern will occur for APIs.
Frequently the mission to create the new APIs is given to the team who owned the service oriented architecture (SOA) initiative. This group, understanding these assets well, builds the APIs on top of their services. This is probably the most common mistake that I see companies make. There is some value in this in learning the technology by creating some basic utility APIs and possibly gaining some IT analytics and security around these assets. However, from a business perspective, all we have done is add another layer to existing assets.
Without a focused business driver, your APIs are “random trees” with little value to the business. They become IT tools for integration and do not drive business change.
Benefits of Seeing the Forest
APIs and the API Economy are all about enabling change for your business. Most businesses that are looking beyond just the technology (I hope this includes yours) are looking for business benefits including:
• Improving speed to market for business initiatives,
• Reaching new customers and new markets,
• Allowing for innovation with high speed, minimal risk, and low cost, and
• Sharing information and assets more effectively across the enterprise.
All of these are supportive of digital business transformation.
Providing focus on business outcomes and planning for initiative execution drives far more business value
With defined business driver(s), we now have context to define projects and start to measure business ROI. Frequent business driven API enabled use cases revolve around:
• Mobile / Web UI
• Social Media
• Data and Analytics access (inside the company and potentially outside as well)
• Partner on-boarding and integration
• Public APIs for comparison apps or other third-party access
• Internet of Things integrated solutions
From business objective to project to API becomes the ongoing mechanism for how we deliver business change.
For our forest to grow, initiative infrastructure and execution issues also need to be considered:
• Security - Paramount for most companies allowing access to their business assets is security. Establishing a strong API Gateway protecting the enterprise assets is critical.
• Flexibility - For most companies, assets are primarily on premise today, but cloud is imminent if not already underway. The ability to manage and secure APIs consistently across on premise and any cloud is necessary because most companies will be accessing assets in several locations including multiple different cloud providers.
• Scale - Granular scalability is important. As API traffic or users or any part of the infrastructure is stressed, it needs to scale without requiring the entire infrastructure to scale with it.
Trees Need Attention Too
We need to build quality APIs to meet the needs of our use cases and business drivers.
Earlier I mentioned that creating provider-based APIs is a common mistake. Instead, I recommend that APIs should be based on the needs of the consumer and not the provider (i.e. services). Sometimes a consumer need may match one to one with a service, but other times this is not the case.
Let’s use a retail example to illustrate this. A retailer has a mobile shopping app with a function to “check order status.” The retail systems include services for CRM, ordering, inventory, logistics, and more. If APIs are built based on these services, there would be four (or more) APIs potentially involved in the “check order status” implementation. The mobile app would need to call the CRM API, get a reply, call the ordering API, get a reply, etc. causing many network calls and parsing of replies. These provider-focused APIs would be built generically based on the service, not consumer oriented and the API interface might change incompatibly if the service is updated. However, if the API is built based on the needs of the consumer, then the API could be very simple. Thinking about what input is required to check order status from a consumer’s perspective, the order number and user identity is all that should ever be necessary to receive the order status. One API call can then query all the necessary systems and come back with the response. A single simple API call versus many and a very backward compatible API—even if the services are changed.
Successful API initiatives mature over time. In your initial stages you will probably build some random trees. Providing focus on business outcomes and planning for initiative execution (the “forest”) drives far more business value. But, for these initiatives to obtain the desired results, we also need to focus on the quality and consumability of our “trees,” our APIs.
