A few years ago (perhaps less than ten), the term "SOA" appeared in the tech scene. "Service Oriented Architecture" was discussed, examined, and eventually dropped from the world of tech. (Or at least the Serious Peoples' world of tech.) People derided it with clever sayings like "SOA is DOA".
SOA defined software as a set of services, and a system as a collection of connected services. It was a reasonable approach to system design, but very different from the designs for desktop and web applications. For desktop PC applications it was overkill and for web applications it was nice but not necessary.
The change to SOA design entailed a large effort, one that was not easily justified. The rejection of SOA is quite understandable: there is no payback, no return on investment.
Until we get to mobile/cloud systems.
Mobile/cloud apps, in contrast to desktop and web apps, require SOA. The small UI app on a cell phone or tablet presents the data it receives from services running on servers. There is no other way to build mobile apps. From Twitter to Facebook, from Yahoo Mail to Yelp, mobile apps are designed with SOA.
Building new apps for mobile/cloud with SOA designs was easy to justify. A new app has no legacy code, no existing design, no political turf that people or groups try to protect.
Converting existing applications is much harder. The change from non-SOA to SOA design is significant, and requires a lot of thought. Moreover, it can often require a reorganization of responsibilities, changing the political landscape. Which groups are providing which services? Who is negotiating and measuring the service level agreements (SLAs)? Who is coordinating the consolidation of redundant services?
These reorganizations, if not anticipated, can increase the management effort for the simplest of conversion projects. (Even anticipated reorganizations can increase the management effort.)
Changing the organization is not a technology problem. Moving from non-SOA (desktop PC apps) to SOA (mobile/cloud apps) is in part a technology problem and in part a management problem. You need to address both sides for a successful project.
Showing posts with label SOA. Show all posts
Showing posts with label SOA. Show all posts
Wednesday, March 20, 2013
Tuesday, October 11, 2011
SOA is not DOA
SOA (service oriented architecture) is not dead. It is alive and well.
Mobile apps use it. iPhone apps that get data from a server (e-mail or Twitter, for example) use web services -- a service oriented architecture.
SOA was the big thing back in 2006. So why do we not hear about it today?
I suspect it had nothing to do with SOA's marketability.
I suspect that no one talks about SOA because no one makes money from it.
Object oriented programming was an opportunity to make money. Programmers had to learn new techniques and new languages; tool vendors had to provide new compilers, debuggers, and IDEs.
Java was a new programming language. Programmers had to learn it. Vendors provided new compilers and IDEs.
UML was big, for a while. Vendors provided tools; architects, programmers, and analysts learned it.
The "retraining load" for SOA is smaller, limited mostly to the architects of systems. (And there are far fewer architects than programmers or analysts.) SOA has no direct affect on programmers.
With no large-scale training programs for SOA (and no large-scale training budgets for SOA), vendors had no incentive to advertise it. They were better off hawking new versions of compilers.
Thus, SOA quietly faded into the background.
But it's not dead.
Mobile apps use SOA to get work done. iPhones and Android phones talk to servers, using web services. This design is SOA. We may not call it that, but that's what it is.
When the hype of SOA vanished, lots of companies dropped interest in SOA. Now, to move their applications to the mobile world, they will have to learn SOA.
So don't count SOA among the dead.
On the other hand, don't count on it for your profits. You need it, but it is infrastructure, like electricity and running water. I know of few companies that count on those utilities as a competitive advantage.
Mobile apps use it. iPhone apps that get data from a server (e-mail or Twitter, for example) use web services -- a service oriented architecture.
SOA was the big thing back in 2006. So why do we not hear about it today?
I suspect it had nothing to do with SOA's marketability.
I suspect that no one talks about SOA because no one makes money from it.
Object oriented programming was an opportunity to make money. Programmers had to learn new techniques and new languages; tool vendors had to provide new compilers, debuggers, and IDEs.
Java was a new programming language. Programmers had to learn it. Vendors provided new compilers and IDEs.
UML was big, for a while. Vendors provided tools; architects, programmers, and analysts learned it.
The "retraining load" for SOA is smaller, limited mostly to the architects of systems. (And there are far fewer architects than programmers or analysts.) SOA has no direct affect on programmers.
With no large-scale training programs for SOA (and no large-scale training budgets for SOA), vendors had no incentive to advertise it. They were better off hawking new versions of compilers.
Thus, SOA quietly faded into the background.
But it's not dead.
Mobile apps use SOA to get work done. iPhones and Android phones talk to servers, using web services. This design is SOA. We may not call it that, but that's what it is.
When the hype of SOA vanished, lots of companies dropped interest in SOA. Now, to move their applications to the mobile world, they will have to learn SOA.
So don't count SOA among the dead.
On the other hand, don't count on it for your profits. You need it, but it is infrastructure, like electricity and running water. I know of few companies that count on those utilities as a competitive advantage.
Subscribe to:
Posts (Atom)