AT#37: Stop Botching your IT-Landscape!
Things happen in IT projects. At times, some quality elements will be sacrificed in order to offset the vagaries of the project delivery scene. A solution that works of course. But as discussed in a previous article, a working solution brings no comfort regarding its quality, since almost anything can be done in the virtual dimensions of software and computers. And when issues arise to put pressure on IT teams, a suboptimal alternative will be presented as a fix, a patch, a temporary solution, or as the most wickedly named: the tactical solution. In circles of experienced IT managers and practitioners, the ‘tactical solution’ sits somewhere between fairy tale and sham.
The word ‘tactical solution’ suggests to the non-IT stakeholder that the chosen tactic is a step sideways, and that once the applicable steps are taken, the product should attain the desired state, which is often labeled as the strategic or target solution. Because the tactical solution works (since anything in IT can be made to work), it could be viewed as a small step in the right direction.
After this dodged solution is implemented, we simply need to perform a few extra steps to reach the strategic state, right?
Tactical Solutions Waste Work
The solution does work, and common wisdom says “If it isn’t broke, don’t fix it”. Besides, how could it be broken if it works? Unfortunately, and I know that I am repeating myself, the fact that it works does not guarantee of anything. Tactical solutions are never presented to you as a step in the wrong direction or a step back, but most of the time they are, and here’s the logic:
Once a tactical solution is delivered, the next step is not a move forward, but rather a revision of the sub-optimally designed part. The system will often have to be partly dismantled and then rebuilt, throwing away portions of the previous work. That’s not a step in the right direction. That’s not tactical. That’s wasted work.
Assets Built on Hope Aren’t Enough
Not many business people are keen to pay for throwing away something that works, and as such, when money for the next phase becomes available, there is a good chance that the sponsor will want to invest in an effort that brings more business value, rather than redoing what’s already completed. Moreover, in many cases the bewildered customer will need to pay an additional fee for the removal of something that was paid to put in place. That’s a stillborn path to the strategic state.
Hence, to get there, the IT team has to hope for luck, or must fall back on secrecy. Hope to correct the situation in the lucky event that the tactical solution breaks, or count on a forthcoming major project to allow them the opportunity to openly (or discretely) administer the needed rework effort.
Next time you hear a friendly IT person confidently talk about a tactical solution or any of its synonymous labels, don’t jump too fast to the conclusion that it will elegantly be transmuted to a strategically positioned investment based on a greater plan to get there.
Most of the time, a so-called tactical solution is in reality a permanent solution that sacrifices agility and becomes an IT liability for many years to come.
This post has been originally published on https://the-new-age-of-it.org/ by Architectural Thinking Leadership Team member R.M. Bastien
What you should do:
A previous post discusses how to regain control of your application landscape and reduce botches step by step:
- Make Business People accountable for Architecture
- Add ‘Technical Debt’ as a project metric
- Integrate Legacy Renovation with your Governance Structures
AT#5: Architectural Thinking – the iPhone of Enterprise Architecture Management
AT#10: Technical Debt – the ignored Killer of “Agile” Enterprises