7 ms·

Armed with APIs, developers will drive the composable enterprise

34 points by jenlankford 13y ago

AznHisoka 13y ago
Is it just me, or is this article filled with a lot of complicated buzz words and hyperbole? "APIs have eaten software, and they’ll go on the eat enterprise architectures, too." Yes, that API someone did a few months back that allows you to do a GET and POST "F *ck you" 10 different ways will eat software indeed. As will that API that gets a random LOLCat pic.
- AsymetricCom 13y ago
  This is how managers manage.
- ismaelc 13y ago
  FOAAS! (F*ck Off As A Service) https://www.mashape.com/community/foaas https://www.mashape.com/community/foaas
- 6cxs2hd6 13y ago
  > Is it just me, or is this article filled with a lot of complicated buzz words and hyperbole? A helpful site for biz tech writers on a tight deadline is http://bullshitipsum.com/ http://bullshitipsum.com/
coldcode 13y ago
A noble concept. I first read this in the original J2EE documents which imagined a future where you just connected EJB's together to build apps. Didn't work out that well. It's not as easy to build tiny pieces of apps as people thought.
taeric 13y ago
To me, the "web" is currently as successful as it is, not because of the APIs by which you access data, but by the fact that it is a lot of data. Most of it publicly accessible. Some of the markup is "semantic," which is certainly nice, but even that which isn't has a way of being figured out by people.
ismaelc 13y ago
http://mashape.com http://mashape.com
iambateman 13y ago
Damn. Nice. This article is really true, and is terrible news for Microsoft. Many great applications do one thing well. Github --> source control (and issue track, ok whatever). Dropbox --> File storage on devices Sublime --> Code editing MailChimp --> Email Marketing Hopefully, the days of doing everything within one program are over. The "microsoft word can build a website" concept needs to die hard. Developers have always been building on top of people's solved problems, but we are slowly learning to formalize that into a sustainable business agreement via API, which is exceedingly good for the pace of growth. A good application over the next few years might take Twilio, Mailchimp, Dropbox, and Github and add something uniquely special on top.
eranation 13y ago
Or in other words, SOA is back, we just call it now "API". Loosely coupled APIs and services is an old idea, Amazon live by it, even internally. However it is true that most enterprises failed to adopt it. And I agree with the article that companies that write every piece of functionality with API in mind, will have the upper hand in the long run. And those stuck with monolith closed systems will eventually pay a price due to inability to adapt to rapid changes. If calling it API will convince the decision makers to provide budget for internal APIs even though no customer is paying for it directly, then I don't mind. But this is not a new idea. the problem is how to justify ROI for making your code API friendly (doesn't go without saying by the way, there is a price, of backward compatibility, documentation, decoupling etc). For most CEOs this is a waste of time unless there is a direct revenue path from it (e.g. a customer pays for it). It's hard to justify extra effort on the code to management when all you can say is: it will pay off in the long run (imagine the link to the relevant XKCD here)
- sinzone 13y ago
  SOA is not back. It never left. It just much more mature now and easy to implement thanks to RESTful APIs.
  - Daishiman 13y ago
    Agreed. A few years ago SOA = a bunch XML-defined web services with ill-conceived and complex grammars + J2EE "enterprise" stuff and unusual return formats. The maturity of REST has resulted in simpler return types, more mature and easier-to-use serialization libraries, and explicit, English documentation to define interfaces (for the most part). It's a welcome change.
drblast 13y ago
Right on. In the future, all applications are just going to be collections of remotely callable objects, with just a bit of local glue code to tie everything together. This is going to be even bigger than Sun RPC, DCOM, or even CORBA!
0xdeadbeefbabe 13y ago
Armed with marshaled data, developers will drive the composable enterprise. Hey lets bring back ASN1 and call it something hot.
jason_wang 13y ago
As a civilization, we went from "grow what you eat" to "buy what you eat." Today, every member of our society specializes in something and collectively, we cover the overall needs of the society. This transformation took place a long time ago for our civilization and the same transformation is now taking place in technology. My company, TrueVault (https://www.truevault.com https://www.truevault.com) is definitely betting on this trend by specializing in being the data backend for healthcare apps, sites and devices.

34 points by jenlankford 13y ago

Is it just me, or is this article filled with a lot of complicated buzz words and hyperbole? "APIs have eaten software, and they’ll go on the eat enterprise architectures, too." Yes, that API someone did a few months back that allows you to do a GET and POST "F *ck you" 10 different ways will eat software indeed. As will that API that gets a random LOLCat pic.

AsymetricCom 13y ago
This is how managers manage.
ismaelc 13y ago
FOAAS! (F*ck Off As A Service) https://www.mashape.com/community/foaas https://www.mashape.com/community/foaas
6cxs2hd6 13y ago
> Is it just me, or is this article filled with a lot of complicated buzz words and hyperbole? A helpful site for biz tech writers on a tight deadline is http://bullshitipsum.com/ http://bullshitipsum.com/

coldcode 13y ago

A noble concept. I first read this in the original J2EE documents which imagined a future where you just connected EJB's together to build apps. Didn't work out that well. It's not as easy to build tiny pieces of apps as people thought.

taeric 13y ago

To me, the "web" is currently as successful as it is, not because of the APIs by which you access data, but by the fact that it is a lot of data. Most of it publicly accessible. Some of the markup is "semantic," which is certainly nice, but even that which isn't has a way of being figured out by people.

ismaelc 13y ago

http://mashape.com http://mashape.com

iambateman 13y ago

Damn. Nice. This article is really true, and is terrible news for Microsoft. Many great applications do one thing well. Github --> source control (and issue track, ok whatever). Dropbox --> File storage on devices Sublime --> Code editing MailChimp --> Email Marketing Hopefully, the days of doing everything within one program are over. The "microsoft word can build a website" concept needs to die hard. Developers have always been building on top of people's solved problems, but we are slowly learning to formalize that into a sustainable business agreement via API, which is exceedingly good for the pace of growth. A good application over the next few years might take Twilio, Mailchimp, Dropbox, and Github and add something uniquely special on top.

eranation 13y ago

Or in other words, SOA is back, we just call it now "API". Loosely coupled APIs and services is an old idea, Amazon live by it, even internally. However it is true that most enterprises failed to adopt it. And I agree with the article that companies that write every piece of functionality with API in mind, will have the upper hand in the long run. And those stuck with monolith closed systems will eventually pay a price due to inability to adapt to rapid changes. If calling it API will convince the decision makers to provide budget for internal APIs even though no customer is paying for it directly, then I don't mind. But this is not a new idea. the problem is how to justify ROI for making your code API friendly (doesn't go without saying by the way, there is a price, of backward compatibility, documentation, decoupling etc). For most CEOs this is a waste of time unless there is a direct revenue path from it (e.g. a customer pays for it). It's hard to justify extra effort on the code to management when all you can say is: it will pay off in the long run (imagine the link to the relevant XKCD here)

sinzone 13y ago
SOA is not back. It never left. It just much more mature now and easy to implement thanks to RESTful APIs.
- Daishiman 13y ago
  Agreed. A few years ago SOA = a bunch XML-defined web services with ill-conceived and complex grammars + J2EE "enterprise" stuff and unusual return formats. The maturity of REST has resulted in simpler return types, more mature and easier-to-use serialization libraries, and explicit, English documentation to define interfaces (for the most part). It's a welcome change.

drblast 13y ago

Right on. In the future, all applications are just going to be collections of remotely callable objects, with just a bit of local glue code to tie everything together. This is going to be even bigger than Sun RPC, DCOM, or even CORBA!

0xdeadbeefbabe 13y ago

Armed with marshaled data, developers will drive the composable enterprise. Hey lets bring back ASN1 and call it something hot.

jason_wang 13y ago

As a civilization, we went from "grow what you eat" to "buy what you eat." Today, every member of our society specializes in something and collectively, we cover the overall needs of the society. This transformation took place a long time ago for our civilization and the same transformation is now taking place in technology. My company, TrueVault (https://www.truevault.com https://www.truevault.com) is definitely betting on this trend by specializing in being the data backend for healthcare apps, sites and devices.