IT Operations: The Reasons Why You Don’t Want To Be Unique

  • Article

Written by Kip Ng, Principal Microsoft Premier Field Engineer

IT Operations: The Case For Why You Don’t Want To Be Unique In today’s world, we are brought up in a society where we are taught to be first, to be different and to be competitive. We are frequently being urged to be unique in order to stand out among the crowd.

There is no doubt that an element of uniqueness is essential in many different areas and there are many reasons why being unique can be beneficial.  The question I have today is that from the IT operations and IT architecture stand point, is it good to be unique? In my humble opinion, it’s a big no-no. In fact, I even think it is bad juju to be unique.

In fact, time and time again, I come across customers of various sizes, from various industries and various regions proudly showing me their infrastructure and their design, and boasting about how their infrastructure and architecture needs to be different because of their special business requirements. Many have even boasted about their ingenious ideas on how they have tweaked a product to do things that the product was not designed to do.

Some have definitely taken products like Microsoft Active Directory and Microsoft Exchange and fully embraced the Star Trek tagline of going beyond the final frontier. They’re proud that their architecture is unique and you know what, I am glad for them, but probably not so much for the company. Don’t get me wrong, I am not saying that they are doing anything bad, they are just doing what they need to do.

However, here’s why I think being unique is not a good thing in IT:

  1. Being unique in IT means you are the guinea pig. You really don’t want your IT environment and infrastructure to be so one-of-the-kind (i.e. unique in this world), because if it is:       Guinea Pig
    • You may face problems that no one else in the world has and the problems may take much longer to get resolved. Your vendor has probably never tested your scenario, and their support engineers may not have the experience with (or knowledge of) the behavior of your unique design and they most likely have no environment to reproduce the issue if needed.
    • You may face problems where vendor will not fix the issue because you are the only one in the world doing it that way and hence they can’t justify mobilizing the resources to fix it.
    • You may face problems where your vendor is forced to issue you a support statement rendering your design as unsupported because they never designed the product to behave in that way. When a vendor upgrades their product, they may also break your uniquely customized design.
  2. Being unique in IT has no glory in it. I know we like to be proud of what we are doing, but the truth is there is really no glory to be unique in IT. You are only creating more work, and more problems for your operations staff. So, why do it?  We run IT because it is meant to enable the business; no one with any business acumen really cares about the environment being unique. The truth is as long as it has no problem and it helps the growth of the business, that’s what we need.
  3. Being unique in IT makes recruitment more difficult and lengthens time-to-effectiveness. When an environment is unique, it takes a longer time for someone new to get familiarized with it. Augmenting or finding replacement staff also becomes more difficult and time consuming.

Of course, there are many other reasons why I think you should consider not being unique when you are designing your new systems. Your best bet is to find out if other organizations are deploying the products that you’re about to deploy, and chances are they will be more than willing to share their experiences with you.