.comment-link {margin-left:.6em;}

Monday, February 13, 2006


Converting Legacies to SOA: Don't Put Lipstick on a Pig

Dave Linthcum has posted a few times on leveraging legacy systems through SOA. I agree, to a point. While we'd all love to wave our SOA wands and service-enable everything in sight, claiming 'Better, Faster, Cheaper' in the process, there needs to be some analysis done before committing time and resources to these efforts. This post gives you the start of an overall strategy to accomplish that with an eye to service-enabling legacy systems that benefit from it and scrapping and re-designing those that won't.

I'll be blunt: almost every IT organization has a few fragile, schizophrenic, resource-draining legacy systems in their shop. You know, the ones that always suffer outages, especially on weekends and holidays. The ones that take a battalion of developers and support people to maintain. The ones who have numerous and lengthy break-fix cycles. The ones that exist on hardware older than my teenage daughters. The ones that chew through IT expense budgets with high maintenance and support costs. And usually, they're still crucial to the business even though they should have been long ago retired and replaced with something else.

Well, sticking some type of service-enabled front-end on systems like this isn't going to make things any better. In fact, it could make things much worse operationally and financially for your IT shop because you're adding additional complexity to a system that already has numerous problems. While like many of you I find the siren song of agile, efficient, and cost-effective services very appealing, I have concerns that certain types of legacy systems are not suitable for service-enablement, never will be, and need refactoring or complete redesign. The trick here is to ferret these systems out before you attempt to service-enable them.

OK, I promised you strategy, and I'm pleased to give all of you one over the next few posts. To begin, you're going to need to get your hands on some data and facts, or 'educated' WAGs if such data isn't available or incomplete....

Overview of the Process

Part I: Legacy System Data or WAGs You'll Need

Part II: Refactoring/Redesign with Service-Enablement Project Data

Part III: Analysis

Part IV: Decision from Analysis

Part I: Data or WAGs You'll Need

For a given legacy system over the last 24 months (longer if you have the data, shorter if not...the more you have, the better the forecast/estimate will turn out):

You'll need this data in order to make comparisions in cost and time to service-enabling these systems. The next step is to make some baseline estimates of the service-enablement effort, and I'll post about that specifically later today. If you have questions, feel free to e-mail me or comment below and I'll get back to you.

Comments: Post a Comment

Links to this post:

Create a Link

<< Home
Technology Blog Top Sites |

This page is powered by Blogger. Isn't yours?

Weblog Commenting and Trackback by HaloScan.com