03.25.10
It’s Such a Mess, Just Replace It!
[Cartoon]
How often have you heard, “It’s such a mess, just replace it.” You may have heard this when talking to a car dealer about replacing your old car. You may have heard it when talking to your IT guys about your current software solution. Both are trying to sell something.
Except replacing software solutions is not like replacing an old car. Automobiles are all very similar. Driving one is much like driving another. This is unlike software that requires training to understand the new solution. A new automobile will probably fit right into your garage. New software usually will not fit right in where the older software operates. When replacement of software encompasses multiple products and multiple integration points with other existing software, things get even more difficult.
Software replacement in most organizations has become a costly and extended effort. Projects often overrun their budgets and miss critical deadlines. Most see this as either a quality problem or a scope-creep problem. I believe that this is an oversimplification of the root problem.
The root problem is that most organizations cannot see the potential consequents of making major software replacements. If they could see the consequences, they would take action. They might choose to take a more incremental approach. Or, they might budget money and time to address the consequences.
Unfortunately, organizations that do not practice Enterprise Architecture do not have the ability to see the unseen that is needed to fully identify consequences. As a result, these consequences become the “unseen consequences”.
How often in a software project have you heard of the “unseen consequences” causing delays? It usually comes as software failures or hardware failures or bottlenecks in the process flow. Can these categories truly be described as “unseen consequences”?
Software is engineering. Software should be treated as a set of components that can be modeled. Each model can be simulated and all components can be simulated within the existing enterprise software. There should not be any “unseen consequences”, only probabilities of outcomes from the modeled simulations.
When the actual components are constructed, the simulation outcomes provide the expected performance criteria for each component. If a development component cannot meet the expected performance, the consequences can be tested in the modeled simulation and compensations applied.
The proper way to fix a software mess is not necessarily to replace it. Through the Enterprise Architect it is possible to determine alternatives and consequences. So, the next time you hear the phrase, “It is such a mess, just replace it” from someone in IT, ask if the one saying it can identify all of the consequences. Have they consulted their Enterprise Architect to validate the replacement using models and simulation?
Closing the Business / IT gap
