X
Business

Web services: Look before you leap

Today's "snooze, you lose" climate has companies embarking on Web services and integration projects without having a firm grip on what they already have in place and where they plan to go. That's a big mistake.
Written by Brent Carlson, Contributor
COMMENTARY--The prevailing wisdom holds that enterprises currently working on Web services will be in an excellent position to realize benefits such as cost savings, productivity enhancements and new business processes.

On the other hand, those not working on Web services are warned they¡¦ll be at a huge competitive disadvantage. This kind of "snooze, you lose" climate has companies embarking on Web services and integration projects without having a firm grip on what they already have in place and where they plan to go. That's a big mistake.

Today's typical large business already has thousands of software development assets (SDAs), including applications, components, documentation, frameworks, and patterns, strewn throughout the enterprise. Cutting through this massive spaghetti-works of assets is a daunting but necessary first-step. While component catalogs have traditionally provided a convenient repository for listing software assets, the effectiveness of such basic repositories has proven to be limited. When Web services development, with its need to quickly extract, consolidate, and expose business capabilities from disparate legacy systems is brought into the picture, the inadequacies of these simple store-and-retrieve products become even clearer.

To truly take advantage of the promise of Web services, companies must have the ability to map their assets to the enterprise's strategic business processes. Knowing what assets exist and where they are located is only part of the equation. Understanding how each asset fits into the corporate business landscape (in other words, a model-based approach) is the key to efficient development.

Without such a blueprint, budding Web services projects are doomed to produce more poorly thought-out software that is just as unmaintainable as what already exists in the organization, only running on a yet another technical infrastructure. As the analyst firm ZapThink, LLC recently put it; "just because a new technology has promise doesn't guarantee that it will be applied correctly."

In addition to improving development efforts, a model-based approach that includes mapping of those models to existing SDAs dramatically accelerates the identification, consolidation and ongoing management of the software building blocks used for Web services. A codified picture of existing SDAs provides the business context necessary to optimize these assets throughout the enterprise. Absent this capability, businesses waste resources rewriting software they already have, spending more money and time than necessary, or they overlook aspects of their existing systems ripe for consolidation, leaving the infrastructure mess in essentially the same condition as when they started. Ultimately, such failures are likely to result in enterprises delaying or dropping their Web services initiatives altogether, with Web services¡¦ true opportunity for simplifying software integration lost in the bargain.

A model-based approach to handling SDAs gives enterprises an efficient way to manage the entire lifecycle of vital software assets as they are continually called upon under new Web services initiatives. This model-based approach should be executed as a four-step process.

Assess what you have and create a business roadmap for migrating to Web services. The gradual accumulation of thousands of assets over the years has created a very messy IT closet. Who knows what¡¦s in there these days? And, who has the time and interest to straighten the mess out? Properly assessing your inventory, however, is worth the effort--it'll give you the ability to develop many applications in the future. As you start this work, however, remember the 80/20 rule; some SDAs are "more equal than others" and are obvious candidates for your initial inventorying efforts, while other marginal assets are best left alone in the far back corners of your IT closet.

Build a catalog of essential software development assets (SDAs) mapped to your business roadmap (i.e., your business architectures and models). This is like a dictionary that goes beyond merely listing words and provides the context in which they are used in a company's unique dialect. The ability to see what aspects of your business architecture are already supported, to identify redundancies, and to see where gaps exist will enable you to build Web services that present the right level of information and interact with the right underlying business systems.

Locate the most appropriate software assets for your high-priority services using the catalog you have built. Application developers, business analysts and architects need the ability to quickly identify those assets that best match business and technical requirements for new application development and integration. This includes legacy applications, components (Java, .NET, CORBA), XML schemas; patterns and other key building blocks for application development.

Employ these assets in your tools of choice in developing Web services. And, as these newly built Web services are created and deployed, complete the lifecycle by feeding them back into your catalog, mapped against the business roadmap for which they were built. These Web services now become part of the developer's everyday toolkit--with the result being faster, higher quality, less expensive application development and integration.

In addition to helping companies improve future development efforts, this kind of model-based approach also makes it possible to avoid making unnecessary investments. By better leveraging the assets they've spent years--and billions of dollars--building and deploying, companies find they can do much of the work with the SDAs they already have.

As more and more integration and creation occurs, users need the ability to easily search and view assets from multiple contexts„obusiness processes, application architectures, etc. This will make it far easier to make decisions about how to go about adding Web services or any other application project.

Three enormous market opportunities--application development, integration and Web services--appear to be intersecting. Companies that rush headlong into this uncharted fray will be disorganized, inefficient, frustrated and, eventually, unsuccessful. Enterprises that pursue a model-based use of their software assets will operate faster, better and more cost-effectively than competitors.

No one looks forward to cleaning out a messy closet, especially IT folks faced with budget constraints, competitive pressures, and a spaghetti-works of software components cluttering the enterprise. But a pragmatic, incremental approach to building your SDA library is worth the effort. Organizing corporate software assets and mapping them to specific business processes will help propel an enterprise to the front of the Web services race„oand keep them there.

Brent Carlson is vice president of technology and co-founder of LogicLibrary. Carlson is a 17-year veteran of IBM, where he served as lead architect for the WebSphere Business Components project and held numerous leadership roles on the "IBM SanFrancisco Project," a consortium of more than 100 companies united by the mission of providing a framework for Java-based application business components. Carlson is the co-author of two books: SanFrancisco Design Patterns: Blueprints for Business Software (with James Carey and Tim Graser) and Framework Process Patterns: Lessons Learned Developing Application Frameworks (with James Carey). He also holds 17 software patents, with eight more currently under evaluation.

Editorial standards