Is SOA still emerging or do people just not care? SOA seems to have been around for a while, as it was first described by Gartner in 1996. Gartner has claimed that SOA will become mainstream in global companies by 2007.
Yet are we impressed with what we have seen so far? There seems to be plenty of talk about SOA, but it's just working its way into the mainstream. A standard definition for SOA was recently provided by OASIS in their
Is SOA still catching on or does it confound organizations? The business community does not seem to care about SOA, but does the IT community really care? We seem to be stuck in an education, hype and proof-of-concept phase. When do all the big SOA initiatives begin and budgets get allocated? We all know how hard it is to define ROI for IT projects and SOA is no exception. How much are the agility and reuse benefits that SOA provides really worth? SOA has hitched itself to the governance bandwagon as SOX compliance created budgets, but this does not seem to be translating into large SOA initiatives.
The SOA community is certainly active and passionate. We talk to each other with wide-eyed possibilities of loosely-coupled services dancing, or orchestrating, in our heads. We care, but the rest don't seem to. We try to explain to them the power and elegance of SOA and they nod. The SOA conferences are still active, the industry is fraught with conferences with SOA in their name. The name has buzz, no question about it, but then they leave the conferences and go back to their normal business. They have learned a few new acronyms, but no real projects seem to start.
I suppose they feel like I do in an art museum, I know there is something great about what I am looking at, but I am not sure exactly what. Some people really appreciate the art and use fancy terms when talking amongst themselves to describe what they see, terms that mostly elude me. When they describe what they see to me, I see the passion in their presentation and at the moment I can appreciate some of the greatness that they see - and what makes one artist great while another is just average.
But when left to my own perception, the greatness is hard for me to define – it can be a bit overwhelming. So I leave the museum with some appreciation for what I saw and maybe some inspiration, but once I leave I find that I am generally unaffected by the experience as other distractions overtake my life.
And so here we are, the SOA aficionados, we are moved and passionate about something others can appreciate, but ultimately has no real relevance to them. And if the IT community are like adults in an art museum, the business community are the kids. When we talk about SOA with passion and glee to them, their eyes gloss over, their bodies go limp, and they think "I'm bored!" This is a problem because the business community has budgets and can effect change if they cared to.
So what do we do? How do the SOA pilgrims bring SOA to the people and create some converts? How do we make SOA relevant?
Here is an open letter to the SOA community with some suggestions for how each of us can help the SOA cause.
SOA Solution Providers – Make it clear. In a market that has not matured, solution providers often look to grab market and mind-share by defining the market themselves. Until there are a few de facto SOA solutions, the product vendors will thrash to become the dominant provider. This is not a bad thing, except as the solution providers compete, they try to define the market by creating new terms and including differentiating capabilities in their own products.
TIBCO has added support for creating Ajax Web applications with their General Interface platform. LogicBlaze has included the LifeRay portal in its FUSE SOA solution and IBM's SOA Foundation has added a vast array of software from business modeling to identity management to its WebSphere application server. These organizations can't be blamed for competing, but if almost anything can be included in an SOA platform, then the term becomes synonymous with 'Web-technology', watering down and confusing the concept.
From a solution perspective, SOA is about middleware. It is about message queues, orchestration and transformation. It is Web services and the enterprise service bus. This is the realm of SOA solutions, but portals, identity management and application servers – this is a stretch to throw into the SOA basket. Providers should compete to be the best SOA middleware available and clearly differentiate themselves as such, creating a strong message for the provider and a clear offering for the consumer. SOA providers could go a long way by offering the best administrative interface, the easiest installation, the most comprehensive documentation and support and superior quality of service and not worry so much about throwing every type of Web functionality into their platform.
Standards Bodies – Keep it simple. There are too many SOA standards. Like the SOA providers, standard bodies compete to define the most popular and widely-adopted standards. And the organizations that contribute to the standards are inevitably the first to provide a solution that adheres to the standard, providing a competitive advantage.
The result is a standards war that pulls at the fabric of the solution that is trying to become standardized. As a result SOA solutions don't always work together because each may follow a slightly different standard. To help solve this organizations such as the WS-I are formed. The WS-I is an organization charted to promote Web services interoperability across platforms, operating systems and programming languages. WS-I's Basic Profile (wsbasic) is based upon other standards including W3C's WS-Addressing, SOAP Binding and WSDL Binding standards. It is a standard of standards!
The WS-I's intentions are noble, but their existence represents that there are far too many standards and these are just the Web services standards. The problem gets worse when additional SOA technologies such as JBI, JMS, J2EE and the many others are considered. Initiatives such as the Service Component Architecture (SCA) and the Service Data Objects (SDO) try to address this issue by creating a common API to integrate heterogeneous services, but rather than creating new standards that are written to address increasing confusion and complexity, it seems the key is to keep the standards simple in the first place.
REST is the dominant Web service API because it is so simple. It is not as powerful as the more structured Web services protocols, but it solves the majority of integration needs and it is extremely simple, so it is widely used. The Java/J2EE community has learned the lesson of complex standards the hard way, losing ground to the very simple languages such as PHP, Perl, Python and Ruby. The latest incarnation of J2EE, Java EE 5's stated goal is to make development easier by making coding simpler and more straightforward.
SOA seems to be heading down the path of complex and gluttonous standards, let's not do this. Create very simple standards that solve 90% of SOA issues, leaving the other 10% for more complex features and standards that can be created as extensions, but tout the simple standards and allow the users an easy path to SOA adoption.
Universities – Teach Architecture. A new graduate in the computer sciences does not know what architecture is. There is no understanding of enterprise or application architecture. There is not a solid understanding of architectural concepts such as patterns, cohesion, encapsulation, loose-coupling or reuse.
There is little appreciation for the quality of service elements of a system. The difference between components and objects is certainly not well understood and how these might compare to a service is completely foreign. So to this audience, SOA is an abstract concept. It is a product, a set of standards or just a new collection of acronyms.
Without understanding the fundamentals of software architecture, the realization that SOA is just a pattern or evolution of architecture is beyond comprehension. Organizations and individuals are left to their own devices to teach and learn what software architecture is. Too many IT professions do not have the opportunity to learn these fundamentals, so SOA is perceived as a silver bullet that will fail or just a concept that is out of reach.
SOA will be irrelevant given this backdrop because it can not solve the problems it sets out to overcome when so many of its users are unaware of the architectural foundation that it is built upon. Engineers who understand architecture have the opportunity to see value in SOA, those who don't, can't – no matter how many SOA products they evaluate.
Consultants – Make SOA relevant to the business. Consultants have access to an organization's business community. If SOA is to reach its potential, business users have to value it. It is the responsibility of SOA consultants to make SOA relevant to this audience.
Consultants talk business-speak. Don't talk about techie terms like Web services and orchestration, and certainly not SOAP and BPEL. Talk about rapid time-to-market, lowering costs though reuse and the ability to enable business transformation and innovation. Talk about ROI.
Legacy systems cause business rigidity, shackling business users. SOA allows for rapid change and less expensive systems integration. Make business users care about SOA. Make business users aware of their services, the ones they own. Model services graphically, in a way the business community can understand and participate in. Name the services using nomenclature relevant to the business.
A business user will never get as excited about SOA as an engineer might, but at least make the business user aware that the services have real value. Prove to them that SOA can create applications faster and cheaper than any other method. Make them value SOA.
IT Organizations – Move beyond proof-of-concepts. IT departments have done a good job ramping up on SOA and getting initiatives started. However this has mostly taken the form of proof-of-concepts and SOA strategies. The major SOA initiatives have not started in earnest.
Try to move from the proof-of-concepts to SOA production systems. Perhaps stop viewing SOA an enterprise concept and use SOA locally to integrate applications. Use SOA concepts to build individual applications. Don't allow SOA to be solely the realm of the CTO and enterprise architects.
Look to use SOA techniques on a smaller scale, where it is not so overwhelming. This way the proof-of-concept gives way to implementation because the scope is not as grand. This is a great way to introduce SOA to an organization and to demystify the concepts.
There is plenty of talk about SOA, but not enough action. SOA may still be emerging, but SOA still could go the way of data centralization, object-oriented databases and so many other technologies that could not live up to their expectation. SOA is a great advancement in architecture.
Most software engineers know that there is something alluring about SOA, but just what it is may seem elusive. It is the responsibility of the people in the SOA community to help, to make SOA accessible and relevant.
About the author
Adam Michelson has more than a decade of technology implementation experience. Adam is currently the director of service-oriented and enterprise architecture for Optaros Inc., an international consulting and systems integration firm that provides enterprises with best-fit solutions to IT business challenges, maximizing the benefits of open source software.
This was first published in October 2006