Information Technology and the World

The name of this blog, Information Technology and the World, may seem grandiose. It probably is, but then my plans for it are also grandiose. I want us – you and me – to explore three issues: (1)the impact of information technology on business and society; (2) the impact of society on information technology; and (3) the lessons that each domain can teach the other, including both the possibilities and the limits of what technology and society can accomplish.

Location: Chicago, Illinois, United States

I have worked in construction, petroleum, software and consumer electronics. Professionally, I am a physicist, and engineer, and an IT professional.

Monday, January 22, 2007

Service Oriented Architecture
Is it Ready for Prime Time?

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 E-mail 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 usable and 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 probably 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 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 TV channel. Each cnannel serves a specific individual resort community such as Aspen, Vail, or 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.


Labels: ,


Anonymous Anonymous said...

An interesting article but some points seem to be missing.

1. In the "old days" when man was banging the digits together using COBOL and Fortran, the library routines would be purchased with a manual which would explain in great detail ( ha ha ha ) how to use the routines in question, how they were called and in what order the parameters would be allowed. You had to bind the code into the executable and come up with a single executable. In today's SOA we have such standards as CORBA or .NET that allows the services to be offered without the need to have bind them in and so on. You work with them using another standard called XML and the web.

2. You don't seem to mention software repositories which are the magic bullet for this stuff, assuming that the project management data is included in the repository.

Other than that the article is a good one.

Thursday, January 25, 2007 11:08:00 AM  

Post a Comment

<< Home