Wednesday, February 15, 2006
Converting Legacies to SOA: Part II
In the second part of the process on whether to service-enable a legacy system or refactor or resdesign, we examine what it would take to refactor or re-design a legacy system from scratch (or nearly so) with service-enablement added. In Part III to follow, we'll compare what we've found in Parts I and II and get an idea about which approach is better from cost and time standpoints.
Some legacy systems are too large or obtuse to make a meaningful comparison in the manner I'm presenting here. Systems that fall into this category are usually third-party COTS packages (in which case one hopes the vendor has or is contemplating a service-enabled offering) or huge enough where the cost/time scope would be prohibitive - large ERP, supply chain, CRM, and HR packages come to mind. Again, since the majority of systems like this are third-party/outsourced, anything but the most trival services will most likely be provided by the vendors and their partners.
What we're doing in this portion of the exercise is to arrive at some reasonable estimates of what it takes in time and money to significantly refactor (or completely redesign) the legacy systems with service-enablement added. This exercise is important for the analysis in Part III that follows because we will be making comparisions between the labor, time, and money expended to redesign versus the cost of maintaining the legacy systems in their current state.
Yes, this is a bit of a project management exercise, but the style of project management (agile or process-oriented) isn't of interest here. How long and how much is what we're after. In all cases, whether you interate the development, testing, and deployment or engage in process-oriented techniques, the resulting system must have equivalent functionality and features as the ones it is replacing. As such, I haven't accounted for enhancements or alterations in the underlying business processes, which are separate issues.
The basics are as follows:
Strawman Architectures: It's easy to get bogged down and do a full-scale design of the legacy systems, and the analysis outcomes are going to be heavily influenced by the approach taken in this regard. My advice here is that you want answers to the overarching issues of legacy system retirement as soon as possible, so do enough design and modeling to get a good handle on what's going to be required with respect to time and cost. My take here is that this shouldn't take weeks per legacy system, but a few days to a week depending on complexity. Get help from your fellow architects and brainstorm it if you need to.
I'm assuming here that the SOA and other service-enablement issues have already been established or decided upon in your organization. If they haven't, it makes this entire exercise very nearly moot and you need to decide those issues and direction first before proceeding further.
Task Lists: Once the strawman architectures are complete, what it takes to implement and deploy the redesigned systems must be estimated from a task/work perspective. In project management-speak, this is known as developing a Work Breakdown Structure, or WBS. If your organization follows process-oriented project management styles, the WBS looks like a waterfall-model, start-to-finish single iteration. In an agile scenario, the iterations are mapped individually until you're comfortable that the proposed WBS retains the functionality being replaced or refactored. The amount of task detail that you develop is your decision, but the more comprehensive it is, the more sound your final analysis and estimates will be. Again, its easy to get bogged down in details and trivialities that sap time with little or no return on the final analysis, so I suggest that the task depth be kept managable and completed within a reasonable period of time.
An important thing to keep in mind at this step is that work breakdown structures are only concerned with tasks, not interdependencies or available resources. That comes later on and if you try to do two or three of these at once, you'll get bogged down with the complexity. Focus only on tasks at this point.
Timeframes: Now that you have a task structure for each legacy system, its time to make estimates of how long the tasks will take. For our purposes, time estimates take two forms:
Cost Estimation: Now we're ready to get an estimate of the costs involved...
After you've completed this section, total 1-3 above up for each system to arrive at the overall cost estimate.
Now that we've collected our data and performed preliminary design and scope, now we're ready to analyze what we have and where we should go in Part III to follow.
Some legacy systems are too large or obtuse to make a meaningful comparison in the manner I'm presenting here. Systems that fall into this category are usually third-party COTS packages (in which case one hopes the vendor has or is contemplating a service-enabled offering) or huge enough where the cost/time scope would be prohibitive - large ERP, supply chain, CRM, and HR packages come to mind. Again, since the majority of systems like this are third-party/outsourced, anything but the most trival services will most likely be provided by the vendors and their partners.
What we're doing in this portion of the exercise is to arrive at some reasonable estimates of what it takes in time and money to significantly refactor (or completely redesign) the legacy systems with service-enablement added. This exercise is important for the analysis in Part III that follows because we will be making comparisions between the labor, time, and money expended to redesign versus the cost of maintaining the legacy systems in their current state.
Yes, this is a bit of a project management exercise, but the style of project management (agile or process-oriented) isn't of interest here. How long and how much is what we're after. In all cases, whether you interate the development, testing, and deployment or engage in process-oriented techniques, the resulting system must have equivalent functionality and features as the ones it is replacing. As such, I haven't accounted for enhancements or alterations in the underlying business processes, which are separate issues.
The basics are as follows:
- Develop a strawman refactoring or re-design of each legacy system with service enablement. If you decide to consolidate a number of legacies with respect to infrastructure (e.g. consolidating database servers) make sure to allocate time and costs proportionally across each system. The strawman architectures don't need to have large amounts of detail. They only need to be good enough to allow you to make reasonable estimates of time to implement and costs.
- Once the strawman architecture is complete, then develop a preliminary task list that would be executed in sequence for each legacy system project.
- Assign timeframes to each task or task group.
- Estimate costs in labor, software licenses, and other project expenditures.
Strawman Architectures: It's easy to get bogged down and do a full-scale design of the legacy systems, and the analysis outcomes are going to be heavily influenced by the approach taken in this regard. My advice here is that you want answers to the overarching issues of legacy system retirement as soon as possible, so do enough design and modeling to get a good handle on what's going to be required with respect to time and cost. My take here is that this shouldn't take weeks per legacy system, but a few days to a week depending on complexity. Get help from your fellow architects and brainstorm it if you need to.
I'm assuming here that the SOA and other service-enablement issues have already been established or decided upon in your organization. If they haven't, it makes this entire exercise very nearly moot and you need to decide those issues and direction first before proceeding further.
Task Lists: Once the strawman architectures are complete, what it takes to implement and deploy the redesigned systems must be estimated from a task/work perspective. In project management-speak, this is known as developing a Work Breakdown Structure, or WBS. If your organization follows process-oriented project management styles, the WBS looks like a waterfall-model, start-to-finish single iteration. In an agile scenario, the iterations are mapped individually until you're comfortable that the proposed WBS retains the functionality being replaced or refactored. The amount of task detail that you develop is your decision, but the more comprehensive it is, the more sound your final analysis and estimates will be. Again, its easy to get bogged down in details and trivialities that sap time with little or no return on the final analysis, so I suggest that the task depth be kept managable and completed within a reasonable period of time.
An important thing to keep in mind at this step is that work breakdown structures are only concerned with tasks, not interdependencies or available resources. That comes later on and if you try to do two or three of these at once, you'll get bogged down with the complexity. Focus only on tasks at this point.
Timeframes: Now that you have a task structure for each legacy system, its time to make estimates of how long the tasks will take. For our purposes, time estimates take two forms:
- The amount of labor to accomplish a task regardless of schedule. This is known in project management-speak as effort.
- The calendar time required to perform the tasks. This is known as duration.
Cost Estimation: Now we're ready to get an estimate of the costs involved...
- From your task time estimates in the previous step, take the total time that was assigned for each task, add them up, and multiply by the burdened labor cost factor you obtained in Part I. This will give you your esimated labor costs.
- All software costs - licenses, support and maintenance contracts, etc. should be tallied up. I have not included hardware and network costs in this analysis because these issues are usually too broad to accurately address in a generic model. If you can comfortably estimate them and want to use them, then do so.
- Any other project-related expenses unique or specific to your organization and situation must be included.
After you've completed this section, total 1-3 above up for each system to arrive at the overall cost estimate.
Now that we've collected our data and performed preliminary design and scope, now we're ready to analyze what we have and where we should go in Part III to follow.
