by Carl Ververs 2 July 2008
As long as IT has been around, IT professionals have complained about being unappreciated and misunderstood.
Well now, are you surprised?
How can business types think of IT any other way than a bunch of maladjusted adolescents spouting acronyms and building Rube Goldberg systems?
In just about any IT shop, computer systems are ramshackle contraptions, over-complicated compared to the simple problems they were designed to solve. Additionally, the staff on the ground often thinks their systems are the summit of innovation and that there is no better solution ever developed. Only a few individuals know parts of the system in-depth and they guard that knowledge with their lives. One can only obtain a full picture of the entire production system by piecing together what the Cabal of Elders is willing to share.
Subsequently, IT spends most of its time chasing its tail rather than innovating and building revenue-generating solutions.
The mantra of IT is, "But we have legacy systems!" Even improving them gradually is considered costly and risky. The cost and risk of rewriting systems, possibly replacing bespoke components with better commercial ones, is automatically assumed to be far greater than the total economic impact of keeping the current systems.
But is it?
The best way to find out is - shocker - to run the numbers. What do system outages cost? What percentage is related to attempts at improvement? How many people are "twirling plates" to keep the system alive? How much additional revenue or cost savings have you generated by actually rolling out system or process changes? And, the big one: what’s your systems’ “bus factor”, meaning how much of the system’s operation is in only one individual’s mind?
If you do this exercise for all of your critical business systems regularly, you'll get a clear picture of where your IT staff is spinning its wheels getting nowhere. It need not be more than a few hours of work if your staff is already collecting the right metrics, for example outage attribution and impact. If you then do some basic analysis of what components can be bought and which have to be rewritten, you get an idea of the rewrite cost.
Anticipate the obvious IT response: "But, dude, it took us years to build this system! How can you say we can rebuild it quickly?!?"
Keep in mind that the "current systems" were not implemented with their full functionality in one exercise; they grew organically, through bouts of discovery and spurts of modifications. Also remember that the actual functionality need not be discovered: it's starting you in the face. In many business systems, a mere 50% of implemented functionality is actually used. (See this article on Standard Life’s internal audit) So rather than just assuming that a rebuild will take the same time as the original development lifetime, take a good hard look at the useful functionality and estimate how much effort that will take to reimplement.
Many CIOs make the mistake of not looking far enough ahead. Engulfed as they are with keeping the current systems stable, they cannot muster the courage to embark on a risky and controversial system overhaul. Consequently, they are caught off-guard when a critical individual leaves or the system starts to crumble under its own weight. By then it is too late and the options are few. When this happens, IT has become the victim of its own creations (the “Frankenstein effect”) and no longer has the option of running its own agenda. It tends to become a drag on the business rather than an asset.
Look at all the business-critical systems and add up how much time is spent fixing problems and keeping them going. Then figure how much production time is lost because of attempted improvements and you will get a good idea of their cost of ownership. To round out your assessment, take a stab at listing the business functions that are actually used and sit with your development managers to estimate how much time it would take to reimplement that.
So rather than have The System Beast keep you hostage, tame it with your most menacing weapon - your calculator – by doing a bit of systems detective work. You'll be pleasantly surprised what you'll find.
About Carl Ververs: Carl has been a business transformer through technology since the start of his career two decades ago. Always at the vanguard of new thinking and creative application of systems, he built CRM systems, used SOA and applied Agile techniques well before they were named.
Carl's technical expertise lies mainly in high-performance computing for derivatives trading and business process management. His background spans a wide spectrum, including business application specialist, hierarchical storage system architect, customer management systems designer, trading operations manager, Agile project Management coach, SOA practice lead, PMO/QA director and deputy CIO. Carl is an avid musician and composer, computer graphics artist and geopolitical pundit. He lives in Chicago with his wife and son.
No comments:
Post a Comment