SOA Services: Build – Don't "Clone"

"Cloning" and using a Web services wrapper to extend the life of existing applications might sound like a good way to save on maintenance and development costs. But in practice it is far from a perfect science. The decision to Build SOA services instead ultimately saves time and promotes Web service reuse.

The Idea: "Forget About Cloning Humans: Clone Your Apps"

The IT team at Jesper Travel, an online travel service, had a novel approach to systems management. It created new applications and new business processes by reconfiguring and cloning existing applications. One application, for example, had 30 "separate" instances in production, all customized to a certain degree with 50% to 60% of the application core residing in each instance.

The IT team thought that this approach would reduce development time, make maintenance easier, and reduce problem resolution time. They reasoned that:

• More developers would be familiar with a larger percentage of applications.
• The architecture was simple: the two points being the cloned application and the customer.
• It would be easy to plan and compute future costs, since a new customer = new hardware + cloned application + a few modifications specific to that customer.
• A new customer would be a self-contained "business model," with all the costs associated with it and no shared infrastructure to depreciate.

Why It Wasn't So Smart

This approach was flawed in four major ways. First, if there was a bug in the core code, it was replicated.

Second, some of the core code was altered during the customization process, but these changes were rarely documented. So, when the triage team needed to determine why something was not working, it spent far more time doing detective work than actually fixing the problem.

Third, the result of this cloning was redundant infrastructure, maintenance, and development—not only at a business area level, but also at the IT level. The IT team had no way to share capacity between customers, lower the TCO, or manage SLAs. (But the hardware and software vendors were quite happy with this model, as every new customer for Jesper Travel meant additional hardware and software purchases.)

Fourth, core code changes impacted every customer who relied on these services. Following every change, the core and related customized modules had to be tested before the company could redeploy these services. In addition, the IT team could not simply patch applications, but had to go through more steps, all of which translated into a longer release cycle. Plus, this approach embedded rules, or policies, as code into the application—rather than abstracting them. This added to the level of redundancy and made change even more difficult.

A Better Approach

If you want to save on maintenance and development costs, focus on reuse. Unlike cloning and reconfiguring, reuse enables growth within your business, while minimizing complexity within your IT systems.

By building a SOA, you can attack redundancy at the application and infrastructure levels. For instance, you can distill from hundreds of duplicated applications a small set of core application feature sets. These reusable SOA services can be used globally, across applications and business processes, resulting in greater operating efficiency and reduced maintenance costs. In addition, you can standardize, break out (abstract), and control the core infrastructure functionality of key business processes, including security, identity, profile, message queuing and brokering, translation, directory service, etc.

With a SOA, you can construct new business solutions far faster than by cloning applications. As a result, you can spend more time customizing solutions for each customer, while still leveraging your core set of SOA services.

Bottom line, these smaller services you build actually can help reduce your hardware and software costs since they allow your company to better utilize what it already has. In addition, you can measure, manage, and secure these services or change them easily with security policy changes.

For More Information

How to get started with building SOA services: read the free white paper: Getting Started with Web Services