When I tell customers that my company does Web services management, the question I often hear is "so what do you mean by Web services management?" It's no wonder there's so much confusion on this issue, because the term "management" has been used to mean many different things. For example, there's business process management (actively coordinating the runtime execution of business processes) and systems management (passively monitoring performance and availability of IT infrastructure). These are two very different meanings for the word "management," and two very different markets.

The question of management in the context of "Web services management" has gained a lot of visibility as the big vendors each try to claim ownership of the space. Hewlett-Packard's OpenView division acquired Talking Blocks. Computer Associates acquired Adjoin. BEA Systems announced that its future WebLogic 9.0 release would focus on management. Are application platforms like BEA WebLogic and systems management tools like HP OpenView in the same market? Hardly, but both camps are trying to stake a claim in the space. Further confusing the issue is that most pure-play Web services management solutions do a bit of both.

Who's right? Does Web services management belong in the domain of the application platforms, does it belong in the domain of the system management platforms, or is it truly a new market? Industry pundits state with absolute certainty that they know the answer. Unfortunately, they don't all come up with the same answer! As you would expect, it's not as clear-cut as any one industry pundit might have you believe.

In a world where the way people design, build, and deploy applications remains status quo, there is a clear separation between the roles of application servers and systems management tools: application platforms run the applications, and systems management tools make sure the applications are running well. Application platforms are used by developers, systems management tools are used by operators - and the two camps rarely cross paths. In a status quo world, what then happens to pure-play Web services management vendors? In this world, consolidation is inevitable.

The open question is whether the status quo will remain, or whether enterprise IT is on the cusp of a fundamental change. Frankly, Web services alone are not going to be the cause of a fundamental change. Web services can be deployed in traditional multitier or client/server applications instead of traditional proprietary technologies, and result in improvements in cost and time-to-market, but this is just evolutionary use of a new technology. It's not revolutionary.

The fundamental change that's coming in enterprise IT is the move to service-oriented architectures, which in theory allow IT organizations to avoid unnecessary duplication by sharing software services, like order processing, across projects and teams.

Web services are the vehicle to make service-oriented architectures available to the majority of IT organizations. Through reuse and consolidation of redundant services, a properly implemented service-oriented architecture results in significant improvements in both IT cost and flexibility. This reuse and consolidation changes the rules of the game in one important way: it means that a software project is no longer self-contained - one IT project depends on others, which are maintained on different schedules by different organizations.

These cross-project dependencies result in new requirements that previously did not exist. Maintaining performance and availability of the overall service network not only requires central visibility into the operation of all of the services, regardless of what platform they are built on, but also active in-network manipulation of the routing, quality of service, and in some cases, content of messages sent across projects.

Heterogeneous central visibility is something foreign to application platforms but typical of systems management products. On the other hand, active in-network control is something foreign to systems management products but typical of application platforms. To coordinate in-network control across heterogeneous projects requires a careful blend of functionality drawn from both systems management and application platforms - this is the sweet spot for Web services management.

This blending of functionality is what is driving application platform vendors as well as systems management vendors to think that they "own" Web services management - even though, for the most part, the vendors are not building Web services management. As with anyone coming from a certain area of experience, their belief is that the problem entirely fits within their domain. To a hammer every problem is a nail. Systems management vendors are building in passive monitoring of Web services and application platform vendors are building in functionality such as routing of Web services - and both think that this gives them a complete solution for Web services management.

As the big vendors become more aware that Web services management is both a critical capability for maintaining a service-oriented architecture and that critical components of it are outside their experience base, they will scramble to bring the technology in-house, since only the largest vendors have significant expertise in both areas (though usually in product teams that rarely talk).

Regardless of whether a fundamental change is on the way for enterprise IT, the second- and third-tier Web services management players are likely to be shaken out of the market or acquired. The opportunity for the first-tier vendors, however, is to reach escape velocity and become successful independent vendors - demonstrating that Web services management isn't "owned" by any traditional market segment.