A lot of enterprise IT concepts and tools have experienced dramatic change in the last decade. Several long-lived rules of thumb have faded into irrelevance. However, one conceptual holy grail has survived the volatility of the IT transformation toward all things cloud, DevOps, and APIs: reuse. Like historical explorers seeking the Northwest Passage, enterprise IT executives have long sought out ways (e.g. SOA) to drive down the cost of solution development through code reuse.
It was not that long ago when one of the prime reasons to adopt enterprise source code control was because it was a component of a reuse strategy that never quite seemed to pay off. Over the last decade, SOA died (at least as an approach to drive reuse at the enterprise level) and RESTful APIs have moved to a position of prominence given their ease of driving omnichannel strategies.
Now that API-led transformations have demonstrably unlocked both code and component reuse for enterprises and small shops alike, a set of easily understandable KPIs have begun to emerge to measure how well an IT shop has integrated the ethic of software reuse.
IT shops have long strived to achieve and measure software reuse across a portfolio of assets, but with the proliferation of API-led transformations, enterprise IT shops have never been as poised as they are right now to enact and measure the concept of software reuse across an enterprise. RESTful APIs have been the key to this phenomena specifically because they democratized SOA via the HTTP protocol — which was also the key to the proliferation of the World Wide Web.
Now that API implementation patterns are mainstream and engineers can effectively take advantage of reusable components without having to tightly couple or make a duplicate copy of code for basic reuse, the prime question shifts from “what can we do to enable software reuse?” to “how can we instrument and measure our software reuse?”
Whence APIs and Instrumentation Came
Before diving into individual KPIs, it is critical to understand the role and importance of instrumentation. Historically, most enterprise monitoring and alerting strategies start and end with a set of business and operational KPIs (e.g., core financial KPIs like revenue and customer engagement, core operational KPIs like MTTR and MTBF). This model falls short of the requirements of a software driven business (which is rapidly becoming a requirement for any business of significant scale).
In order to effectively and sustainably run a software driven business, having easy access to a set of modern metrics that track the creation, operation, and reuse of technology access has become a “must have” requirement because:
- Tracking and driving reuse through instrumented sources is necessary to help drive the spread between productivity and labor curves for a technology shop; this is because reuse is a prime method of growing revenue at lower incremental costs. This widening of the spread between these curves serves to fend off digital disruption from competitors who are no longer bound by historical barriers to entry.
- Tracking and driving technology health metrics through instrumented sources including, but not limited to, speed, quality, reuse, cost per feature and others is necessary to build and maintain trust between organizations with different near-term goals and objectives.
A key concept in these points is that the metrics themselves have to be instrumented for automated data collection. In regards to any individual or group of metrics, without an automated data collection capability, the ability to track and measure the performance of any individual metric will often compete with the urgent and passionate requests to improve the performance of the metric all while people try to argue about the value or precision of the metric itself.
The ease of collection, aggregation, analysis, and dissemination activities is the best tool for fact-based decision makers to avoid “enterprise metric fatigue.” Once fatigue sets in, it is only a matter of time before a technology shop is cast down from situational awareness into blindness by those who believe that “reporting on the work” comes at the expense of “doing the work.” Shops that are blind to process control KPIs lack the fundamental tools to improve their output because they can’t measure the impact of any changes in their approach without, once again, being trapped by the above catch-22.
Check out part 2, where I discuss a number of reusable KPIs in detail – from APIs consumed to channel types per API – that enterprises can use to track the success of their APIs.
Learn more about how you can use approaches like API-led connectivity to further enhance API reusability.
