Reprise of the Golden Rules of IT

Reprise of the Golden Rules of IT

Summary: In an earlier post, I ran through the "Golden Rules of IT" that appear to guide how medium and large organizations adopt technology. I've had several requests to run through those rules once again.

TOPICS: Virtualization

In an earlier post, I ran through the "Golden Rules of IT" that appear to guide how medium and large organizations adopt technology. I've had several requests to run through those rules once again. Virtualization technology adoption, by the way, appears to be following along the same path as the adoption of other technologies.

Although there would be some that say the cautious approach codified in these rules no longer are helpful, most IT executives would counter by saying, "maintenance is a very large part of our IT budget" and that "we need to be very prudent when making major changes." Several readers wanted me to present these "Golden Rules" as a separate post. Since we just live to serve, here's a reprise of the Golden Rules of IT.

  1. If it's not broken, don't fix it. Most organizations simply don't have the time, the resources or the funds to re-implement things that are currently working.
  2. Don't touch it, you'll break it. Most organizations of any size are using a complex mix of systems that were developed over several decades. Changing working systems that are based upon older technologies, older architectures and older methodologies has to be done very carefully if the intended results and only the intended results are to be achieved.
  3. If you touched it and it broke, it will take longer to fix and, in all likelihood, cost more than you think to fix. Most of today's systems are a complex mix of technology. If your organization is going to be updating part of that tower of software, be prepared for unexpected consequences and see Rule 2.
  4. Good enough is good enough. Although it would be nice to have the luxury of unlimited amounts of time, resources and funding and be able to develop every conceivable feature, most IT executives know that they are only going to be allowed the time, the resources and the funding to satisfy roughly 80% of requests for new capabilities.
  5. Don't make major changes unless people are screaming! If they're not screaming, see Rule #4, good enough is good enough. If they are merely asking for changes, see Rule 2, don't touch it, you'll break it, and Rule 3, if you touched it and broke it, it will take longer to fix than you think. If they begin screaming, you'll have to do something to respond, just touch things as lightly as possible.
  6. Embrace your "jerkdom." We all know that we have to move forward and help our organization be as efficient and successful as possible. In short we must do the best we can with the resources, the time and the funding available and accept the fact that years from now someone will look at what was done and come to the conclusion (based upon what they know then) that what was done was insufficient in some way or didn't properly forecast future events and requirements.

Adopting virtualization technologies is really no different. It's important to know where the organization is (from a technology standpoint) and where it wants to go before taking on major changes. In the end, it's far better to take the time to envision a comprehensive architecture that includes the capabilities of today's technology and makes allowances for the appearance of new technology before leaping headlong into an implementation process.

Topic: Virtualization


Daniel Kusnetzky, a reformed software engineer and product manager, founded Kusnetzky Group LLC in 2006. He's literally written the book on virtualization and often comments on cloud computing, mobility and systems software. In his spare time, he's also the managing partner of Lux Sonus LLC, an investment firm.

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
  • Also for home use....

    Useful rules, also for home use. The mainboard of my PC just died because of an unnecessary BIOS flash..... :-(
    • It only takes one board to learn that lesson :(

      my sympathies.
  • Rule #7?

    Maybe I should have added 7. Always have an escape route in case things go bad!
    • Maybe you shouldn't do it in the first place

      If you need and escape route then you have expectations of failure. If you plan on failing you will fail so why not just ditch the original plan in the first place?
      • Escape route scenario

        How about when a new operating system version is announced? At that point, a small organization may choose to try it out by installing it. Just in case they have a problem with the installation or if incompatibilities show up, it would be wise to have a plan on how to back out that update.
        • Backup the back up of your backup

          "Backup the back up of your backup" Is already an IT rule. Nothing is immune to failure, so built in redundancy is a must. Furthermore in business, contingency plans should always be made for every decision has a risk factor. It is impossible to move forward on anything without the risk of failure.

          However, it is also equally impossible to maintain the status-quo without the risk of failure. Even if you don't change things, exploits and the awareness of vulnerabilities will.

          Standing still and doing nothing is not a solution to risks.
  • Responses to individual points:

    1. Won't happen - Gartner tells everyone it's cheaper to do things so-and-so way. Therefore they'll touch, grope, molest, do what they want because they think it'll work better. (uh, not always...)

    2. Ditto

    3. Ditto

    4. True.

    5. Well, start touching and molesting as in point #1 and they WILL scream.

    6. Managers think they can do that. They just end up jerking everybody around and that's when talented people leave, sometimes taking their notes with them. (No wonder companies are making standardized databases of documentation. Loyalty is so 1950.) But I digress; those who do come in are a gamble. When you have a good employee, be good to them in return. We're a civilized society, right?
  • RE: Reprise of the Golden Rules of IT

    These golden rules should be labeled the "old golden rules" from the olden days of IT. If these are what an IT department chooses to do they'll quickly become irrelevant.<br>The new golden rules are much shorter. <br>1. Add Value or get left behind.<br>2. Embrace change or get left behind.<br>3. status quo = getting left behind. <br>If you aren't adding value, embracing change or are satisfied with status quo you aren't helping the business move forward. And if you aren't helping the business you will be left behind for IT leaders who understand the business' needs.
    • Risky

      Sometimes it's better to be left behind when things work than to risk everything for the sake of novelty.

      If my COBOL payroll system works fine on a mainframe, why would I rewrite it just so I can run it on a Windows or Linux server and be forced to upgrade it in 10 years when new technology won't allow today's code to run? The mainframe code has been running unchanged for 40 years in some places, why change it?

      New technology is fine and important, but not as important as a working environment.