Besides technical magic, there is a way to prepare for this unpleasant situation which involve demand management process; essentially we try to justify decommissioning cost upfront.

At the early phase of demand management, it is possible to factor in cost of decommissioning into feasibility study. There are usually two major cost classifications.  The fist class is initial cost which cover initial implementation (hardware, software, professional service) and the second class is running cost which cover on-going expense (DC facility, operator, fault management, and technology refreshment, etc). We can try to reserve budget to do this somewhere in expense pool  but different organization will have different financial or booking practice that could prevent this so check with financial controller if this is allowed.

…Don’t say that i didn’t warn you, even if you get the budget, your executives may decide not to spend anyway [don't be surprised by how often you will witness this].

In case of turn key project or business outsourcing environment, make sure that vendor do cover this activity in their scope of delivery.

As a conclusion.. Decommissioning activity can be complex and costly. Recognizing it at early phase and address it in the way that suite your business/technical context will result in less headache. The suggestions are made with intention to stir up creativity and create awareness of this hidden and often ignored process.

Best wishes to you,

This is rather non intuitive as decommission usually mean potential saving from OPEX such as DC facility (space, AC, electricity), license and MA for software and hardware, cost of operation staff, and cost of management. Somehow there are cases that these saving is outrun by cost of decommissioning.

Yes, that is right. Decommissioning have cost too. It is not as simple as pull the plug and forget about it but there are changes that we have to be managed and mess to be cleaned up. This begin with cost of doing Impact Analysis, cost of implement, cost of testing, cost to minimizing risk, rewiring, and relocation. [note that virtualization technology was not available when we first built our DC.] All these cost will get more serious in enterprises IT environment with high degree of outsourcing.

Now what can we do? are we willing to let the machine running without contributing to business base line (revenue)? Sure NOT… NOT if we have a choice and the choice is NOW.

There are technical work require from decommission that if recognized earlier by planning department or Enterprise Architect, there are good chance that the cost will be in manageable range. Basically what we want is the environment that cheap to add components as well as remove components.  How can we achieve this?

I hope i do not disappoint anyone but all classic good software design principles still in play here. But Rules of Isolation, and Rules of Simplification are the top among other in this case.

Within today technology, Isolation in architectural context could mean implementing with multiple level of work-flow/orchestration. I have seen three level and i think it work well 1. at business  abstraction 2. at system abstract and 3.  at technical integration (bridge business and system). if you have more than 3 level, you will violate Simplification rules. Isolation should implement within each layer to prevent impact to propagate to outside the layer.

Rules of Simplification can also mean a lot in today context. use your imagination but here are a few. 1. fewer number of component 2. dept of the process (in straight through process – STP context) or 3. fewer number of vendor!!.

Besides EA may provide some guideline on integration, transaction and exception handling to allow add or remove components without or with minimum impact.  For example when design work-flow using synchronous call for only when it is a must (mandatory function) otherwise do asynchronous to reduce waiting time. By doing this non-mandatory can be removed without noticeable impact.
<< to be continued >>