| The short answer to the question in the title of this piece is, “Yes and no; it depends on what you mean by prime time.”
When I first heard the buzzword Service Oriented Architecture (SOA), it sounded like a pretty good idea. After all, we in IT have been talking obsessively for years about better service for our users, while not doing a very good job of providing it. Developing an architecture (a blueprint) for providing good service to users seemed like a natural next step. So I decided to look into it.
As the hype began to build I found myself asking the same questions over and over again without getting any clear answers. “What is SOA?” “Who is getting the service, the end user or another computer program?” It was déjà vu, back to the beginnings of client/server architecture, trying to find out exactly what a client is and what a server is. We now have a pretty good idea about these things and how they interact. But it was a struggle to reach this point.
Initially I naively assumed that the services in question were oriented toward the end users. It took me several months and a couple of dozen interviews to learn that the services in question were oriented toward IT applications. In a service oriented architecture, when a program – typically an application – requests a service, say a customer name and address, it requests this service from an independent program that provides this service not only to the application in question but also to other applications requiring the same kind of information. SOA has no direct contact with a user. Rather, its goal is to enable and expedite the work of application programs.
Recently a client (a human, not a workstation) asked me attend a conference on SOA and give him my opinion of its maturity and suitability for major rollout. I attended an IDC conference and then did some further research. Here is a summary of what I learned. (Incidentally, the presentations are on IDC’s web site. Go to www.idc.com
. E-mail email@example.com
to get a password. The event name is IDC Service-Oriented Architecture Forum Midwest.)
The core idea of SOA is to design applications around the use of various services, each dedicated to a specific task and each reusable by multiple applications.
The goals of SOA as recited by several authors and speakers are the same as the goals we have been hearing about for many other architectures and technologies: lower costs of new applications; quicker deployment of new systems; quicker and less expensive updates; lower total costs of ownership. All of these can be achieved by having widely useful reusable services.
If you have been around IT for a while, this sounds familiar to you. We have been talking about reusable code for decades. COBOL has stored procedures; FORTRAN has callable subroutines. object-oriented programming (OOP) has – what else – objects. In every case, the purpose was to save money and deployment time by having pre-coded subprograms that already had been used in other applications and could be used in still other applications in the future.
We had a little success with reuse in COBOL, and a modest amount in FORTRAN. There were a few successes in OOP. The most promising user was a large financial services company which was so pleased with its use of OOP that it spun off a company to go into the business of selling the objects it had created. This company was not a resounding success.
Note that in every case cited above, the code in question was in fact reusable. It simply wasn’t reused very much. Why? The promise was there. The engineering was done. The potential benefits were large. Before we jump into SOA with both feet, we should figure out why previous attempts to reach the goal of reuse failed.
One difference between the world of SOA and the prior world of reusable code is the presence of the Internet as a host for services. It is in many ways the ideal host. It uses industry standard interfaces; it transfers the work and responsibility for operation and maintenance of the service from the user to an independent vendor. And its use prevents the application programmers and architects from meddling with the service in a vain attempt to customize it for a specific use.
The current level of discourse about SOA in the trade press and on the seminar circuit suggests that SOA is far from a mature technology. One article lists the Five Things You Must Do to succeed with SOA. Another lists the Seven Keys to SOA Success, Unfortunately, some of the Five contradict some of the Seven. One suggests that the beginnings of SOA be small and low key; another says that SOA must be a long term enterprise-wide activity,
There is some consensus that a successful SOA program will require changes in the IT organization, changes in IT governance including SOA steering committees and SOA standards committees, enhanced cooperation across business units (to assure that the services developed are in fact reusable and reused), and increased understanding of business needs by the IT community. None of this is new, and none of it is unique to SOA. Look at any of the surveys of CIO concerns over the last couple of decades and you will find the same issues. We haven’t resolved them before. Why should we think that the new perspective of SOA will enable us to resolve them now?
The hype surrounding SOA has called forth the usual identity theft associated with new software; other things are renamed SOA to ride the marketing wave. Be sure you are getting the real thing. Lack of common definitions at all levels, including the definition of “ service” itself causes confusion and mistakes.
As of now, all of the tools are not in place. Any real world application of SOA will require some custom code. There will be legacy systems which cannot be effectively served by SOA. Further, you will need a new set of tools to manage both the services and the applications that rely on them.
Finally, there remain significant design issues that are unlikely to be resolved in any definitive way. One is the question of granularity. How much detail should, say, a name-and-address service provide? Zip code (5 digit or 9)? E-mail address? Identification of spouse and children? Making these decisions is an art, not a science, and is likely to remain so.
Please do not interpret my comments above as a condemnation of SOA. Quite the contrary. I think it is a positive development, particularly the use of Web based services. The attention SOA is getting is reemphasizing the importance of the perennial IT issues of better understanding of the business by IT, better communications between IT and the business, and better governance of IT activities shared between IT and business executives.
SOA is mostly old wine in new bottles, but this is not bad. It is offering us another chance to get at core IT issues that have bedeviled us for years. And, finally, the re-use idea may actually work. If it does, it will constitute a major advance in the way we do things, and provide us with systems that are less expensive, more agile, and more focused on business needs.
Is SOA ready for prime time? I recently read about a new kind of cable channel. It serves a small number of resort communities such as Aspen, Vail, and Stowe. These channels are focused on visitors rather than residents. They report snow conditions, weather, and information about local events. Prime time for this small, select audience is not 7 PM to 10 PM as it is for network television; it is 8AM to 9 AM and 5 PM to 7 PM.
The answer to our topic question is this: SOA is ready for prime time for a small and select group of organizations: those that can bear the risks and live within the constraints noted above, those that have advanced technical skills available for this work, and those willing to make the changes in business processes (IT and other) that a successful SOA implementation requires.
SOA is too unstable and too iffy at this point in its history to be a wise choice for an organization-wide architecture of a large company. But it may be a good choice as a target architecture “to be” in five to ten years.
I have left until last the most important question about SOA. Will your designers and implementers actually use the reusable services designed and built for other applications? The passive aggressive opposition by IT professionals to reusable code is what doomed most previous efforts. Can your organization overcome this mind set?
I am reminded of the old riddle about statisticians. Why do statisticians distrust all data? They divide data into two classes: data collected by others and data they themselves have collected. They distrust data collected by others because they do not know how it was collected; they distrust data collected by themselves because the know exactly how it was collected.
Make you own translation to the world of system designers and programmers.