Rogue IT

Today I shall scratch the surface of the so-called “Rogue IT”, how it is affected or enabled by the very nature of cloud and Software as a Service and whether organizations should fight against it or just “ride the wave”.

A simple definition of “Rogue IT” is the situation where organization departments build and/or use their own applications without prior knowledge of the CIO. Because such applications do not have a “legitimate” confirmation by the IT department, it is often called “hidden technology”. Also, the costs relevant to that software or service are called “hidden IT costs”. Obviously, they are not really hidden; they just don’t appear in the I.T. annual budget sheet.

Rogue IT is not a new concept. Even before the days of the cloud, departments sometimes created pieces of “application software” to execute several tasks. This could start from an intelligent spreadsheet, which incorporated formulae to extract department-specific statistics but it sometimes grew extensively to local databases with quite sensitive data. For example stand-alone CRM applications built in MS Access which, among other things, contained some form of “Customer file”. Of course, that meant that somebody from Sales or Marketing or whatever department had some technical knowledge to build such applications (but this was often the case!).

Now, the cloud era makes things easier for rogue IT. Departments no longer have to have any technical expertise to build the application that they need. If the IT department can’t serve them fast and completely, they may choose to adopt some cloud offering to do what they have in mind. A scheduling system to track your department’s activity, a CRM for the Marketing, a ticketing system for Service operations etc. The department head can allocate a percentage of their annual budget to “invest” to such software solutions. They just make their own market research and decide to subscribe to this or that SaaS service. The fact that nowadays there are a lot of reputable SaaS solutions for any need drives the potential growth of the Rogue IT. Also, by definition, it solves some “traditional” problems that the Rogue IT users were facing: Who can develop a really workable and reliable application if they are not real “IT guys”? Who and how will maintain this application? What happens when the person who built that application leaves the organization? How can this work in a multi-user environment (departments don’t have access to setting up servers etc.)? These days, one can subscribe to a SaaS service, have their users collaborate in a cloud platform and immediately solve all of the above problems.

After understanding how cloud enables Rogue IT, we must ask ourselves whether organizations should fight against this trend or not. It seems that both aspects have their pros and cons. Let’s have a look at the two sides of the same coin:

Issue	Rogue IT is good because…	Rogue IT is bad because…
Costs	Costs of rogue IT do not burden the annual budget of the IT department and so the organization may find itself in a position that it invests in some new technologies which otherwise it wouldn’t.	Rogue IT costs may well go out of hand, if every department invests unattended. This may significantly increase total IT spending without getting the benefits that it would, if all these investments were centrally controlled.
Agility	If a specific department no longer needs or is disappointed by the performance, it may very easy choose to switch to another service. It can do so fast and easy without depending on the IT department’s availability to lead such a transition project.	When switching between cloud services, somebody must have the control of what is to happen with the data that were stored in the abandoned service and a lot more technicalities pertinent with the organization data on the cloud.
Time-to-port a new application	If each department drives its own Rogue IT project, then things will move much faster that having the IT department of the organization trying to serve everybody and manage multiple projects at the same time.	If nobody (the IT dept.) doesn’t have the central management of such projects, then perhaps departments build their own logic, diversified from corporate policy and maybe duplicate data and processes while they are implementing (e.g. the CRM customer file can/should be only one for all purposes, like Marketing, Sales and Accounting. Imagine the issues that arise if every single department had their own customer file and updated it the way that they would see fit!)
User support	Rogue IT users may be happy with the support that they get from the SaaS vendor.	IT dept. hot support is missing.

The above examples show that while Rogue IT is a reality (and will probably continue to rise), there aren’t specific rules or arguments that drive the decision to adopt or to abolish the use of it.