Enterprise Architecture

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):

• Percentage of uptime over the period
  
• Number (not percentage) of outages that had a severity of 'moderate' or higher (that is, subtract 'outages' that still allowed the majority of the system to function and be usable)
  
• Amount of staff hours supporting system (help desk & other support)
• Amount of staff hours maintaining system other than user support (break-fix work or developer/administrator maintenance that isn't user support)
• Amount of staff hours designing and developing enhancements, new features and subsystems, refactoring existing code, porting, integrations, etc. These aren't related to break/fix and maintenance described above. Make sure to include all development cycle activites including requirements, specification, testing, etc.
• Amount spent on annual maintenance agreements for all commercial software that the system utilzes. If a commercial software resource is shared with other systems, pro-rate this cost to each system as you choose and assign costs appropriately.
• The burdened cost of labor for your organization or even better, for your IT department. This value is a figure representing what it costs per hour for your company to employ someone, including salary, benefits, employer-paid taxes, and overhead for facilities, office equipment, etc. For most large organizations, this value usually falls between $80 and $125 USD per hour. If you don't know this value, ask your financial people if they have it, or for an estimate. For the purposes of this exercise, use one generic value even if your financial people have this number broken down by job or location categories, as it will make the analysis much easier and give you nearly the same results.
  

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.