“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.