Evolute Consulting - Architecture & Process

The customer I work for at the moment has a simple policy. Shadow IT is allowed, but never the responsibility of the IT department. And there's something to be said for this approach. Let me specify that my customer is a Belgian enterprise and thus not subject to the restrictions of Sarbanes-Oxley. There is no need to register all actions within the company for audit purposes. And even so, as the article states, compliancy is more about accountability and the audit trail to this effect, than about proscriptive processes. And so these IT components should be isolated from other systems, but should never take away the possibility of the business to solve their pressing needs.

The concerns surrounding data integrity and security are legitimate, but to my knowledge, in most companies and/or governments seem to struggle with these concepts and a quick fix is not out there. They are both disciplines on an enterprise scope that need attention. However, to use CMMI terminology, most organizations are still very much cults of heroes at this point. Strides can be made, but to think your organization has a handle on these, is more often than not, a mirage conjured up by those departments involved.

So why is Shadow IT such a bad thing? The four reasons offered by the author are:
1. They are sharing critical, private data with the wrong people somehow.
2. Their data is fundamentally flawed, inaccurate, or out of date.
3. Their data would be of use to many others, but they don't know it exists.
4. Their ability to solve their own problems is a threat to IT.

Let’s tackle these one at a time, starting with number 4. As I stated earlier, this is a question of accountability. When a policy is in place that business can operate a Shadow IT, it should be made clear that these components should stay separated from the organization’s assets and that they remain the responsibility of the people that introduced them. On the other hand, the IT department should take note, and devote some resources to analyze why this component is needed, and which capability is lacking to provoke such an introduction. The temporary nature of such a component up until such time as the business agility catches up to the needs, should have an impact on the IT roadmap in coming years.

Number 1 is a sore point in Belgium, as the Privacy Commission watches over all citizen data like a hawk, and the feeling that any leaked company data is detrimental to the company image (whether true or not). It seems that these shadow components, while kept isolated, should still comply with security standards and policies, once again hampering the agility their sponsors crave. But here, as with all security related topics, a risk assessment should be made and squared off against the benefits such shadowy undertakings generate. There is no clear cut answer for this topic.

Number 2 is argued by the author that the business experts creating these capabilities know what they are doing, and for the boundaries of their domain, this is very true. However, when regarding information across departmental boundaries, or even organization boundaries, this expertise could be significantly less. How to ensure that every such endeavor is in line with the company strategy and not just a business owner freewheeling, is not a trivial matter. It might be more than just the lost opportunities arising from number 3, and in a worst case scenario detrimental to other efforts happening within the organization. Luckily such doomsday scenarios are not very likely, if the business strategy is well thought and robust.

It all comes down to how well your business departments can coordinate with IT operational and transformational departments. The cooperation in this triangle most certainly has an effect on the overall business agility, and should be a well-oiled machinery, ready to give its conveyor belt some slack when needed, but able to rein in that slack with proper initiatives further down the track.

Thought

EA

Operations