In a
recent blog post I questioned whether services oriented architecture (SOA) was driving substantive transformation inside of enterprise IT. My conclusion is that something is not quite right in SOA-ville.
The uptake of general-purpose service enablement is by no means a hockey stick trend line. The adoption patterns some five years into the
SOA evolutionary path do not show a "slam dunk" demand effect. The role, impact and importance of SOA is, in fact, ambiguous ... still. Many see it as merely
an offshoot of EAI, rather than a full-blown paradigm shift.
Meanwhile, some other trends that do demonstrate more of a hockey stick adoption pattern -- social media, Ruby/Phython, RESTful interactions, and RIAs -- are worth a fresh look in the context of SOA. The new kids on the innovation block are experimenting at break-neck speed with
social media,
social networking,
Ruby on Rails,
SaaS,
Python,
REST and the vital mix of
rich Internet application (RIA) approaches.
Something is going on here that shows the compelling attraction of better collaboration and sharing methods, of self-defining social and work teams, of faster and easier applications development, of not moving old systems to the Web but just moving to the Web directly, and the recognition that off-the-wire applications with fine
UIs are the future.
A lot of
these issues surfaced in a
face-off last night between Salesforce.com CEO Marc Benioff and SAP Chairman Hasso Plattner.
So who's on first, SOA or
Web oriented architecture (WOA)? These Web-facing trends for the time being may remain outside the strict boundaries of enterprise IT -- but they are of great interest to developers, ISVs, welling Web 2.0 services start-ups, and
cloud compute purveyors.
These technologies and techniques are also clearly on the radar of forward-looking innovators inside of businesses large and small. Indeed, those non-IT influencers inside of corporations with a keen eye on the all-important Internet growth opportunity are the constituency to win over, and they are not sold on SOA.
If these methods and tools work for a handful of developer entrepreneurs in proverbial garages with credit-card balance-sized investment requirements, then why wouldn't the same solutions be scalable and relevant to the more established business world? Reaching customers quickly with compelling products and services that exploit and leverage the Internet -- this is the same for General Motors, Sprint and Dick-and-Jane
startups alike.
The startups often have advantages -- because, among other things, they don't need a SOA, they don't need to integrate with 15 different back-end systems, they don't need to wield
the political power inside a bureaucracy necessary to get anything done. Success requires the best of start-ups and the best of what large, well-capitalized corporations can do. But the balance may be shifting to the fleet and
Agile side of the equation.
So I'm wondering now whether the window for holistic SOA deployment and value, as it has been classically defined, is being eclipsed. Is it possible that Web interfaces and data disintermediation for legacy applications will be enough? Is it possible that exposing the old applications, and reducing costs of IT support via consolidation and modernization is enough?
In short, is the path of least resistance to business transformation one that necessarily requires a fording of the SOA stream? Or is there a shorter, dry path that goes directly to Web oriented architecture? Is SOA therefore the impediment or empowerment to transformation on the right scale and at Internet time?
Is it better to seek business transformation, or perhaps to seek just enough transformation that creates better services for my employees and customers, ones that rely on the Web as much as possible? And if you don't need to go full-bore SOA on the infrastructure side to enjoy lower cost with better extension of application logic and data value, they why do it? Or why do it first?
And if you can build new applications of code, not components, and the interactions are all loosely coupled from start to finish, and the Web GUIs are what become automated -- rather than the
middleware -- then doesn't that make sense, too?
What seems most important from the legacy IT installations is better access, control and extension of the application-specific data. And we can do that without full-bore SOA. And we can access that data from these WOA applications.
Maybe we don't really need a unifying theory of datacenter assets and resources after all. Maybe we can recognize that particle physics is particle physics and gravity is gravity, to use a matter-of-fact analogy. Why boil the ocean, when you can fry up a few fish and serve them up fast to the highest bidders?
I'll be seeking answers to these questions next week at the
IBM Impact WebSphere conference in Las Vegas. The same questions will no doubt be on a lot of minds, and as well for those evaluating Oracle, BEA, SAP, HP, and Microsoft when it comes to SOA and WOA values.
I'm seeing a lot of good productivity being created from both legacy modernization and new Web development-and-deployment efficiencies -- and they are by no means mutually exclusive. Indeed, data integration advances and Web oriented architecture together may be the real SOA adoption path.
So let's keep an eye on how social media and networks enable workers inside of companies and users outside of companies to relate in ways that help them find what they want and what they need -- and to with quite impressive ease combine and unite as teams -- for fun and productivity. Business process efficiency may come from business-oriented social networks than from business analysts-driven services repositories and governance-enabled policies engines.
And composite applications may come from rapid Ruby development and Agile team practices -- perhaps deployed lickety-split to a public or private cloud -- than from a
BPEL orchestration approach.
Services reuse may not matter as much as the kinds of use that drives constant iterative improvement on Web-facing online widgets and mashups. The real goal is to get work done and to make business and consumer services quickly and dependably available to the online and physical markets. For these real results, is SOA an impediment or empowerment?
SOA's aims have been worthy -- light-weight development, fleet compositing of services and applications, easily customizable processes, flexibly deployment options, reduced total costs, and legacy assets extensions. But there does seem to be more than one way to skin a cat.