Watch out for the products that have snuck in behind your back The mention of shadow IT can produce beads of sweat on the brow of any knowledgeable IT staff member. For those who do not know, the term covers any company systems and services that are not procured by the IT department. The toil and trouble of a single shadow IT occurrence can cause a headache that sticks with the company …
The problem in my last organization was not unauthorized applications so much as out of bounds use of authorized ones. The government agency was responsible for operating and coordinating a large number of accounting systems and producing consolidated reports from disparate and somewhat noncongruent data. The core accounting systems were mainframe based, using CICS, DB2, and COBOL in some instances. The remainder lived on a variety of Unix systems, some with web front ends.
The tools were Excel, Access, and FTP, wielded by far too clever accountants. They would download files, load them into their spreadsheets and databases, reconcile inconsistencies, and upload changes. Once they worked it out by hand, they wrote .bat files to semiautomate it to a reasonable degree. We in IT usually found out about one of these little atrocities several months to a year or so after the "developer" retired or moved on to another job and a change of fiscal year or to one of the feeder systems broke it. By the time the situation was properly noticed there were better than 500 such "systems."
After a number of such emergencies the agency director established a team (outside of IT) tasked to restore order and come up with a Plan to consolidate them and bring order to the house. That team, headed by a new hire, did a quick analysis, decided (a) the IT staff was too hidebound for the task, and (b) that it would need a large amount of money to hire consultants and purchase new tools in order to correct matters properly.
I retired about a year later, by which time little progress had been made, and when I visited last summer, about another year and a half on the situation was still mostly unchanged, except that the development money had been "burned" and the ashes had been turned over to the IT staff for completion, paid for from the system operations and maintenance budget.
Even as someone who works in an IT department I find most IT departments to be too slow and too obstructive to be considered the first port of call for new software and systems.
Its just so much easier to bypass the IT procedures -- which generally involve a mess of form filling and half a dozen approvals ( some from people who have left the company) -- download the software and install it. I have my whole development environment off the Web rather than use the clunky out of date proprietary tools that are the "official" development environment.
Having bypassed my own IT department I can now surprise my business users by delivering software next month rather than the next year or never delivery date they have come to expect.
Most business users would rather go to a cheap dentist than have any interaction with IT. If IT had a culture of serving their business users than their convoluted internal politics then the Shadow Systems problem just would not arise.
Since you are part of the IT department you're probably able to fix it yourself, but all the other mortals
Six months down the road when their fancy new had-to-have-right-now environment throws an error starting up who will be yelled at for not knowing how to fix a product that nobody knew they were supposed to support?
"Hard drive crashed?" - "That's no problem. As long as you save your data on your "personal" drive, which actually sits on the file sever..." - "Yes, the server is backed up twice a day." - "Oh, you run your own server?" - "SQL Express, you say... On your notebook"
CLICK
"Tell me, who gave him admin rights again?!?"
Agree completely. The problem is that too many IT departments are ultimately run by the CFO that sets the budget. Anxious to meet targets, IT management squeezes out development cash and competence is outsourced and lost. If you're really unlucky, IT management will be hell-bent on overperforming on finacial targets.
For the business, this really isn't a problem because they will have their own discretionary spend budget, and since IT won't use that money, they take care of it themselves.
If people were to run their company based on a recharging model whereby the business owners set priorities and fund IT from their own budget, you could get around this mess. Of course, that also means that the business 'wants a say', which may not always be a good thing...
@Edwin. That is exactly what I do here, I run the company and the IT department. In fact we started as an IT company and then added the other 'bits' as needed to keep clients happy and operational.
While this works very well for a small company I think, as the company grows, there becomes much more 'empire building' in departments which is a very strong driver of what this article points out.
@Ivan 4
Agree, and I didn't say it was easy :)
However, I have seen it work in at least one Fortune 500 company, but that was a company that also had good budget control and accountability all the way up and down the food chain, as well as across geographies "in matrix", which makes it quite hard to hide any substantial IT.
Sadly, most companies claim to have this sort of control, but in practice it often applies only up to (but not including) VP level, so the overarching supervision is missing.
Having bypassed my own IT department I can now surprise my business users by delivering software next month rather than the next year or never delivery date they have come to expect.
You can thank $DEITY that you do NOT work for my employer, because my boss would have stuffed your ass into the Trebuchet sling, and sent you on a new career trajectory!
Cow boys like you can work elsewhere!
It is bad enough that IT must deal with the sales weasels who always try to get ShIT past us, but to have one of our own do it; that is unforgivable. Here is your PINK SLIP. DO NOT allow the door to hit you on your way out!
This post has been deleted by its author
I think the iThings are mentioned because they are the things that attract the 'empire builders' in any company.
I agree that new hardware is interesting, especially if I can take it apart to look inside, but the results of people trying to use ShIT software can be very amusing since in most cases it a) won't install and b) if it does install somehow it generally doesn't run. In house we use OS/2 and our clients use OS/2 modified to run industrial systems and engineering equipment.
Back when I were a lad, "IT" was mainframes and shadow IT was PCs and Sun workstations. Actually my first job was to look after some Apollo workstations that had been bought _after_ a run-in between a bunch of engineers and the corporate IT dept (corporate IT insisted on getting an IBM mainframe that was unsuited to number-crunching, and then charged royally for processor time).
It's one of the eternals of "the business" - IT depts need absolute control to run systems efficiently (= cheaply, really) but because it costs a lot of money to establish that much control, it only happens when technology is mature. So the empire of control is vulnerable to new technologies, especially from vendors who do not have a legacy money-spinner that is at risk of being killed by new & more nimble technology.
There's no point to whingeing about the situation; there is no solution, only mitigation. i.e. monitor the new technologies that are appearing and look at how they might be valuable to the business; and make a plan to work with early adopters to find out the best way of assimilating these technologies into the existing infrastructure. Resist the temptation to tell all the users to wait for the supposedly equivalent product from $INCUMBENT_BIG_VENDOR, for it will always be compromised to the advantage of their legacy products.
One of the biggest problems with "the thrill of the new" wasn't really mentioned in the article, namely the problem of divergence. e.g. the multiplicity of cloud storage offerings resulting in siloes of information and wasted end-user hours as users manually try to keep track of what information is where. That is probably the best reason of all for IT departments to engage with early adopters: at least get agreement on no more than two competing solutions that will be evaluated. Those early adopters can be your friends, as they have tremendous energy and power to influence other users.
IMHO, iThings definitely have a significant role in ShIT than other devices... if you're looking at it from a % point of view.
The iPad and iPhones are great examples, and the problem is it's hardware AND software, with an incredibly inflexible approach to working with any other system.
MDMs (and Android) really only exist because of iThings.
A few years ago I was doing an upgrade to an ERP system.
All seemed to be working fine. About two weeks before go-live UAT testing started. All of a sudden there was a massive uproar as a key piece of functionality had completely gone AWOL, all associated tables and code.
Much head scratching on our side as there were no errors in the logs and everything had gone really well up to that point.
So we cross referenced the production system still on the older release, traced the functionality only to find none of the tables/programs where marked as vendor specific code or even customer specific code.
After much digging we found out that the Vendor had demo'd some beta code on their system but it was never purchased.
Some bright spark then decided (contractor), to export the tables/programs from the demo system and import it all into the normal DEV/QA/Prod landscape, passing it off as his own code, so had managed to "save" the company a stack of cash for the functionality they needed.
Alas as the code was not signed correctly it got deleted on the upgrade.
Much embarrassment later they had to hand over vast amounts of cash to the vendor (backdated licences for 5 years), the go-live date was missed due to having to import the official code base, create routines to export the data and reload, and do another round of regression testing.
Many years ago (well, 1996) at a well-known telco the (telephone) network ops people decided to buy some new contraption to display some of their monitoring apps on the (6 x rear projector) videowall. It turned out to be some sort of X-Station. They didn't bother to tell us IT types, who ran all the HP-UX kit that ran the monitoring apps. In short we got told to make it work, we did... but it looked liked crap as a lot of the apps didn't scale well when given more pixels to use.
These were also the same people who wanted a "secure network" and so were going to order some kit to be strung together with coax 10base2. We had to point out all the floorboxes that everything was connecting to via RJ45. And as soon as they asked if it was "secure" we managed to placate them by creating a separate VLAN and suitable routing/firewalls/etc. Fine until they wanted to copy a file from the PC network to their own network. So in the end we found some old HP-UX workstations than still had a floppy drive and got them to use sneakernet...
It has been a constant in the IT business that it takes 10x lower IT resources to maintain and manage Macs relative to Windows boxes. And yet dealing with Macs arriving in the workplace "is a time sink the IT department just doesn't need." Rubbish.
The only reason Macs are any problem to IT staff is that:
1) Macs are unfamiliar to them.
2) They're too staid and lazy to bother learning Mac technology.
3) They're afraid for their jobs, seeing as it takes 10x lower IT resources to maintain and manage Macs.
Get over it. Windows box market share is being replaced with Mac market share. And that's a GREAT thing.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
