Who's Your Data?

OK. This really torks me off. Normally I am a very calm and reasonable person, open to many viewpoints and ideas. A colleague whom I shall call “Ben” (his real name) was preparing a presentation for a military/intel customer regarding open systems and open source software. He was going to talk about Linux and insisted throughout our conversation on calling it “Lye-nix”. When I called him on his pronunciation he informed me that the matter was “in dispute”.

No it isn’t. The founder, creator, birther(?) of Linux, Linus Torvalds, says that it is pronounced Linn-ucks (it rhymes with cynics). And don’t give me any of that Finnish “lean-ucks” crap. This is America.

While we are on the general topic of how not to sound like you know what you are talking about, I want to warn you about “SAN’s”. I am going to break one of my steadfast blogging rules. I am going to tell you what “SAN’s” stands for. This blogging rule is called The Britney Spears Rule. The rule states that if you are reading this blog it is assumed that you are a serious technology person. If you are not, you should only surf websites that discuss Britney’s enormous problems.

A SAN is a Storage Area Network, emphasis on the word, network. It is a network that you can use to attach storage devices. It is not the box sitting in the corner of your server room. That is a disk array. You need a switch (could be in the box) connectivity between servers and storage devices (HBA’s, cables, etc.) and enabling software. That is a SAN.

There is additional confusion about fiber and fibre channel in the data center (and diet). Again, this is America, not the Commonwealth. Fiber in the data center is fiber-optic cable. Fibre channel is a data transfer technology often used in SAN’s.

Why are these distinctions important? Number one, it torks me off if you get it wrong. Number two, it would be embarrassing if you received a package with 10 kilometers of fiber-optic cable when you were expecting a fibre channel switch. And it is common courtesy to get it right. It would be like making a PowerPoint presentation to a Red Hat executive. They know all about Redmond. They want your help in promoting open source applications. Take the time to do it right. There. I am Finnished.

Posted by Matt Hamilton at 09:13 AM | | Permalink | Comments (0)

I walked into an office supply store in an old part of town last week. The store had some of the neatest journals I had seen in years with beautiful inlaid covers. I love to write so I picked up a few. In one dusty corner of the store the owner had sorted and labeled a few hundred assorted typewriter ribbons.

It got me to thinking about how we view technology and the ups and downs of the market. Here is a simple question, which is more important to an Executive…there, phony baloney job (and stock price) or the purchase of additional technology to meet the ever growing corporate demand for application availability?

It’s a pretty stupid question, but one I heard serious people debate just before the Tech Wreck in 2000.

A friend of mine had received founders stock in 1995 from a major tech firm whose name would be instantly recognizable, so I can’t mention it. He had watched the value of his stock climb from $50k to $500k. He was contemplating early retirement. In 1998 I suggested he begin to diversify his portfolio. I felt the stock price was about to go down.

My very astute friend told me that his stock would never go down in price, because, “the demand for technology would continue to grow for the next ten years”. Oh my goodness. I fainted on the spot. When I came to I told my good friend that he was an idiot. I said that if the stockholders of corporate America (you and me) saw our investments begin to lose value and CEO’s started getting sacked, demand for technology would mysteriously go down…quickly. Well, this story does not have a happy ending. My friend lost his entire investment.

I knew the stock price would go down because of something my father had told me years ago during the run up of energy prices in the early 1980’s. In 1982 oil was over $30 a barrel. My father was in the energy bidness. Everybody was flying to lunch in their helio-copters and tipping $100 for a $50 meal. I asked him if the price of oil would just continue to rise “for the next ten years”. He laughed. A scornful laugh. “Everything goes up in value and everything goes down in value”, he opined.

How many times do we have to get smacked across the head with this simple truth to realize the implications? And yet, I read articles everyday where some expert states unequivocally that there pet technology is bullet proof. Now, I don’t want to get all Milton Friedman on you, but these up and down cycles are a good thing! Just think what the inflation rate would look like if prices just went up. We are talkin’ serious Weimer Republic circa 1930!

There are of course some exceptions to this rule. I just bought a very promising stock. It was a big investment, but I am not worried. This is my retirement ticket. It’s some video technology that I don’t really understand. I guess it used to be around a few years ago in a cruder form. It’s called “betamax”. Interested?

Posted by Matt Hamilton at 11:25 AM | | Permalink | Comments (0)

One of our engineers was at a customer site recently. He observed a young engineer who worked for the customer “monitoring” the network on one screen while he played Warhammer: Mark of Chaos on a second monitor (it was 2 in the morning, give the guy a break).

Engineers who are into online gaming (97.3%) have developed their own language to communicate complex ideas and exclude outsiders. Outsiders include management, salespeople, most colleagues, the bus driver, Mom and Dad, the barista at the local coffee shop and at times, even themselves. When an engineer wants something new for the data center this presents a slight problem. It’s called communication. Many engineers do not know how to communicate unless it is in Vulcan. Hence the problem.

When it comes time to request a new piece of hardware for the Data Center the engineer has a limited bag of tricks.

Approach 1.0 is to obfuscate. “The system requires dual HBA’s in order to maintain optimal transfer speed and maximize the caching capability of the application”. Purchase request rejected.

Approach 2.0 is the creative lie. “If you don’t do this, your e-mail will disappear in the middle of the day and you will burn in hell”. Rejected again.

Approach 3.0 is the desperate Hail-Mary in honor of Gene Roddenberry. The engineer says, “I'poprah fasei setebihk t'ovsotuhl-ozhika”.* unless the boss says, “Isha nash-veh Vuhlkansu - pontal na'sochya”, ** he is screwed.

There is approach 3.5 that combines the essence of the Vulcan and Romulan races (horrors! can there be such a thing!). It’s called, collaboration for mutual interest. In this approach the data center engineer works with the business types to build a case for the purchase. This means delving into yucky things like return-on-investment and staying away from discussions about how many cooling fans you need to keep the server at ambient temperature. Many of our customers have had good luck with this approach and successfully built out their data centers. Live long and prosper.

*Now-receive this-here symbol of-total-logic
**I too am a Vulcan, bred to peace

Posted by Matt Hamilton at 11:10 AM | | Permalink | Comments (0)

Saturday night I was enjoying a glass of wine with my wife during intermission at one of those big Broadway musical revivals. A former colleague and customer, whom I had not seen in eight years walked up. We will call him “Dave” (his real name). “Dave” and I had worked on a $50 million Y2K upgrade for a Fortune 500 company.

You remember Y2K. That was the event that led to the entire collapse of the worldwide banking system and the loss of every significant electric power grid in the Eastern United States at exactly 12:01 a.m. on January 1, 2000. Apparently one lone System Engineer in South Dakota at a small regional bank branch forgot to expand his date fields. Worldwide chaos ensued. Remember that?

Fortunately, our Y2K project had gone smoothly and was off the grid. While we waited for the curtain to come back up “Dave” told me about a not so successful software project at a large federal government agency. The agency had attempted to upgrade a major application. Many millions of dollars later the agency abandoned the upgrade. People were fired, system integrators were disintegrated and vendors were hung out to dry.

I asked “Dave” what had happened. He said it was management. Too many change requests combined with unrealistic expectations. I was certain that management would have a different view. In a make-believe survey I took, 7 out of 10 fictitious Executive types (this is a blog not a doctoral thesis) blamed their project failures on…something else. The salesperson lied, the contractor sucked, the software was junk and the dog ate the installation manual.

“Dave’s” view was that all of the above had gone wrong. My list of top reasons for project failure would normally not include the software. I am pretty sure that people make things go right or screw things up. If the salesperson tells you that the new release of software includes a feature that temporarily suspends gravity, who’s the idiot? If a major software upgrade goes south (or north or east or west) start at the top, but don’t stop there. What was management’s direction at the beginning of the project? Did they include everyone in the process? Was the schedule realistic? Did everyone play nice?

When a project goes wrong there will be plenty of blame to go around…something with music, something with laughter, something for everyone, a comedy tonight.

Posted by Matt Hamilton at 08:57 AM | | Permalink | Comments (0)