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)
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.
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)