Tuesday, August 23, 2011

Ignoring Good Ideas

If you've read the previous articles you might think that I would say that we should do every good Idea that comes our way and talking to the base of techs you employ is the best source of ideas. It's not to far off but I do not believe every good idea is one you should do.

In any given IT department there are tons of good ideas floating all over the place, to fix this, or change the way we do that. I doubt there is a single tech in your department worth his/her salt that doesn't have a half dozen good ideas sitting in there pocket. So why not just start implementing all these great ideas?

Well that's when good ideas start to break down, implementation. In many cases a good idea would take hundreds of man hours to implement and only net you a 5% gain over what you have right now. To the tech responsible the idea is very critical and will dramatically improve whatever they are responsible for. But in the grand scheme of managing the enterprise, chances are it will have very little to no impact. These ideas are generally only worth it if they are easy to implement, or are core services like Active Directory that lots of other services key off of. 5% gain in AD means 5% in SCCM, in Exchange, etc.

The other trouble is that many many good ideas are great, but take you down the wrong path for your overall IT vision. Well first you have to have an IT vision (Something Third Rail Inc lacks in a big way right now, examples to come), those departments that lack it wont be able to tell the difference between a good idea, and a "bad" good idea. Your IT department will be pulled to pieces with nothing but good ideas if you have no overreaching direction to follow.


Example Problem
We have a licensing problem in our IT department, we seem to be un-able to track what's installed where. So we had a fairly good idea which is to enhance are already existing Network Operations Web Site to track licensing. They've gone to the trouble of figuring out what information they need and have half an idea of how to get the information off the machines, and even a splash of how to track the licenses over time. Sounds like a good idea, sounds like something someone has put some thought into. The problem is the whole system is built on top of in-accurate information.

Running inventories on systems to find out whats install is a great way to find out how many licenses of a particular application you have installed. But at Third Rail our machines are splattered all over the US, and many many systems do not regularly report into the network. To deal with this in our client management solution and in AD we just say that machines that have been offline for more than 60 days get deleted automatically. Then if they check back in down the road we re-add them. Works ok as long as you don't care to much about licensing, or knowing how many machines you have.

But it gets worse machines can be reimaged at 7 different locations around the US and the techs doing the reimages don't necessarily report to the main IT group. In many cases we will get machines reimaged or replaced with no notification to us that they have been. If a machine was re-imaged and all licensed software reinstalled under our current system the old enteries for the system would stay for 60 days, forcing us to account for 2 licenses of each item installed for those 60 days, because we have no system for knowing it was a re-image vs a new machine. For one machine not such a big deal, when your overall IT averages 30 re-images a week that's a 264 machine churn rate for the 60 day period, or a lot of extra licenses we may not need.

But again it gets worse, we have a ton of remote users. Many of these remote users do not regularly connect to the VPN or come into the office. So even though they fall out of our systems we should be tracking and holding licenses for there machines.

Over the whole we have an average churn rate of 200 machines per month that either come on or off the network, and have no way of knowing which ones are just returning, which ones are re-images, and which ones are new machines. And this is the system you want to build your licensing system on top of.

So while a licensing system in and of itself is a good idea, and the particular system they want to implement is pretty decent. It's a bad idea to spend hundreds of man hours implementing without first addressing the underlying issue of not having good life cycle management and asset tracking of our machines.

Tuesday, August 9, 2011

Building a Better Enterprise takes Talent

Under using a technology should be a criminal act. Yet I see us at Third Rail commit to it every day. Some technologies are free and extremely useful to the population. For example indexed searching on Windows servers is pretty straight forward to implement, and can greatly help users find what there looking for on file shares. But more criminal acts such as failing to use software we've purchased seems much worse. Pay 100k a year for an asset management and licensing tool, and then just don't use it. Then pay various software vendors millions for having hundreds of licenses installed that we failed to purchase.

These are examples of having the tools but not taking advantage of them. Part of the reason these things don't get done is that it can become difficult to even know whats out there. What do we own exactly and what do those tools do, and what tools are available to us for free and we just need to implement them. But just knowing what tools you have doesn't mean you know how to implement them. This is where talent comes in; people who can pickup a new technology and turn it into a true enterprise class production solution are few and far between.

If your lucky enough to have one of these guys, pay them well because they will keep your enterprise lean and efficient if you let them. Someone who can take a set of tools and put them together and build a service, then train up other techs on how to use them, and implement the business processes to make the service useful. This might be two people in your organization depending on the techs you have; one business oriented tech and one introvert super tech.