Does shadow IT really exist?
For those who have worked in the IT space for some time, there can be no doubt that budgets and funding are under pressure. Unless you are business unit selling IT services to your own and other organizations, your ability to justify budget growth and even hold onto the precious dollars you already have, seems to be a constant battle.
The war seems all but lost when you discover that a business unit has gone out and invested in a cloud or 3rd party solution without any consultation and without allowing IT to have any influence over the decision.
In some cases this speaks to misaligned priorities, in others, it indicates a lack of understanding of the role of IT in such decisions and in the worst possible cases it suggests that IT is not meeting the needs of the business or the business has given up on expecting IT to address ongoing needs and concerns.
For some organizations, there is probably something in the middle. Every organization has business users that are somewhat ‘trusted’ by IT. I have always considered them, business professionals with a passion for technology. These individuals have pet peeves about the mainstream systems that they use, or have evolved solutions of their own in the absence of a solution being offered up by IT.
Is writing a macro shadow IT?
This is probably the most facile of examples. A business user leverages the power of Microsoft Excel to either build or repurpose a piece of VBA or Macro code to automate some activity with data. I have seen it many times. In fact in the realm of Lean Data Management and agile data management, using macros, excel functions and formulae to profile, manipulate and build data sets is incredibly common.
I would argue, that if IT didn’t write the macro, doesn’t ‘officially’ support it or is oblivious to it’s existence or turning a blind eye to its use, then it is indeed shadow IT.
What’s the risk?
Business users who engage in shadow IT activities will either vociferously defend their use of the solutions that they deploy or they will feign or claim ignorance and then ask for an IT solution to the problem.
At this juncture problems emerge. Shadowy solutions are often poorly documented and likely poorly understood by users. They may be fragile or poorly executed, inefficient or deviate from well accepted or conventional development practices – ever heard of ‘goto’ ?
The more painful risk is the fact that the business may become heavily dependent on the solution delivered in the shadows and it may eventually fail at a critical juncture in its use. The originator may be no longer around and the ability to fix the solution may be beyond the capabilities of the business. Processes will fail, deadlines will not be met and misery will ensue.
Mitigating the risk
The most sensible approach to mitigating the risks of shadow IT rather obviously involves IT being engaged with the business and helping to either take inventory or stock of all the solutions in use and then further understanding where these solutions are addressed by existing functionality in the mainstream portfolio of IT offerings.
Where gaps exist, have a transition or migration plan.
Where no transition plan can be created, funded or justified, take the necessary steps to understand how the solution is used, architected, maintained and supported- call it out as an ongoing issue to be monitored and periodically reviewed with a long term strategy or approach for resolution.
The reality is that ‘Shadow IT’ is pervasive, the question is whether it is identified and the necessary mitigation controls put in place to manage the risks associated with it.
CIO’s can choose to either embrace businesses’ desire to solve their own problems and leave IT to address big picture problems like infrastructure or integration or whether they want to get down in the weeds of operational solution building and problem solving. If an ‘in the weeds’ approached is used, then the question will be whether solutions can be delivered in an agile and cost effective way that really meet the demands of the business.