Optimal Use and Reuse
Every large enterprise periodically accumulates what we call "tech debt". It happens even in very well-run companies, those that have built-in processes designed to adapt quickly to capitalize on emerging opportunities, or cope with unexpected problems. In essence, to respond rapidly to these and other market shifts, they have to implement new technologies. Then, with the next shift, they have to do it all over again, basically starting from scratch each time.
There’s only one way to stop going further into this kind of tech debt, and that’s to stop digging. And the best way to do that while still having the flexibility to respond to market needs in a timely fashion or even faster than ever is to implement a good API strategy.
One key factor in this equation is what’s broadly referred to consumerization. This is the need to ensure compatibility between the enterprise infrastructure and an ever growing number of mobile devices, social business platforms and of course apps. It gets even more complex when the changes are being driven from the inside, by a new generation of developers who create apps specifically designed to cater to individual priorities, specific tasks and personal styles. Now multiply those factors with the characteristics of a large enterprise of disparate business units with varying priorities, heterogeneous systems, remote workforce, etc. Even within a well-run enterprise, ensuring the optimal sharing of data and other resources can be very difficult.
If that’s how it begins, it often ends with the headaches associated with point-to-point integration. Somebody has to tie all those strands together, and that takes time, money and a lot of effort. This is in stark contrast to the need for speedy time to market, enhanced efficiency, lower costs.
But that’s not even the worst of it. For a variety of reasons, many integration projects don’t allow for reusability. This means that after all the work that goes into each integration effort, it can’t be recycled. Every project essentially has to start from scratch.
It doesn’t have to be this way. A common API infrastructure can ensure that the same data and services are exposed to every internal (and, when business requires it, external) constituency in exactly the same way.
For example, Comcast is noted for its efficiency, but it also has multiple business units and market priorities. It’s also heavily in the business of digital consumer technology, which requires lightning-fast responses to business forces. So, like many other enterprises, it used to add new technologies as required, while having to play catch-up through painful integration processes.
Comcast turned to Mashery to create an in-house API platform, and the difference is nothing short of dramatic. The pains associated with sharing resources have just about disappeared. Far-flung units with very different business interests no longer have to work with different codes and protocols—the RESTful APIs in place now enable developers to access any service or content through a basic URL.
Perhaps best of all, any code built to suit a specific purpose can now be re-purposed to serve other needs. That’s because each API service comes fully furnished with on-demand dynamic scalability, access controls, rate limits and so on.
That’s the story of the technology, but the true business benefit is that any unit within Comcast can expose data and services to any other unit in half an hour. In some cases, it used to take months.
Essentially, this strategy achieves the often elusive goal of ensuring uniformity at the back end while offering full personalization at the front end, with new apps offering individualized services across multiple platforms. All accomplished with minimum effort and maximum reuse, with no need for more tech debt. For every enterprise, that’s a worthy feat.