Lifecycle or Immortality

Vilas talks about exceptions to the enterprise architecture as slums. I have to agree. In fact, as EAs, we need to plan for their emergence. Let's face it, people will find ways to work around processes, rules and guidelines if enough money is at stake and frankly, that's the way it should be. Our enterprises exist to make money and aside from regulations, everything that does not support that goal is fluff. There is a large difference between governance and policing and too often, we forget this and start EA practices from the point of enforcement rather than guidance and containment. The best way to manage deviations from the grand plan is to anticipate them by providing a lightweight process for granting architectural waivers.

Let's revisit the SDLC acronym. The last half is Life Cycle. Death is a part of the Life Cycle. Yes, there is an old maxim that says "software lives forever" and there is truth to that; that is also the kind of immortality that needs to be well-defined within an enterprise architecture. Therefore, don't make slums immortal. Give them a lifespan. Why don't we want slums around in the first place? Well, they are difficult to govern and that leads to expensive maintenance. It should be relatively easy to show the long-term maintenance costs for a slum in it's business plan. At some point, the system will either need to be turned off because of TOC or, it needs to be refactored into the EA to lower it's cost of operations.

When designing the process for granting a waiver, ensure that there is a Retire or Re-factor clause in the plan stating either a date the software is to be removed from production or the date re-factoring is to begin. Clever designers will keep the existing EA as a constraint when building the slum so that when it comes time to retire or re-factor, the cost of doing so is as low as possible.