While Burgess wrote this post last year, it is worth resurfacing, because it raises many questions that need to asked as enterprises continue to lurch headlong into the API economy. The burgeoning API economy, he suggests, increasingly puts control in the hands of knowledgeable API creators, but pulls things out of reach for many mainstream developers and enterprises. As he put it:
"API-oriented tools today can lure users into situations of artificial complexity they did not expect. Imagine the RESTaurant that makes you do your own cooking and washing up (after you've paid the bill up front). Instead of presenting you with a menu of choices (which corresponds to a declarative way of approaching a restaurant), you pay for a set of strings to remote-control the kitchen in every detail, moving arms and legs to chop vegetables and stir sauces. This might be all fine if you are KickAss (Gordon Ramsay), but what if you merely an ordinary cook, used to buying your food in bags for the microwave?"
So the massive quantities of programmable interfaces being strewn across the internet provide a lot of services, but are also transferring programming burdens to the consuming businesses. "All programmers are assumed to be good enough to solve any issue that might arise, so if we just expose everything and push the responsibility onto them (as end users) then we've made progress," he writes. "If they aren't good enough -- well, then they aren't good enough!"
For enterprises, until recently, many companies relied on packaged software shipped from vendors -- often already pre-configured on server boxes. IBM's legendary AS/400 system (now part of IBM's Power Series) -- was meant to be plopped down and turned on by the business.
Open APIs do provide something that is sorely needed in the IT world, however -- and that is choice. There is an abundance of APIs covering many business and IT functions that can be accessed and used, saving the need to re-invent the wheel. In addition, providing open APIs introduces a value-add for businesses seeking to better serve their customers.
Burgess, however, questions why so many internal workings need to be exposed to the world via open APIs. The logic is, of course, that API-ing applications to the world builds dedicated followings of developers and others, and results in greater innovation. He scoffs at the notion that more innovation will arise out of communities than from closed APIs. "In practice, innovation happens in the same way for open APIs as it does for closed," he says. "You complain to the service provider or author, and they innovate from within on your behalf."
There are many aspects of enterprise IT that should stay in the enterprise. As Burgess puts it:
"We communicate with friends and colleagues, but we don't control their heart rate, cortisol and testosterone levels, nor can we suddenly demand the use of their arms and legs. If we could, there would be interesting contention in the world. There is good reason for autonomy in nature.But this is what SDN, SDDC, Cloud, and any number of other services seems to be proposing."
"Why do we think exposing detailed internals is a good idea?" Burgess asks. "After all, this is the direct transcription of the very micromanagement which we loathe and detest in the human realm." He answers this question by suggesting there is a "gamification" going on across IT, in which the challenge of building and innovating across networks is seen as more exciting than simply supporting contained rules-based systems.
Greater automation is needed, Burgess suggests -- not more do-it-yourself approaches. The proliferation of APIs means more detail work, and less automation, he suggests.