EA: Prevention is better than cure
Many people believe that the Hippocratic Oath states that a doctor is not to leave a patient in worse condition than before they treated them. While it doesn’t state that explicitly, it is clearly a goal of any conscientious doctor.Enterprise architects should follow a similar mantra of not leaving a system in a worse state than before they attempt a fix.While there are many differences between doctors and architects (hopefully a doctor wouldn’t consider amputating an arm and replacing it just because a mechanical one could serve better), there are many similarities when architects plan for a core system fix or modernization.
Many architects are quick to consider rip and replace solutions for core system legacy systems.Today’s distributed applications are integrated with other supported or process-related systems; or leverage legacy components or systems used by other applications. Similar to treating a body ailment, there are many dependencies and complications that can arise if the entire picture is not taken into consideration.I am reminded of the series “House”, in which in many episodes the patient becomes much worse before they truly understand what the ailment is and are able to fix it.In these shows, the patient is already in critical condition and the doctor didn’t have the opportunity (or time) to research and do the advance planning to understand all the implications of decisions made in the hope of healing the patient.Many architects are placed in the same position when a premium bearing application goes down.However, this should not be the case during design.
Similarly, there are too many instances in which architects and developers jump on the latest and greatest bandwagon, trying to force everything into the new standard or methodology, when the existing solution works just fine.When modernizing a new core system, upgrading most of the interfaces is a fine objective and can provide great benefits, especially through re-use.But there are instances where leveraging an existing point-to-point solution as-is works just as well and is much less costly. As the Hippocratic oath does explicitly state, “I will prevent disease whenever I can, for prevention is preferable to cure.”Used in the right circumstances, this should apply to architecture as well.
Deeper analysis of why IT Architects prefer rip and replace is in order.
1. I have ran across developers and architects who have made technology choices solely for personal interests that have caused long term harm to the business. Likewise, I have ran across developers and architects who have incrementally leveraged legacy technology for business competitive advantage. As you are aware, many enterprises are dramatically scaling back their workforce and the developer with the resume that shows the latest hot technologies is more than likely to get a job faster when displaced when compared to his peer that otherwise has legacy skills. In today's marketplace, it is very difficult to encourage a developer to not be selfish especially when their enterprise is scaling back.
2. I think want else is missing from the conversation is the acknowledgment of different skills being required above and beyond language choice. In the building trades, Architects are really good at designing new systems from scratch, where they may not necessarily be involved with "remodeling" something that already exists. The same challenge exists amongst the IT Architect crowd in that they may know a language and good design but may not have the skill to pull off a large scale "refactoring" effort.