IT Commandment: Thou shalt not condemn departments doing their own IT

IT Commandment: Thou shalt not condemn departments doing their own IT

Summary: Thou shalt not try to stop departments from experimenting with web services and developing skinny applications for their own uses.The IT department has often been among them the most conservative and change-phobic in the entire company.


Thou shalt not try to stop departments from experimenting with web services and developing skinny applications for their own uses.

The IT department has often been among them the most conservative and change-phobic in the entire company. "That's not the way we do things and we've been doing this 15 years," is a common type of comment from within some IT departments.

Well, some of the things we'd like to do today--we haven't been doing 15 years--so we are making it up as we go along.

And there are a lot of IT things we have been doing for fifteen years and you know what? Why not let the users have a go at designing simple applications for their specific needs? They sometimes need to be changed.

But it is not surprising to get pushback from the IT departments because they have seven layers of legacy systems to keep running and are backed up on new IT projects from the last century. And the last thing IT departments want to do is to sit down with the users to design and implement an application.

That's why it is better to have the users create their own "skinny" applications using some of the software development platforms and tools. These can be the wiki-type software platforms such as those from SocialText and Jotspot. And it can also be the scripting languages such as PHP and using open source databases such as MySQL.

Why not let the users have a go at designing simple applications for their specific needs? Better than giving it to the IT department which doesn't generally communicate well with users and produces a half-useful product half-of the time.

But IT departments are also about control--just one of many departments within each company vying for pole position. The great loss of control for the IT department was the PC revolution. And it certainly was a revolution because departments could use their budgets to buy their own Apple computers, later IBM PCs, and run their own applications when they wanted to run them, thanks to VisiCalc then, and Excel today.

However, the IT departments have gradually reasserted control over the PC hardware. PCs are very much locked down in most companies in that users have a lot less control over the software they can run and the PC itself. Centralized management of PC networks and development of central provisioning technologies have enabled the priests of the glass house to regain control over the hardware and most of the software.

IT users are still bringing in revolutionary technology from the outside world but the battle lines have shifted. The battle between IT users and IT departments has moved away from the PC towards using mobile technologies such as PDAs, which have become much more "personal."

And departments have also been interested in developing and using collaborative applications based on web services.

The mobile push has been going on for a while now, and IT departments have given in on that one despite initially strong pushback based on security concerns. The skinny application development is based on using wiki-type online web services platforms.

Joe Kraus, CEO of Jotspot, says that the Jot wiki platform can replace the "Excel based applications combined with email which is the way a lot of departments run collaborative projects, and it's messy."

Ross Mayfield, of SocialText delivers the same kind of message. "There are a lot more easier ways to do things than to email Excel spreadsheets to each other."

Here are some examples of simple, skinny applications at  and

It is said that only 20 per cent of an application's features are accessed by most users but I would wager it is more like five per cent.

And needing just five percent - users can use the modern software development platforms to create their 5 per cent solutions for almost anything they need.


Our IT Commandments:
  1. Thou shalt not outsource mission critical functions
  2. Thou shalt not pretend
  3. Thou shalt honor and empower thy (Unix) sysadmins
  4. Thou shalt leave the ideology to someone else
  5. Thou shalt not condemn departments doing their own IT
  6. Thou shalt put thy users first, above all else
  7. Thou shalt give something back to the community
  8. Thou shalt not use nonsecure protocols on thy network
  9. Thou shalt free thy content
  10. Thou shalt not ignore security risks when choosing platforms
  11. Thou shalt not fear change
  12. Thou shalt document all thy works
  13. Thou shalt loosely couple

Topic: Apps

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • There's a word for it

    Its called <b>Shadow IT</b> (two words?). On the plus side, it fills a need and is innovation at its best. On the other hand, it creates "islands of technology" that are hard to manage and support (and remember, 90% of ALL software costs are in the maintenance phase).

    I have argued this point for MANY years to IT management. It goes like this: When the Japanese car companies hit American companies HARD in the 70's and 80's, Major auto manufacturers studied the reasons behind the success. The "answer" was always right in front of them (Dr. Demming told them so!), but more to the point - they found that a low-level line worker can STOP the assembly line if he found a problem. This problem would be brought to the attention of managers and engineers, and they would ALL work together to fix it. This "canary in the coal mine" idea works very well.

    This "empowering the front line" mentality is lost on IT. Younger workers find EASILY CORRECTABLE FLAWS that languish in "todo" list forever. Larger, endigmatic problems are visible, and SOME younger IT guys try to bring it to upper management attention - to the detriment of their future careers (mine included). IT has a LONG history of killing the messenger, and older IT guys have been cowed into accepting it.
    Roger Ramjet
    • Compromise Solution.

      Let users create their own version of a needed application while IT mulls the whole idea over. 5-10 years down the road when (if) IT ever decides to try to meet the user's need and the original need still exists (a lot can happen to a business in 5-10 years), let it be known that the user/creator is responsible for shutting down the temporary solution once IT has built a solution with at least as much functionality as the home brewed one.

      As an upside, IT will have a functioning prototype when they decide to design the "formal" solution, so understanding the real purpose of the application will be much easier and simplify the design phase.

      The biggest downside is this type of solution tends to show how much IT [i]isn't doing[/i]. It is hard to trot out the old "It can't be done the way you want it" line when some schmoe outside of IT already did it, and did so in his spare time...
    • Hold that thought, Rog . . .

      Roger says: On the other hand, it creates "islands of technology" that are hard to manage and support (and remember, 90% of ALL software costs are in the maintenance phase).

      On a small scale, I experienced this back in the stone age, I am not kidding, at more than one employer. <phone rings> User: Hi, the network is broken. Me: Why do you say that? User: My dBase application won't work. This would be a program developed by a non-programmer within the department and, since the files resided on a network drive, if the program didn't work, of course the problem must be the network.

      At this point, it would was typically easier to just debug the program than to argue with the user about whether s/he had any reasonable basis for thinking this. Now, imagine this scenario on a much larger scale.

      I agree that if your IT department is so cumbersome or unapproachable that production departments feel they can't get the tools they need to do their work, you have a problem. But having departments independently develop applications without coordination from IT will probably lead to yet more misery in the end.
  • mess years down the line

    When someone writes their own program who will support it down the line when it has problems and the person who wrote it is gone? What kind of flow chart did they leave for others to follow
    • Does it matter at all?

      Assuming I wrote an app for MY USE does it matter what happens after I am gone? If the company decided it was worth giving to others then IT should get off it's backside and write it the way they want.

      Seems pretty simple to me...
  • Depends on Responsibilities

    The problem is "Business Users" want to have their cake and eat it, too. (Note: There's probably big money in enabling this.)

    Take the classic example of locked-down desktops. Why would IT lock-down a desktop when it's obviosly going to piss people off? It's simple: Because if IT can't control what goes onto the desktop, then IT can't control what happens to the desktop or what the desktop does.

    My organization absolutely loathes non-productive hours. Waiting for a IT help desk tech to come fix a broken desktop counts as non-productive hours for whomever is waiting. Consequently, IT is blaimed and beaten when people sit idle. This is reasonable when it's IT's fault for not taking preventative measures or not responding fast enough. It's not fair when a user installs some random piece of software or hardware that repeatedly crashes his machine.

    The same thing can be said for MS Office "applications" (glorified macros). How can IT be held responsible for the integrity of a given applications, if some shadow-group developer decides stick a managers password into so Excel template or Access database that an entire department users. Ever heard of escalation of privledges as a means of hacking a system?

    The point is "the business" wants to point the gun at IT and say keep this running and keep it secure with one hand while crashing the system and breaking the security with the other.

    That all being said, I think an innovative IT organization (and/or innovative enterprise software providers and/or IT outsourcing companies) have a golden opportunity to develop more fluid security infrastructure that stops preventing people from doing what they need to do but prevents them from wreaking havoc.
    • Here's an idea...

      Train the non-IT folks on some general "good practices".
      • Doesn't work...

        When a few worm-infected machines from users who failed to understand those "good practices" can destroy the productivity of thousands of people.

        But from an IT systems engineering standpoint it begs the question: Why can a few rogue machines do so much wide-spread damage?

        Giving users more control requires more robust, well engineered infrastructure. Not simply "buying Cisco" or "buying IBM" and declaring it good because it's Cisco or IBM or whatever the vendor du jour is.
  • Bad idea

    [b]That's why it is better to have the users create their own "skinny" applications using some of the software development platforms and tools.[/b]

    That's a really bad idea for many reasons. The biggest reason being that having users designing their own little stovepipe applications is almost a guarantee that the data won't be available to any other application that needs it and your legacy data management will be an out of control nightmare. I see that every single day.

    What business really needs is a compromise. A responsive IT department that develops the micro-apps for the user departments. Rapid development using a common data dictionary and really flat front end, like PHP.

    What tends to happen is the IT department throws more and more documentation and requirements gathering at those wanting development. Then they spend months developing something the users ultimately don't like. After a while other departments quit asking and some closet geek throws together something on google maps.
    • No, it's a GREAT idea.

      I hate to tell you this but if you look at all the software running on PCs it started with a user, not some backroom IT guy.

      If it was up to IT everyone would still be running green screens and dreaming of VGA.

      That would be why the PC displaced so much of IT.
      • I disagree

        It was some IT guy but that's the mistake being made here.

        As IT guy we are enablers. If the users wants to create thier own data access applications all we do is enable them to do so. This could be a database mainted by IT that is maintained in manner that makes it easy for the user to code up any information they want from the data in the manner they choose.

        There are two type IT people out there. IT enablers and IT road blocks. The IT enablers change the world. IT road blocks are fogotten and joked about as how we did it in the old days.

        Remember it was that IT guy you knew who got you into your first PC and helped you network to get to the interent and configured it for home movies. It's always been a IT guy first, just the enabling type who's excited about a product.
      • Displaying your ignorance again

        << I hate to tell you this but if you look at all the software running on PCs it started with a user, not some backroom IT guy. >>

        What you know about IT would fit in a MSFT EULA. And be just as vague and meaningless.

        In shops that have a responsive IT department centralized development really does work. All those enterprising shade tree developers may think they're smart and are getting the job done but they're actually creating a long-term productivity deficit for the company.

        The best example I can think of is a customer site that has data rice bowls in various departments. The biggest app in terms of data was a shade tree project gone horribly wrong. 7 gigs of data replicated 6 times across their production SQL server. Whenever they needed different functionality, they'd clone the original database all over again. Brilliant!

        The customer developer quit and they got mad at me when I told them the app was so horribly convoluted that it would grind to a halt in a couple weeks. Which it did. Then they got mad when I told them it would cost more to fix than replace it with a functional app integrated on the back end. They didn't believe me, too many guys like you on their staff. So they hired someone to fix it on a contract I knew was low-balled.

        Several hundred thousand unproductive dollars later the outsource contractor is gone and I'm back doing what they now realize they should have done in the first place.

        And I see that over and over and over. Companies making the same monstrously expensive mistakes. But then you show up some place that does it right and they love their IT department. It's orderly. There are processes but results come before process. They're actually ahead of their workload and are not fighting brush fires all day.
        • There's a line

          I can think of MS Office applications that should have been done as enterprise-class systems, enterprise-class systems that should have been done as MS Office applications, and "enterprise-class" systems that were (are) substantially less robust than the average MS Office application.

          The question is: Where is the line?

          The problem is today's departmental application meant to help 5 people keep track of some data turns into tomorrow's mission-critical system. The thing is, for every one that becomes critical, there are 20 that never really get used and 9 that stay within their original scope (I just made those numbers up, BTW).

          So in that way, No_Ax is right: A lot of the best stuff doesn't originate in IT.

          Also, IT can't afford to invest in every new idea for a database.
        • A difference of opinion = ignorance???

          Thank you so mush for demonstrating why the majority of IT people FAIL to EARN the respect of others. You, like most IT, take a difference of opinion and start off by calling people names. I bet you win over all the folks in your company with that attitude... NOT!!!

          You tell this story about how you stood by (doing nothing) while others made mistakes so that when it did fail you could strut around hollering "I told you so".

          You could have taken an hour a day for a week and taught who ever was replicating the data base how to structure it properly, you could have pulled the "rice bowls of data" into a real data base and straightened it out for them, you could have suggested top management send them to some basic classes, in fact there are a hundred things you *could* have done. Instead you preened your tail feathers the entire time for the "I told you so" dance.

          Dude, you wouldn't last 5 minutes in any company I ran.
          • Doing those things would get your fired

            Fired for not doing your job. They said the system was fine even though you could prove they were wrong. You are mandated to stay out. So you disobey and fix the system. A fixed system they didn't want. So they fire you for being insubordinate. I've seen this. I call it bad management. It covers about 3 of the jackass management traits. Usually comes in the form of empire building and your fix is seen as destablizing thier empire. Can't have that now can we....

            This would work for some companies and others it wouldn't work for.
          • Yes and No

            1. People don't like unsolicited advice
            2. People like unsolicited advice to management even less
            3. Read voska's reply
            4. Some organizations require time be charged to a project. What project to you charge when providing unsolicited advice?
            5. Just because people receive unsolicited advice doesn't mean they follow

            Doing what you describe requires:
            1. An organization that values people who "do the right thing"
            2. Really good people skills
            3. Strong political skills
            4. A pre-existing political standing
            5. A source of funding for the work to fix it

            Sure, it can be done. I'm sure in your company it's possible. But it's a daunting task for most people in most companies.
  • control versus controls

    In many organizations, IT falls under the direction of the accounting department head. The pros and cons of this can be, and have been, debated ad nauseum. I'll talk about one of the positives. Learning the concept controls. Some controls are common sense (don't give customers access to costs/margin data). Some are only evident when you understand how disparate systems interact in the real world. Average end-users typically only worry about controls they've been told to worry about. Sometimes they aren't even aware of the controls because the software they are using have those controls buried in business logic they aren't privy to. Things get even worse when you look at Sarbanes-Oxley requirements of publicly traded companies. If companies are going to allow non-IT personell to develop their own software, it is incumbent on those companies to educate those non-IT developers on all appropriate controls, including Sarbanes-Oxley requirements, they could ever encounter during their development. If I were advising a company looking at this kind of software development model, I'd tell them that as long as this level of education is taking place, go for it. If the company isn't willing to spend the amount of resources required to attain this level of education for their non-IT staff, forget it.
  • Oh Please

    So then, if users have lots of experience living in buildings, let's let the end users play architect and design their own buildings? Or since they drive their own cars, let's let them design automobiles? There's a reason that programmers get trained to do the stuff that we do.

    A good application is a mix of efficient code, an intuitive interface, secure programming, good database design, efficient error handling, dealing with multi-user concurrency issues, writing good documentation, etc. The problem is that when an end user (with no real training) does their programming "lite" stuff, you end up with a pile of garbage that IT gets to support when it breaks. Then (inevitably) the "application" is given to sompe poor programmer to "touch up". And it shouldn't ever take very long for the programmer because all of the "real" work has been already done. The programmer just has to bolt on little things like security or error handling. And if it talkes longer than an hour, the programmer obviously must be milking the project.

    Even in the real 10 Commandments, the first one lays down the law in no uncertain terms: I am the Lord, thy God. Though shalt have no other gods besides me.

    It's the same here ... I am a programmer. I don't pretend to be an accountant or a doctor or an architect or a lawyer or a fireman or a police officer or any other profession. I wouldn't even know where to begin doing those jobs. Why do they think that they can so easily do mine?
    • Why you are wrong.

      "let's let the end users play architect and design their own buildings?"

      As a matter of fact some of the most awe inspiring homes were designed by non-architects.

      "Or since they drive their own cars, let's let them design automobiles?"

      Hmm, care to take a look at the fastest cars in the world running on race tracks? Guess what, most of them have been built/tweaked by "shade tree mechanics", not GM engineers.

      What you seem to be suggesting is that people can't develop enough skill to get where they want to go. History has proven that is a stupid concept and it is usually voiced by those in power and their power base is being destroyed.

      Some of the VERY BEST coders in the world have NEVER taken a class of any kind, they learned it on their own time via the school of hard knocks.
      • Uh ... no.

        End users do not design buildings. If you actually knew any architects, you'd know that an architect has to physically sign-off on the architectural drawings of their buildings and can be sued if the building has any structural defects resulting from the design. You average end user picks colors, trim and non-critical elements. It's the same with programming: I'm fine with users picking colors or the location of where fields get placed on the screen. The critical stuff (like security, data integrity, re-usable code libraries, etc.) cannot be done by un-trained users. This may come as a shock to you, but there **are** standards for good programming out there that need to be understood.

        End users do not design automobiles. There is a big difference between "tweaking" something that already exists and designing something from scratch. Most of the fastest cars that I've seen are maintained by folks who have gone to a trade school or have completed an apprenticeship to study their area of expertise. Most of them hold several certifications.

        I'm not saying that people can't develop a skill set for programming. But it takes time. I don't know of any coders who are good that have never been properly trained. The only people who say that non-programmers can write professionally written code are the ones who've never seen professionally written code. Maybe back in the 1970's when the industry was in it's infancy it was possible ... but certainly not in recent years. Things are far too specialized now. And I am talking about code here that gets written by group of programmers, and then supported by others. Any code monkey can write a "cool hack" ... but writing a system that is supportable in the long-term is far different than this.