WSJ Management

Rather than taking a myopic Web services management approach to realizing the promise of shared services, enterprise architects should focus on building the architecture that controls chaos and enables sharing and reuse.

Web services, with their standards-based ability to exchange data between disparate, distributed systems, hold great promise for enterprises seeking the holy grail of enterprise computing: a fully integrated infrastructure that inexpensively adapts to business needs at enterprise speed and scale. However, for their full value to be realized, enterprise architects need to view Web services strategically or they will find themselves in a muddle of integration spaghetti.

Web services management (WSM) at first seems to provide an adequate solution for global Web services adoption, but has ended up facilitating a myopic, ad-hoc, project-based approach that encourages a focus on near-term projects instead of on long-term, strategic benefits. You cannot accomplish global interoperability and sharing if you approach it one distinct project at a time. Why? Because you cannot control the chaos inherent in purely project-driven Web services adoption. This only adds diversity and complexity to IT - creating a complex tangle of rigid point-to-point connections, numerous departmental archipelagos, and multiple policy silos - fostering enterprise incompatibility, which runs counter to the notion of SOA.

Look at some of the results of current WSM approaches on software infrastructure:

• Policies, policies everywhere. WSM tools place a policy definition tool on every developer or project manager desktop, which forces policy decisions on each individual short-term project. This places the burden of infrastructure design on disparate project teams as opposed to on central operations staff. For instance, with a project-led WSM approach simple policies for access control, logging, or routing can be different from implementation to implementation. Over the long term, this approach creates multiple policy silos, leading ultimately to a need to integrate the policy implementations themselves.
• Agent-based approaches add unnecessary complexity. WSM tools require users to deploy agent or proxy applications onto already-taxed application servers and EAI platforms. Being forced to add an agent or to proxy an application makes participation in the service network more difficult, raising the bar for broad-scale adoption. This approach encourages a myopic focus on the application as opposed to the service network.
• Limited scope = limited scalability. WSM solutions were built to solve relatively small problems residing in a business unit or department, and are not designed to scale across a global enterprise. Trying to scale WSM solutions across the enterprise leads to challenges, especially in unifying policy enforcement for security, routing, message transformations, etc.

With a properly constructed infrastructure, a planned service-oriented architecture (SOA) can succeed where ad-hoc WSM fails. In contrast to WSM products, there are solutions designed to create service-oriented infrastructures that feature:

• Centralized policy definition, distributed policy enforcement. This federated approach enables service-oriented architectures to appropriately balance two seemingly contradictory needs: the need for central coordination to avoid chaos, and the need to be distributed to maximize flexibility and scalability.
• Distributed networking approach. An SOA is fundamentally a distributed network. The inherent challenges - enabling reliable, consistent, and predictable communication between services deployed across a distributed global enterprise - are distributed networking challenges. Remember it was the IP router (not the server, bus or agent) that acted as the key piece of infrastructure enabling the rapid growth of the first generation of Web computing.
• Scale globally. This class of SOAs can handle millions of messages each day out across thousands of applications and shared services. They interconnect networks of services, from across the enterprise and around the world, all directed centrally and governed locally.

Ultimately, the goal should be an SOA infrastructure that is standards-based; enables sharing; offers loose coupling of applications; and federates control over services, applications, and processes that are, in turn, universal, reusable, flexible, and distributed. In this context, Web services management becomes a set of valuable applications and operational capabilities that leverage that shared infrastructure.

Putting it simply, enterprise architects have global challenges that require global solutions, and thus require a stable, reliable, and scalable infrastructure. If they are to make their architecture more connected to business needs, they will have to move beyond ad-hoc solutions and build a broad, enterprise-wide, coordinated SOA so existing systems can live on, interoperating seamlessly with new services that are brought on line and integrated into the SOA quickly. Ultimately it is the architecture that matters.