The Dangers that Lurk Behind Shadow IT

While IT managers may worry about what's going on in the IT department, when you move that work outside of the building, it's enough to give most managers fits. Our Datamation columnist looks at what's lurking behind Shadow IT.


You Can't Detect What You Can't See: Illuminating the Entire Kill Chain

On-Demand Webinar

(Page 1 of 2)

While IT managers and even business leaders may worry about what's going on, and what's not going on, in the IT department, when you move that work outside of the building, it's enough to give most managers fits.

Most public companies these days are very concerned about meeting the requirements of the Sarbanes Oxley Act of 2002 (SOx). Section 404 of the act mandates that management have effective internal controls and requires external auditors to attest to the effectiveness of the controls.

This, of course, is creating an abundance of antacid moments in boardrooms all over the United States and those fears are being transferred to the IT groups as well because the financial systems and key operating systems that run the businesses are all under the spotlight. As a result, groups are hiring consultants by the bus load to come in and help put appropriate policies and procedures in place.

The problem is, however, that some groups are overlooking the threat of critical information systems that have been created and are maintained outside of the formal IT organization.

The term ''Shadow IT'' refers to groups providing information technology solutions outside of the formal IT organization. Their existence is due to groups thinking they can do things cheaper and/or better than the formal IT group. Also, it may be that the formal group can't meet their service requirements or the formal group is forced to develop generic applications in an attempt to meet the needs of everyone and controlling costs versus customizing applications to meet the needs of business units.

Whatever the exact reason, the basic premise is the same -- the business units aren't satisfied with what is being given to them. For example, if manufacturing is under extreme pressure to lower costs while increasing throughput, they may have need for special RFID software. But when they approach the formal IT group and it turns out there are no plans to develop the necessary software, then that may force the business unit to write software outside of IT, for example, or source it from a third party without IT.

In this day and age, there are some very significant issues facing companies that choose to allow Shadow IT groups to exist.

One of the first issues to recognize is poor resource utilization. By having unofficial IT resources scattered through business units, there can't be a cohesive effort to prioritize and schedule work across all of them. That means Bob in accounting may have a four-month backlog on IT related requests for his group, while Sharon in sales may have capacity but be unaware, or for political reasons, be unable to help Bob.

Another issue is lack of proper processes. Sometimes the Shadow IT people have formal IT process training. Many times they do not. As needs popped up, they figured out how to respond through trial and error, turning to friends or leafing through manuals. As a result, proper requirements definition, documentation, testing and change control are lacking. Even IT professionals have been known to let proper processes slip due to pressures from business, let alone when managed by people who may fail to see the value of the processes.

Lack of controls is yet another problem. Proper security and operational controls are crucial now. It's one thing to implement proper controls over formal IT systems and personnel. It's far, far harder to try and retrofit controls over systems that were ill-designed to begin with. It's far better to design quality, security and controls into a system than to try and inspect them in or add the necessary functionality later. Sometimes, it is virtually impossible to do it without a ground-up redesign of the software or system.

And then there's the simple matter of mistakes.

People may have the best intentions in the world when they write a critical application or design a key system. However, simple mistakes can and do happen to everyone. Unless proper design, testing and monitoring processes are in place, the total risks to the organization increase.

To illustrate, I recall a very capable gentleman outside of IT who wrote a reporting application for billing. He thought the SQL command captured all of the billing data. However, since he wasn't a SQL expert and did not methodically test the application, it turned out later that the vital report missed the first and last day of every month.

Page 1 of 2

1 2
Next Page

0 Comments (click to add your comment)
Comment and Contribute


(Maximum characters: 1200). You have characters left.



IT Management Daily
Don't miss an article. Subscribe to our newsletter below.

By submitting your information, you agree that datamation.com may send you Datamation offers via email, phone and text message, as well as email offers about other products and services that Datamation believes may be of interest to you. Datamation will process your information in accordance with the Quinstreet Privacy Policy.