Sean Rhody (pictured), editor-in-chief of SOA Web Services Journal, writes: I have a friend who's very into automobiles. He gets a new car every year or two - not expensive ones, but ones that can be used in stock racing (I know I'm getting the term wrong somehow) and time trials. He likes to drive and tries to get the most out of his vehicles. Recently, I went for a ride in his latest purchase. I'm used to his having computers and more gauges than the space shuttle, but somehow this one was a bit different, almost as if it were intended to get the most information to the driver. It even had a way to measure the tire pressure, from inside the car, while moving.

My friend believes firmly in managing his driving experience. One thing that struck me about it - it sure helps when the ability to manage is designed in from the beginning. I thought about what it would take to put that level of information in my Expedition. It would not be feasible.

Web Services Management is very similar to my friend with the car - very useful, and better built in up front. And yet management is often the last thing on someone's agenda - it's next year's to do, if the budget doesn't drop out.

That's a problem for a number of reasons. We've finally gotten to the point where we can talk about services and SOA and start to peel back the covers of the silos and let the true value of the application - its services - show through. SOA enables productivity in a number of ways, including reuse of services, and freedom from having to write the same security, management, data access, and other common code routines that can now be abstracted to a declarative paradigm.

It's understandable that management is not the first thing on the list when starting with Web services - it's a fairly significant paradigm shift to begin with, and everyone is caught up with how to determine the granularity of services, how to protect them, and even how to put a user interface together now that we no longer build applications. These are all challenges that need to be overcome.

However somewhere along the line we need to understand that management of services - where they are, what they are doing, who can access them, how they are performing - is as vital to an enterprise as the ability to invoke a service. Architects and developers sometimes ignore operations, but without it, the corporation grinds to a halt. Operating an SOA requires management. It becomes even more vital when services are shared across organizations that previously built their own. Quality of Service becomes vital, as all it takes is a couple of seconds of delay from an overloaded service to convince a division that the new platform is "buggy" and their old silo applications are really what they need.

I suppose building an SOA is a lot like the evolution of the automobile. At first cars were really "horseless carriages." They were simple devices, comparatively speaking. Then they evolved things, like windshields, automatic transmissions, brakes, shock absorbers, and license plates, and became cars. Then we added air bags, GPS, DVD players, and surround sound stereos. And we needed to be able to monitor all of the increasingly complex functions of a car, so we put in computers, and built a command center so we could monitor the tire air pressure.

Implementation of an SOA is similar to that progression. You start with basic Web services then add transactions and security. But you still need management; otherwise you're racing a model T at the Indy 500. Now where did I put my crash helmet?