dcsimg

IT's Top Ten

By Bill Vass

(Back to article)

IT executives face plenty of challenges today, and based on my experience, successful IT organizations need to focus on 10 key things to thrive. I refer to these as my "Top Ten" rules for how to succeed with technology, or sometimes refer to them as IT Essentials.

Rule 1: Open Systems Succeed

This rule has been true from the beginning because open systems are standards based. Of course this is good for Sun to say because we're an open-systems company. But, I've watched many, many open systems succeed in scale and continue over a long life span.

When I was in government, I spent all my time on two types of projects: ones that were either over budget, behind schedule, and all messed up, or projects that were ahead of schedule, on time, with happy users, and under budget.

In almost 100% of the cases, the good projects were based on open standards because only open standards had the flexibility to scale. As technology changes and advances during the implementation of a project, the open systems projects could adapt and take advantage of changes, rather than be stopped or derailed by scaling and technology changes.

Rule 2: Proprietary Systems Fail

The second rule is the opposite of the first. Proprietary systems don't scale. To accommodate any unplanned growth, they must be redesigned. And this always cost more in the long run. Proprietary systems were the single greatest waste of IT dollars I saw in those 6,200 government systems I helped manage.

To use a construction analogy, imagine that every IT system starts off as a house, but grows into a skyscraper. If you build on open systems, you have a strong foundation on which your systems can grow to accommodate new business and user demands.

If you build on proprietary systems, you're starting with a house foundation, without planning that the house may one day become a skyscraper. You will end up either re-doing the foundation to support the newer, larger structure, or tearing it down and restarting from scratch; both immensely expensive and time-consuming propositions.

For these reasons, proprietary systems usually cost three-to-four times more than open systems in total. No engineer building any physical product would ever lock himself into a proprietary component or design. IT should follow the same basic engineering principles that all other design engineers follow.

Rule 3: Separation of Logical Layers

This is a key insight into a major cost driver in system lifecycle cost, and it's a technology decision you have to make early. This rule might seem very technical to a business executive, but it's important.

By spending a little extra time up front to separate your technology layers (presentation, business logic, and data) you are ensuring that each can scale and change independently.

For example, the presentation layer will always change as technology advances, but the business rules (logic) and data behind it often will not.

If you put all your logic in the presentation layer (say, under the "Submit" button on the browser screen), when you change the presentation to a cell phone, you'll have to rewrite that business logic.

If you separate the three layers, each can scale and change independently. And that ends up costing you a lot less and giving you a lot more flexibility in the long run.Rule 4: Standards Matter

Especially these days, this rule is important. Companies with written programming and process standards will succeed overall because they're following standards and open systems, meaning they can meet new technology with minimum effort. This was true on a mainframe and it's still true today.

This also gives you the internal flexibility to move resources from one project to another without huge ramp-up times for the development team. With everyone following the same standards, you end up with a very flexible team that is mobile enough to change quickly as user/business demands change.

In addition, it provides continuity on the project when key personnel change. I cannot tell you how many projects fail simply due to key changes in personnel during the development and implementation cycle. With process and technical standards, these changes are seamless. Without them, they are a disaster.

Rule 5: What's Old is New

Technology is cyclical. Take cell phones, where functionality was very thin, are now getting fatter again. As bandwidth becomes more pervasive, they get even thinner again. This cycle applies to all technology and should play a factor in your technology decisions.

I've got a hundred numbers stored on my cell phone. When my kid puts it in the bathtub, the phone is dead and the numbers are gone. The time it takes to re-enter those numbers is worth much more than the device. If the information were held on a central server, I'd be happy because I could just get another phone and pull the numbers off the central server.

Imagine the benefits you'd enjoy if you applied such thinking to all your systems.

These cycles have been consistent throughout the history of IT. First, we had everything on one big fat machine, to which we were directly connected at each location. Then, we had everything centralized on the mainframe, with lots of remote thin clients attached. Next, we pushed everything out to fat clients again, with very little on the server (the fat machine has gone from a mini-computer to a PC). After that, we pushed everything centralized back to the server again with very thin Web-based clients.

These cycles will continue along with the cycles of distributed computing models. Successful IT shops recognize these cycles and design systems that can change as the cycles change. If you follow rules one-through-four, you will always be ready for these cycles.

Rule 6: Technology is not "The" Problem

Getting people to embrace technology and understand its advantages is the hard part. It's the hardest thing IT managers do -- the job is five percent technology and 95% communication, hand holding, and getting people to understand the vision.

Even if the change is really simple and the benefits are obvious, people need to stop their "real" work to make the change. And people fear change. Try getting all your employees to rethink the very way they use computers. Remember, even though you know technology generally improves users' lives, it can be daunting to them at first.

Rule 7: Know Your Estimation Factor

Gaining a reputation for completing projects on time is important for any executive because it establishes credibility. An estimation factor is how long you think it will take you to perform a given task. When guessing this, most people forget to factor in phone calls, meetings, approval processes, and interdependencies.

My estimation factor is four. That means when I first determine a project will take me two weeks to accomplish -- which it would if I spent 100% of my time on it, with no interruptions -- I multiply that projected number by four, and guess what? I'm always on time.

To determine your estimation factor, you need to collect metrics over time based on your original estimates so you can compare them to the actual time when you deliver. This needs to be a process standard in your organization.

Rule 8: You Manage What You Measure

Measure only what you care about, and communicate that to everyone -- your direct employees, peers, and your own management -- so they understand and accept your priorities.

If you don't care about cost, then don't manage cost. If you don't care about schedule, then don't manage schedule. If you are not measuring it with a metric, then you are not managing it.

At Sun IT, we care about availability and quality. I know the availability and performance of every one of my systems and gather volumes of performance data on each. And when a system is slow, I am instantly paged so I can address the issue. I track those metrics all the time, and I manage my employees by them. So my employees know what their focus should be, and my peers and management understand my team's priorities.Rule 8: You Manage What You Measure

Measure only what you care about, and communicate that to everyone -- your direct employees, peers, and your own management -- so they understand and accept your priorities.

If you don't care about cost, then don't manage cost. If you don't care about schedule, then don't manage schedule. If you are not measuring it with a metric, then you are not managing it.

At Sun IT, we care about availability and quality. I know the availability and performance of every one of my systems and gather volumes of performance data on each. And when a system is slow, I am instantly paged so I can address the issue. I track those metrics all the time, and I manage my employees by them. So my employees know what their focus should be, and my peers and management understand my team's priorities.

Rule 9: Best is not Better

This rule addresses "analysis paralysis"; the tendency to over-analyze. By trying to implement the world's best system, you might analyze for three years, which means you won't gain benefits for at least that long.

If you follow rules one-through-eight, you won't make a bad decision. So decide what you want now and move forward. Be confident in your decision. Even if you want to add new technology later, if you base the system on open standards and separate your layers, it's easy to make changes.

Rule 10: Nothing in Life (or IT) is Easy

The last rule is tongue-in-cheek. Always assume the worst from a risk-management perspective. Remember: this is about setting expectations.

Assume that a system is going to production and the server hasn't arrived; your project lead is leaving for another company; and users will do all the things you don't think they'll do.

Don't plan too optimistically. Assume that these are the kinds of things that are going to happen, and because there are so many moving parts, something usually does happen. As an executive, you'll be prepared and will be able to lead any type of project effectively.

These are the top 10 rules by which I manage myself and my teams at Sun. I feel if you follow these 10 rules, you'll always be successful with technology.

Bill Vass, CIO of Sun Microsystems, joined Sun as an IT vice president four years ago. Prior to joining Sun, Vass provided CIO oversight for software systems in the Department of Defense (DoD), the Pentagon, and all infrastructure groups. Bill also acted as the DoD's CTO.