IT Commandments: Ignore them at your own risk

IT Commandments: Ignore them at your own risk

Summary: Here's a stone tablet's worth of rules that no IT shop can afford to break.

SHARE:
TOPICS: Outsourcing
34
IT CommandmentsIn February, when L'Unix blogger Paul Murphy handed down his IT commandment, Thou shalt not outsource mission critical functions, we thought to ourselves: There must be a stone tablet's worth of basic IT rules. We asked each of the experts in ZDNet's blogosphere to supply a commandment that IT executives dismiss at their own peril. So far, a dozen bloggers have delivered.

Some offer truisms -- obvious, yet too frequently ignored: Thou shalt not fear change, writes John Carroll. (ZDNet reader Anton Philidor suggests a corollary: Wait.) And Enterprise Web 2.0 blogger Dion Hinchcliffe cautions: Thou shalt put thy users first, above all else.

Others submitted challenges to IT traditions: Tom Foremksi commands that Thou shalt not condemn departments doing their own IT. There were also some doses of admin common sense: Thou shalt not use nonsecure protocols on thy network, reminds Marc Orchant.

With further ado... 

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 confuse projects with planning
  6. Thou shalt not condemn departments doing their own IT
  7. Thou shalt put thy users first, above all else
  8. Thou shalt give something back to the community
  9. Thou shalt not use nonsecure protocols on thy network
  10. Thou shalt free thy content
  11. Thou shalt not ignore security risks when choosing platforms
  12. Thou shalt not fear change
  13. Thou shalt document all thy works
  14. Thou shalt loosely couple
  15. Added 4/14/04: Thou shalt not let thy web servers be hacked

Should these commandments be etched in stone? Tell us why -- or why not. Have we missed any IT rules that are broken only at great risk to the soul of your business? Add your own IT Commandments...

Topic: Outsourcing

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

Talkback

34 comments
Log in or register to join the discussion
  • Thou shall not Gerrymander or Balkanize

    The history of UNIX is a history of struggle. Departments were given hardware and admins, and each one deployed their own solution. This created a variability in quality whereas your customer was only as empowered as his UNIX guru was talented. This problem NIXES your (stupid) Number 6!

    After UNIX balkanized with all of these "islands" of influence, there was *some* effort at combining things. But since most people (read managers) didn't understand UNIX, they punted - promoting questionable techies, who had their own biases - to try and combine the whole. They made a mess of things, so new groups followed the tried and true method of balkanization.

    When one group becomes more powerful, they Gerrymander the other groups - thus consolidating their "power". So a group that contains some average to below average admins becomes De facto architects for the entire enterprise - proposing infrastructure that is of low quality, but having the power to push it through.

    Thus is the sad tale of UNIX. Balkanize with department-level IT, and then pick (arbitrary) favorites with Gerrymandering. When people ask - why isn't UNIX as prevalent as Windoze if its SO MUCH BETTER - you have your answer.
    Roger Ramjet
  • Thou shall Collaborate

    I would suggest that every company adopt a Sourceforge-like system for internal development. Every single programming project should be there - even "home grown" ideas. In this way, there is visibility to all projects, and thus there is no "Shadow IT".

    A portion of your yearly merit-increase revue would be your contribution to software projects. Each project team would rank members on their time and effort, and that would be rolled into the overall merit revue.

    Management would have an opportunity to view projects, and "throw" money at ones that were deemed significant.
    Roger Ramjet
  • Thou shall follow Dr. Demming's continual improvement process

    Ignore it at your own peril! Just as in science where (most) everything is a theory that COULD be changed at any time - the same applies to computer SCIENCE. Once a project is launched, it should NOT be forgotten! It should be fine-tuned (metrics and analysis) and possibly replaced when something better comes along. This goes beyond just "change" - it is a continuum the encompasses every project and process in the company.
    Roger Ramjet
  • Thou shall understand and use matrix organization

    A "Matrix" organization is basically a different way to organize management. Instead of a tree-like hierarchical structure, you use a 2D matrix. This means that you "belong" to 2 departments at any one time.

    The columns of the matrix represent projects, and the rows represent technologies. Each project (say Human Resources) requires many technologies (network, storage, servers, clients, various software, security, etc.).

    The way this is ALWAYS implemented, the "vertical" (column/project) organizations have all the "power" - the money, the influence, the management ear - but their abilities are questionable (not to THEM!). The temptation for these organizations is to "go around" the "system" when they need something. Example: A new hot-shot manager comes from the competition and knows only one CAD program - Catia. He finds sympathetic ears in Body Engineering (they HATE SDRC - bad surfacing), and manages to get a project to implement Catia. But instead of working with the technology groups, he uses his own local admins and Catia consultants to create the "pilot" (the big joke at Company 'F' is Pilot=Production). These people create a half-ass implementation that doesn't take all infrastructure factors into consideration (but it "works"). This manager gets approval from above and VIOLA it is set in stone - and it gets "thrown over the wall" to the technology groups to support it (90% of the cost of ALL software implementations is in maintenance).

    Horizontal organizations (rows/technology) are weak in power - but very strong in ability. If you don't place STRONG management to head these groups, they get rolled over (see above example). Vertical organizations don't require as strong management, they rarely get rolled over. In any event, horizontal organizations need to stay engaged and stay relevant - If you are not nimble enough to turn-over technology quickly - then vertical orgs WILL go around you.

    SO there you go. Strong management and nimble/quick response is needed in horizontal organizations, while good project management and patience is required for vertical organizations (Back office/Front Office).
    Roger Ramjet
  • Never make changes on Friday or before going on Holiday

    Never Change things just before you want to go away at the weekend or on a longer Holiday.
    PeterGermany
    • most broken commandment

      This one is probably the most broken commandment there is. Heck, that's when most of our code deployments happen...on Friday nights.
      alphawiz
  • Thou shalt reference thy disk packs through three layers of indirection

    Priests of OpenVMS know this in their hearts.
    DelbertPGH
    • Mike Cox?

      Virtualization virtualizes problems - thus making troubleshooting a virtual crap shoot . . .
      Roger Ramjet
  • 1st command

    Thou shalt not CYA...under commit and over achieve eliminates the need.
    harrisjw
  • Thall Shalt Not Commit Pointer Math

    Any half-decent computer scientist should handle structure
    access using overlays, templates, schema or other such
    mechanisms. Pointer math is the last refuge of the scoundrel in
    my book.

    Additionals:

    Name Thy Variables Clearly, To Keep Thine Codebase Readable.

    also known as

    Honour Thy Vowels, To Not Be Retentive Of Them
    Tim Carpenter
    • And also

      No untyped pointers. While we're at it, how about no pointers and no arrays? Down with 'C', up with Ada!
      Roger Ramjet
  • Thou shalt not buy equipment based upon price alone

    Get what your Administrator needs to do the job, and to do it well. Remember if you buy based on price alone, you will ususally get what you pay for - and it will usually end up costing you more in the long run.
    pheible
  • Do not believe that you will make a better product selection decision ...

    ... because you accepted the vendor's invitation to a prestige sports event.
    Uriah_z
  • Thou shalt not write down thine passwords

    Here I am at a large bank with the teller and her manager searching through their paperwork for their userid and passwords. Both ladies had thier paperwork within 2 feet of me.
    srivera9
    • ....and thou shalt not use birthdates or social security numbers

      do I need to add anything to this?
      wh0zatguy
  • Thou shalt not allow users to click on links in email messages

    This is the way unscrupulous folks get past all the network security that you set up
    wh0zatguy
  • I work for IT in State of CA gov't; let's see...

    is 2 out of 15 any good??? :-)
    mgardner
  • Add an eleventh commandment

    11. Thou shalt not entrust critical system and/or process passwords to only one or two employees. This could criple your business if both are not available at the same time.
    bly_jdm
  • Thou Shalt Not

    horde knowledge from your co-workers. We ALL benefit by collaboration.
    Real World
  • Thou Shalt Readeth thy Book on Security Best Practices

    If you don't know how your systems can be attacked by hackers, you can't implement good security, and you shouldn't be developing/programming/supporting systems. Period.
    coffeenite