It's Time to Actively Manage Your SOA

If you were the CIO or chief architect at a company and I told you that you are already running multiple Web services, how would you react? Pleasantly surprised? Shocked? Would you be upset?

Many firms today are just now considering whether to begin exploring Web services. They, like many others, are early in their planning for Web services, and yet in some cases they are farther down the road than they realized.

That's because many of their current software vendors have begun building Web services into their products, and these products are being installed in IT architectures without explicit knowledge and understanding of the implications by IT management. On top of this, many developers have been quietly experimenting with Web services under the radar, which means there may be many Web services already running in your business.

The good news is that these firms are adopting Web services and service-oriented architectures (SOA). The bad news is that their SOA is being defined by the software vendors through their software products as opposed to being based on a business perspective that assures that business objectives are supported with the SOA and Web services strategy.

Furthermore, they may have a proliferation of Web services running without any IT oversight or management, which can lead to an ad hoc SOA with poor interoperability and low services reuse potential. I call this "passive SOA management."

While many firms are very early in their adoption of Web services and SOA, I strongly advocate that these firms quickly develop a SOA strategy and governance model that helps them actively manage their SOA migration to support the corporation's business goals, on their terms, and independent of the vendor community. This approach will help ensure the appropriate business fit and maximum degrees of freedom to implement SOA to support the company's business and financial goals as well as IT strategy.

Today, the central issue is not whether to begin implementing SOA, but when to begin actively managing for SOA. While firms can watch the development of the Web services standards and SOAs from afar, the reality is that the firm already has some Web services operating somewhere in the organization, and the incumbent software vendors are already shipping Web services capabilities in their enterprise software applications. In other words, it's time to begin actively planning to operate and manage an SOA strategy on your terms, not on your vendors' terms.

Consider the following scenario. Company A is a financial services firm with a heterogeneous IT architecture characterized by a mixture of J2EE and Microsoft .Net technologies. It has J2EE application servers to support many of its enterprise applications and e-commerce initiatives. In addition, due to the mixture of legacy applications and stovepiped functionality in various business units, this firm has been deploying a popular enterprise application integration (EAI) platform. You can see that several classes of enterprise software applications would have been purchased in order to implement these architectural choices based on business needs.

However, depending on the vendors and their technology applications, they may support Web services and SOA to varying degrees based on how they align with the standards bodies, other vendors and architectural choices, as well as how they implement specific Web services standards in their products. Most J2EE application servers provide basic support for XML, Simple Object Access Protocol (SOAP), and Web Services Description Language-based services description. Most J2EE development environments, or integrated development environments (IDE), allow development of Web services within their environments to be deployed on the application server.

Consider the EAI strategy for Company A. Most EAI products today are rapidly adding Web services support into their offerings through acquisitions as well as through new features and functions. So, whether intended or not, the EAI strategy will implement a Web services stack that is integration-centric. Will the EAI SOAP stack be compatible with the application server SOAP stack? Will they implement SOAP messaging in a compatible fashion, e.g., document messaging vs. remote procedure call-style messaging? Do both software platforms support the WS-I Basic Profile? Do they implement the standards consistently to ensure interoperability?

And on the .Net side of their architecture, where much of the Web services support is built into the Microsoft applications, how will the various tools converge into a unified enterprise SOA based on a common SOA strategy, governance model and standards template?

The answer is that they won't unless CIOs begin to actively plan and manage their SOA now, ahead of and independent of their incumbent software vendors, and in time to achieve visibility of the services that may already be running within their enterprises.

This is not an attack on the software and platform vendors. The message here is that firms must have an SOA strategy that explicitly maps to business objectives, supports the IT strategy and goals, and can be implemented to drive real business initiatives today. Once that has been accomplished, a CIO can begin determining how current software vendors fit into their SOA, as well as how potential new vendors may fit into the SOA.

An SOA and Web services strategy must be developed based on the firm's business and IT goals, then mapped to the firm's current IT and application architecture. Then, based on how the incumbent vendors support the firm's SOA, they may or may not be part of the SOA for the long term.

Those are choices that must be made with the big picture of SOA and Web services in mind. And naturally, while most software firms will support Web services soon if they don't already, the question is, How well will they support your firm's SOA and Web services strategy as a unifying architecture for all of your technologies and applications based on clear and explicit support for the business?

Consider the following types of software offerings you may have in your IT architecture. Do a quick analysis from the vendors' Web sites on if and how they support Web services and SOA, or when they will support them.

  • Microsoft .Net framework
  • J2EE architecture
  • Application servers
  • Web servers
  • EAI
  • ERP architectures
  • CRM software
  • Messaging backbone
  • Systems management tools
  • IDE/development tools
  • Identity management/security software
  • Asset reuse software

You'll find a lot of information quickly from this quick assessment, but what you won't find is how SOA and Web services will support your business goals and IT objectives. That's why your SOA strategy must be developed independent of your vendor partners initially, and then you should open it up for discussion with your core partners to begin building your SOA.

IT executives must begin actively managing their SOA and Web services strategies now, based on their business goals and objectives and independent of their vendor partners. This will lead to the best overall SOA solution for your business.

EDITOR'S NOTE:

This is the first of a series of columns by Eric Marks concerning Web services and service-oriented architecture.

Future topics he will explore include:

  • The Business of SOA: Business-Oriented Architecture?
  • Implementing a SOA with Web Services
  • Building Blocks of SOA: Asset Re-Use, Web Services, BPM and Grid Computing
  • Active SOA Management: Policy & Governance, Operations and SOA/Web Services Visibility
  • SOA Roadmap: The Multiple Pathways to SOA
  • Cost-Justifying SOA to your Boss
  • SOA Strategy: Operationalizing Corporate Agility and Flexible IT Architectures

Copyright © 2004 IDG Communications, Inc.

  
Shop Tech Products at Amazon