NETTING IT OUT

Service-Oriented Architecture can be applied to update and extend operational applications that were built using non-services technology, that are not Web-enabled, and that lack the flexibility that businesses need today. This is useful when operational systems must be modified to fix data and application problems.

This report shows you how to use Web Services to retrofit, and thus extend the usefulness of, applications that are afflicted with four types of data and application problems: obsolete data structures or missing data, redundant data, redundant processing, and business-rules-enforcement deficiencies. All four of these problems share a common characteristic: application software must be modified to fix the problems. Entirely external SOA solutions won’t correct these problems.

Thus, we outline a strategy for tackling such problems. In a subsequent report, we will work through a case study with examples, guidelines and detailed solutions for addressing each of these four problems.

Retrofitting: New life for AGING Operational Systems

The first two reports in this series(1) identified nine common data and applications problems, and described SOA solutions to the underlying causes of those problems. With our recommended services solutions, you can deliver business-meaningful, current, accurate, and complete view(s) of data to employees, suppliers, customers, and software that need such data and are authorized to use it.

All solutions discussed thus far have aimed to minimize the changes required to your existing data structures and applications. We’ll refer to them as “non-invasive” for this reason. Such solutions are particularly useful for delivering data and functionality to new customer, supplier, and employee portals because they avoid the costs and complexities of changing existing applications. New applications can be brought online, and a variety of problems in existing applications can be corrected, with comparatively modest budget, time, and staff requirements.

While such solutions can break down application “stovepipes” that confine data, important data and application problems remain unsolved until the existing applications themselves are changed. In this report, we examine services-based solutions to this second class of problems—those that cannot be conquered without changing existing software.

Due to the complexity and brittleness of many older operational applications, such change rarely is welcomed. In practice, however, many organizations cannot avoid such changes. The need for clean and correct data extends beyond new applications and portal solutions. Existing operational applications require repair so that the business can function correctly. The question, then, is not whether to make these more invasive changes, but how and when to undertake such change. This report addresses the how and when.

We’ll begin the report by characterizing and classifying problems that require change to existing operational systems; then we will recommend specific implementation strategies and alternatives that can help your organization master such situations.

Limits to Non-Invasive Solutions

Of the nine common data and application problems that we discussed in our prior reports(2), four can benefit from—and, in some situations, will require—more change to existing application software than you’ll be able to effect with external, non-invasive solutions. Simply writing services for use by new applications won’t be sufficient. On the other hand, this doesn’t mean that you can’t address many instances of these problems using SOA—or including SOA to leverage its benefits in parallel, even if your particular requirements mediate against using services directly from the subject application.

The four problems that will involve some level of internal change to operational applications are:

* Obsolete data structures and missing data

* Redundant data

* Redundant processing

* Business rules not enforced correctly or not enforced by software at all

Why is this so? Existing applications can continue to cause problems for the business if the problems are not resolved both externally (i.e., on a customer portal) and internally (i.e., fixing the application’s data or code so that the application produces “correct” results from the customer, supplier, or corporate perspectives).

DETERMINING FACTORS. We have found that the pivotal factors determining the sufficiency of a non-invasive services solution can be assayed by asking these questions:

* Is the application producing “wrong” answers or falling short of customer, supplier or corporate requirements, irrespective of any new or external applications (including portals) that may use the system’s data?

* For the purposes of your customers, suppliers, or company, do the applications in question independently provide “correct” answers through existing access channels, but results don’t correlate between your systems? (In other words, do the problems arise only between systems?)

If you answer “yes” to either question, you’ll want to look for the following indicators to confirm that fixes external to the applications themselves, such as solving the problem in a portal or a Web Service that synchronizes data, won’t resolve the underlying cause...