"Reusability" has been a mantra for the sale of as much unsatisfactory software as the claim for "improved productivity." It's a benefit buyers hope you get, while knowing in their heart it's not going to happen. To say that reusability has been a quest for four decades is to somewhat understate how long and tortured the search has been.
- Top Six Things to Consider with an Identity as a Service Solution
- The People Problem: Cyber Threats Aren't Just a Technology Challenge
- IT and LOB Win When Your Business Adopts Flexible Social Cloud Collaboration Tools
- Big Data and Customer Interaction Analytics: How To Create An Innovative Customer Experience
From the time that structured programming leveraged the benefits of subroutines and libraries of routines, there has been a compelling impetus to create reusable code. Initially, this desire was expressed purely in the form of libraries. The concepts now familiar to API designers were little appreciated then, and so libraries were often hideously complex, hard to use, and brittle.
Even if they were implemented with discipline, libraries presented syntactical problems. One of the biggest was name collisions, which was an enormous issue in C and early versions of C++. In the latter language, you sometimes had to check the exact form of name mangling that the cross-compiler (to C) employed so you could figure out how avoid having your function names collide with libraries or, in the other direction, to figure out how to call those library functions.
Even if you could get past the syntactic issues, you were by no means in the clear. Many libraries made it impossible to use more than one library at a time. Use more than one graphics package? No way. Once one library clamped on to the main UI thread, no other one had a shot at access. You might wonder why you'd ever want two graphics libraries in the same app. But such a question shows how far we've come with omnibus solutions like Qt and Glib. In the times I'm talking about, libraries were much smaller in scope and you often had to call on several of them to complete a single, simple task.
Even if you could lay those problems to rest, the obstacle of platforms presented itself. To solve this, there came components and competing component formats (OLE vs. COM vs. DCOM, etc.) While several technologies such as RMI and CORBA emerged to address remote component utilization, they were never popular and always cumbersome. Which brings us to where we've been for the last few years: Well-written components are reusable only on the platforms they were designed for. That state of affairs, however, was not good enough for mobile apps, which are inherently tied to a highly splintered group of platforms (Android, iOS, Windows Phone, BlackBerry QNX, etc.)
Mobile apps and Web apps have driven key changes in reusability by forgoing components in the traditional sense in favor of consuming services that were publicly exposed in the cloud as APIs. Components moved from the troublesome local machines to a remote server, where they could be invoked through Web services without concern for the execution platform. This new composability is the first truly reusable code experience we've had in decades. Suddenly, you can call functions in one API to handle one area of functionality, call others to handle a separate task, and go to a third API to deliver the data you need for another requirement. For new applications, the design issue that is slowly emerging is how to compose software from the available APIs.
On the surface, this might seem like the Web services that were briefly the rage a decade ago. While there is some conceptual affinity, the implementations are substantially different. The old Web services were cumbersome to code (with WSDL and SOAP) and slow to execute. They also tended to interact with private, local servers. While they held a lot of promise, their limitations made them generally unappealing, and so their use tended to be for very coarse-grained requests. Today, the APIs are fast, they use REST, and are fine-grained. A single application might invoke dozens of API calls and deliver value to the user in near real-time.
The speed of adoption is great and there are now companies such as Apigee, Mashery, and Layer 7 that help other companies design and manage APIs for a wide variety of vendors. How active is this sector? Well, this week alone, Mashery was acquired by Intel and Layer 7 was snapped up by CA (the former Computer Associates).
Less attention has been paid to the developer as consumer of APIs. However, startup company Temboo has created elegant tools that make API consumption almost trivially easy. I expect they'll have competition soon.
While I expect this new model of reusability to flourish, it does have one conspicuous limitation: Most companies do not provide their API services free. The former model of buying a component and then distributing it without royalties will fade away in this new model, as each call now includes costs for the provider. I expect this will have important consequences that are still somewhat difficult to divine. I'll get to those in a future editorial.