tag:blogger.com,1999:blog-15145059.post8106450776455286880..comments2024-02-20T03:26:29.516-05:00Comments on predelusional: Shadow IT vs Silo ITStephenhttp://www.blogger.com/profile/03934169832326108710noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-15145059.post-47129257232882266012008-05-19T08:52:00.000-04:002008-05-19T08:52:00.000-04:00Shadow IT isn't about having a single point of fai...Shadow IT isn't about having a single point of failure.<BR/><BR/>Let's get this straight. Shadow IT didn't name itself. It isn't evil.<BR/><BR/>I have firm evidence that Shadow IT is up to thirty times (30x) more efficient than Silo IT. More than one corporation. With that kind of efficiency, you can have double staff with each having double wages and still come out way ahead, not just in cost, but in responsiveness. You might even get used to it.<BR/><BR/>I've done maintenance on two half million line perl applications. I did it in the worst possible way both times - there was no hand off from previous maintainers. It wasn't that hard. I don't know where this misconception comes from. Picking up other people's code is difficult in any language.<BR/><BR/>The same people who set up Silo IT are the ones who enforce a minimum 10 day turnaround for simple services. It's a mind set. What is bizarre is what incentives they might have to make these decisions. They'll defend it to the last.<BR/><BR/>Shadow IT isn't about everyone just picking whatever tools they want to get the job done. Typically, the department has zero resources, so the developers use what is available for free. Perl is free. MySQL and Postgres are free. Apache is free. Linux is free. Python is free. So you get LAMP development. Go figure. But this isn't as complicated as Solaris (or much worse, Windows) Java, JSP, Javascript, pick one of Oracle, Sybase, MS SQL, DB2, UDB, etc., a zillion class libraries, and deployment to a server by script. The development server doesn't behave like production. When (not if) production goes down, it stays down for days or weeks. It's because no one knows enough to diagnose the problem.<BR/><BR/>I have more on this topic in future episodes.Stephenhttps://www.blogger.com/profile/03934169832326108710noreply@blogger.comtag:blogger.com,1999:blog-15145059.post-68409553900816258382008-05-17T08:22:00.000-04:002008-05-17T08:22:00.000-04:00I can understand where you're coming from. it is q...I can understand where you're coming from. it is quite frustrating to see things done in such unproductive way. <BR/><BR/>Corporations do not like their systems to be dependent on any single person. Employees can leave anytime for whatever the reason. <BR/><BR/>If the developer leaves, who will maintain the application? have to find someone else who knows the developer's language of choice, db of choice, etc. and understand the code that may not be written in a way someone else can maintain (perl code can be notoriously hard to maintain for someone else for example)<BR/><BR/>What if you have dozens of developers, each writing apps in different languages, using different databases, apps and operating systems. How do the corporation ensure maintainability of the applications going forward with many different platforms, languages etc. <BR/><BR/>This is the fundamental problem that drives organizations to specify standard platforms and languages, and groups to support these standards. As a result the silos come about and causes the problems you've outlined in your post. <BR/>Silo IT is simply bad practice. Taking 10 days to fulfill a request is not acceptable. IT has to have much better service. If not, shadow IT emerges as a result. But I don't think the Shadow IT is the answer as it introduces other problems as stated above.Unknownhttps://www.blogger.com/profile/07736462173706533241noreply@blogger.com