Picture this: You are the CIO of a $500 million manufacturing company in a competitive market. You have spent more than $20 million over the past five years on computing infrastructure, various development environments, databases, and the like. Some projects have been enormously successful while others never quite delivered on the promise. For the most part, upper management didn't get involved. But things have started changing lately. Your management has decided that new technology will be the linchpin of the corporate profitability picture over the next five years. You are charged with going out and making it happen. Of course, your management wants it done fast, and given the millions already expended, they demand results. At the same time, you are still under the gun to produce value today. It is a demanding mission and not for the faint-hearted.
Faced with such a scenario, IT managers increasingly feel like they are caught in the middle of an old joke about the tourist who asks directions and is told, "You can't get there from here." IT management knows in theory what it wants to accomplish but doesn't know what it will take to get there. They look at the millions of dollars their organizations have invested in software, and they aren't sure how to integrate the old with the new. The only practical approach is to combine new, innovative techniques and software with the existing investment in applications. I call this approach leverageware.
What is leverageware? It is not a product, the latest technology, or a new category of applications. Rather, leverageware is an approach to application integration that allows organizations to implement technology as a logical progression over time, rather than as a series of hard starts and stops. Leverageware moves organizations into the future by building on the value companies already have instead of abandoning or trashing what they have already accomplished.
This is different from what companies typically do. For example, many organizations have plans in progress to eliminate key mainframe applications altogether because they are aging and no longer flexible enough to meet today's challenges, never mind tomorrow's. Typically, these organizations intend to rewrite, from scratch, all the parts of the applications --only using newer technology.
What's wrong with this typical approach? Plenty. There is no leverage with this strategy. Organizations find themselves reinventing the wheel for each new application and technology. But if they look closely at the existing applications, they'll often find pieces that still work quite well. In fact, these pieces were developed, tested, and perfected over years and are now rock-solid. They represent substantial assets that can be leveraged.
For example, an algorithm may implement a key business function that has not changed. Too many organizations assume that they must completely rewrite the algorithm. I take a different view: If the algorithm, business rule, or piece of application logic does the job well and doesn't need to be updated, it makes sense to continue to use (leverage) the code in the new application. This code can be encapsulated (turned into a reusable component) and used in the rewritten application or across other applications that require the same functionality. This model is different from the traditional object-oriented reuse model. These components are large-grained services that are easy to identify. They also include well-defined interfaces that make integration easier.
I am beginning to see organizations using the leverageware approach, particularly vendors with products in the middleware area. For example, it is behind IBM's Component Broker software environment, which provides an integration point connecting legacy CICS- and MQSeries-based mainframe applications with client/server and Web applications. It is also key to Hewlett-Packard's framework for application integration. Both environments are intended to allow organizations to leverage existing logic in new applications. Microsoft is taking a similar approach with its Message Queue Server, a version of MQSeries for Windows NT.
Common Object Request Broker Architecture (CORBA) -- essentially middleware for objects --may be the most broad-based attempt to foster the leverageware approach yet. CORBA provides the mechanism to enable applications to find and make requests to objects that provide a needed service for the application. These objects can be made using technology from different vendors yet still work with the application and with each other. This is possible because CORBA-compliant objects are encapsulated, essentially remaining black boxes that reveal only those interfaces that are necessary to get the objects to do their jobs.
As a result, an organization can leverage a portion of proven, well-tested CICS code as part of a new application through integration with various types of middleware. Or, it might assemble a variety of existing objects via CORBA into a new application. In all cases, the organization has leveraged existing code.
Microsoft takes a different approach to bridging the gap between components across a distributed environment. DCOM, unlike CORBA, uses RPCs rather than a messaging protocol for communications. Like CORBA, DCOM has a local object-system registry that connects local and remote objects.
Both approaches are designed to provide a key building block for leverageware. To leverage existing components across a distributed environment requires that developers or users be able to locate and make the connections between these pieces. Given that few organizations are able to select a single software infrastructure, bridges between these systems are critical. Companies such as Visigenic Software Inc. and Iona Technologies Inc. have developed products that bridge DCOM and CORBA. Omnis Software offers a product that bridges ActiveX and JavaBeans.
Java adds another dimension to cross-platform aspects of leverageware. JavaBeans, an architecture based on CORBA, allows Java applets to work with any component that is CORBA-compliant. In effect, JavaBeans becomes a standard set of interfaces and behaviors that enables ISVs to build components. These components are very close to Microsoft's ActiveX model. The key difference is that the JavaBeans architecture is closely tied to CORBA, while ActiveX is closely tied to the DCOM model. To ensure leverageware, vendors are beginning to build bridges between ActiveX and JavaBeans.
The other major place where I see leverageware beginning to thrive is the Internet. How much new code do you imagine was written for famous Web sites such as that of Federal Express? While clearly the interface is new and the connectivity software was redesigned for Internet protocols, the back-end logic and data were written for the mainframe. Intranets are becoming important simply because they can leverage so much existing logic and data in a distributed fashion.
It is this demand to Web-enable existing applications that will finally drive IT managers to embrace leverageware. Organizations can't possibly rewrite years of business applications for the Web. The only solution is to identify and leverage the valuable pieces of those applications for use in new applications.
Encapsulation and Internet access to existing applications are simply the beginning. Creating new software based on a leverage model is where organizations will get the long-term value out of the leverageware approach. Leverageware will finally allow organizations to start collecting the payoff from all the investments they have made in applications up until now. As old functionality is leveraged as components in the building of new applications, organizations will speed development and drive down the cost because there will be less code to create from scratch, test, and debug.
To take advantage of leverageware, however, developers need to adopt a different approach to the application development process. Rather than model entire applications as they typically do, developers must look at the business functions that an application is intended to perform. Where they find functions that are essentially the same as functions the business currently performs, they will have identified their key leverage points. They can then isolate (encapsulate) these functions as modular components for use with new applications. In this way, new business applications can be built without having to first decompose and then completely rewrite existing stovepipe applications.
The Hyper-Tier (see "Leveraging Chaos," DBMS, April 1997) is important to this process because it defines a logical model for leveraging existing application resources as organizations integrate new technologies over time. The Hyper-Tier isolates different system resources in one of three layers (access, coordination, or resource) that are accessed through well-defined, open interfaces. For example, the existing business rules and application logic that you want to leverage resides in the resource layer. What are the functions that will likely be repeated in new applications? While the answer is different for each business, just look at every business process (from human resources to sales to customer service to production) and you'll find a host of reusable functions. Those are your leverage points.
How do you get started? It isn't as hard as you think. Here are my six steps to start making leverageware a way of life for your organization:
1. Pick one key line of business (notice I didn't say application) and determine what key, repeatable functions exist.
2. Map these business functions to the primary applications that service this business area.
3. Set up a team to isolate the code that handles these business functions so it can be encapsulated as components.
4. Determine what business functions are not yet automated.
5. Establish a team of developers and business people who can begin to develop new components (from both existing logic and new logic) for these new business functions.
6. Repeat this process across your enterprise, selecting the applications that contain the most business benefit.
The payback from leverageware grows substantially as you get into the leverageware habit. At first, you'll experience some savings as you leverage a few functions in the form of reusable components. Over time, your library of reusable components will grow to the point where large portions of the new application consist of this existing code, which immediately saves on testing and debugging. As your developers get the knack of leverageware, you'll get applications faster, they'll be of higher quality, and the cost should be lower.