“IT IMPACTS”

Before you answer that question, stop and think about your industry and the organization you work in.

You have to start with the definitions of failure and success. They can be slippery concepts. This can be especially dangerous if you and your boss have differing viewpoints on the concept. What constitutes failure in one organization may or may not be considered a failure in another. In fact, there are several innovative companies that are willing to let many projects fail in order to capitalize on the ones that actually succeed. Those projects are likely to be high risk to begin with. It’s important to understand the environment in which you work.

The definition of success and failure can vary within your organization, and differ based upon who you work for.

Many years ago, while working on a project, I announced to my boss that I needed one more week than planned in the project timeline to ready the software for testing. My boss was not happy. Shortly after this,  I received a phone call two levels higher in the organization wanting to know what was going on and what was this disaster.

After explaining, the result was, “Oh. I thought something was really wrong. That’s great news. A week? That’s great. Keep up the good work.”

It was clear that the two of them had very different ideas on success and failure. It painted a very clear picture to me that you had to understand what the expectations of those you work with and for.

Having been in and around numerous IT shops, one observation has been consistent: there is always friction between the Applications Development and Infrastructure/Operations groups. That friction can range from minor skirmishes to outright hostility, complete with drive-by shootings, stabbings, and open warfare.

The reasons for this are simple, but surprisingly, not always clear or obvious to the warring factions within IT. Applications Development make changes to the software environment. On the other hand, Operations/Infrastructure’s role is to ensure stability in the environment and to maximize application software availability, or uptime. The greatest threat to that stability is “change”. Therefore, by definition, these two groups have missions that are at odds with each other. When compounded by poor communication and/or lack of trust, things can easily escalate out of control.

One of my pet peeves has always been when the IT staff moves the front-lines of the battle to the business. One common example is when the Application Developers tell the business that a project will be late because of something Operations/Infrastructure did, or did not do.

When we do this, we really make IT look foolish. The business has every right to expect IT to work in harmony. Taking an example to a truly absurd level, it would be similar to Finance saying that a travel expense reimbursement could not be processed because the accountants handling the debits don’t work well with the accountants handling the credits. Ridiculous? Yes, but that’s the way IT sounds we finger-point within IT.

What’s to be done? Care enough to stop the finger-pointing, and find a way to work together. Take that first step. Take pride in where you work. Do you care about IT’s reputation? Who would not want to be proud of where they work?

While stopped at a traffic light today, I noticed something on a commercial pickup truck for a concrete company that you don’t often see: a telephone number without an area code. Using that very special analytical portion of my brain, I wondered why. It was an old truck. Was that an indication of how old the truck was? Or, a simple prediction of the company’s growth potential?

In the state where I live, there are six (6) area codes. How long will this last? Curious about the growth, I did a quick search and found a map on the Internet that showed that in 1947, the state only had one area code. We know that the proliferation of second lines, fax machines, and mobile phones have consumed phone numbers and area codes faster than anyone could have predicted 60 years ago. 

We face this kind of issue when designing any new system. The challenge is knowing how much growth to plan for. How much capacity do we tie up for future growth? I’m sure most of us know stories where software has limited, or stalled, business growth.

In a similar fashion, we are running out of IP device addresses. The current scheme (IPv4) is based on a 32-bit addressing scheme, which provides a maximum number of 2³², or 4,294,967,967,296 (since there are addresses reserved for special purposes, the practical number is actually less).

The solution is IPv6, which will require new devices, hardware replacements, downtime, money, outages, and a good time for all. However, IPv6 has its limit too. It is 2¹²⁸, which will allow us to put 5000 device addresses per square micrometer. Sounds like that might last a while, doesn’t it?

The question becomes, when will we use those up? What new technological innovation will blow that numbering scheme apart? How small can we make devices? Will we need to assign device addresses to microbes? Nanites? Something will happen. Time has shown us that over and over again. If nothing else, we will need another solution by the time intergalactic warp drives are in mass production. I know what you’re thinking now. You want to suggest that this is all myopic 3-dimensional thinking. You want to talk about multiple universes, multiple realities, and get into a theoretical argument about the 9-dimensional nature of the universe as a growth market and the severe technological limitations of IPv6. It didn’t take long. We need to start planning for what comes next.

IT professionals often fail to communicate effectively with their non-IT counterparts. As IT professionals, we need to talk about technology in terms that the non-IT person can understand. Several years ago, I watched a group of IT people make a business case for a productivity tool investment for the programmers in IT. The idea was good and the technology sound. It was clearly a cost-justified acquisition with a valid justification; however, the justification was a little too clever for its own good.

The proposal required the approval of the Senior Vice-President over IT. The Senior Vice-President was not a technologist. This group of IT people took their proposal to the Senior Vice-President and made the necessary presentation to obtain his approval. However, rather than saying it would increase programmer productivity by 25% and would pay for itself in a specified timeframe, they proudly informed him that it would add 56 virtual programmers to the staff.

The Senior Vice-President reflected on the proposal for a few moments before he asked the group one question.

“Where will all those new programmers sit?”

Surprised by the question, the IT group proceeded to remake the very same presentation, again concluding with the arrival of 56 brand-new virtual programmers. They collectively sat back, confident that this time the point had been successfully made. They only needed his signature to move forward.

The Senior Vice-President looked at them, shook his head, and said, “I understood all of that the first time. You still haven’t answered my question. Where will all these new people sit?”

The meeting ended without the desired approval. The Senior Vice-President was obviously puzzled why these people could not provide him with an answer to a basic and simple question. The IT people left thinking—well, I’m sure you can fill in the blanks. Where was the failure?

As that infamous line from the movie Cool Hand Luke relates, “What we have here is a failure to communicate.” The obvious moral to the story is to know your audience and talk to them in their terms, on some common ground, in language that they can understand. While the justification made perfect sense to the IT folk, it was not in appropriate terms for the decision maker. We run into the need for clear communication with the business in many of the things we do in IT. Don’t fall in love with technical cleverness. We must learn to speak to the business in the language of business.