I went to Vegas and didn’t gamble a dime

  by Charles Rattray | 15 Oct 2008 | Permalink |

I went to Vegas and didn’t gamble a dime!

It’s true, and probably says a lot about the missing links between the parts of my brain which control fun, and the parts that deal with risk. To rectify this I probably need to go through an intensive set of applied behavioral analysis sessions to reset the neural links in my brain – resetting the patterns which associate fun with gambling. Of course, identifying patterns is something which is very important in Vegas – and the Retail world for that matter. A famous US economist once quipped that there are 3 rules in physics which describe 99% of the behavior of inanimate objects while there are 99 rules in business which describe only 3% of buyer behavior.

Walk into any bookstore – Barnes & Noble, Borders, Waterstones, etc and we find many business books which either attempt to identify the patterns in buyer behavior or attempt to reset our patterns of behavior. Much of the advice makes sense, or at least we can see how the conclusions on particular scenarios were reached by the authors. Unfortunately, and the reason why I found it so easy to resist blowing a few dollars in Vegas, change requires effort, and as one of those 3 laws of physics tell us, change doesn’t happen without an equal and opposite force.

Las Vegas airport is an amusing place. It has slot machines. It also has a continuous set of people arriving intent on beating the system and ‘winning big’. As the gambling newbies arrive, they file past the current crop of losers – both groups thinking about how to spot winning patterns – much the same, I imagine, as traders on Wall Street. So patterns are everywhere. We can’t escape them. They even exist in IT – in the systems we deploy, and the way we manage those systems.

The problem with patterns is that they are sometimes difficult to spot. How hard can it be to count 52 cards – quite hard apparently? We know patterns exist, but it takes effort to collect the data and keep track of it. Now, here is a good bet. When a data center manager or an application owner bets you s/he knows how many servers they have, take the bet – they won’t get it right – unless of course their data center is the size of a cupboard, and even then virtualization can throw them a joker.

Once we wake up to reality and realize that we don’t know what is in our data centers it’s easier to understand how we can make mistakes on cost and risk when it comes to managing IT. If we miss a count of just one card in a 52 card deck our game is lost. Likewise, if we forget to include just one system in a data center move, or a patch rollout, or a software license count, the consequences can be expensive.

Enter stage left, auto-discovery and application dependency mapping. Our counting is done for us, the pattern identification and mapping is taken care of. All we have to do is think about what we can do with the information at our fingertips, and last time I checked, thinking didn’t require as much effort as resisting change. Except, digesting the new information may require effort, and it’s a bit like going on a diet – nice in principle, but we always resort back to what we feel comfortable with.

That’s why applied behavioral analysis is so important. If we take new information, now readily available through our auto-discovery and application dependency mapping system, and we are given actual examples of how that data is useful for us and how we benefit from it – ok, so you should be thinking about paid TV advertisements for abdominal exercisers at this point – the actual act of physically experiencing something new helps to embed the change and its benefits into our current set of beliefs.

Tideway’s Configipedia website (http://www.tideway.com/configipedia/Main_Page) does just that. Via these webpages we show our customers how to use the data that Tideway Foundation collects, and demonstrate just how easy it is to benefit from it in their own IT environments. Some of our existing and prospective customers have been learning about how to establish a baseline of policies around Standard Operating Environment (SOE); how to gather license intelligence for a forthcoming Oracle Audit; how to set up a Change Intelligence monitor on critical JAR files underpinning J2EE apps; and so on. During subsequent blogs, I propose to explore some of these areas in detail, and sharing our recipes for success.

In the meantime, and getting back to Vegas, I feel confident that if someone were to send me just a few dollars, I’d be able to practice gambling sufficiently to see the patterns and begin experiencing gambling as a fun activity…..