Who's Your Data?

On Monday morning our engineer arrives onsite. Our engineer and the customer’s IT staff stake out their respective territories. I have not observed anyone rubbing their whiskers against a server cabinet, cat-like, but you get the idea. Measurements are being taken. Assessments are made. Does this so called out-of-town expert know what he is doing? Is the customer environment really ready for this project? Will the customer throw the SOW out the window now? What does the latest plane schedule look like?

Once territories are staked out the real work begins. If there are going to be problems they will surface now. The data management software that we install and configure can send massive amounts of data through the network at high speed. Most of the customer’s day-to-day infrastructure traffic (messaging and application) flows at intervals with predictable peaks and valleys. Software that is designed to store data or backup and restore data can be intrusive. I have seen Network Admin’s used to predictable data flows freak out (we used to say that in the 70’s) when they observe the non-stop traffic patterns of the best data management software. We created separate networks like SAN’s to deal with these data demands. SAN technology is mature, but if not implemented properly it won’t meet expectations.

Because it is more fun to talk about our problems, let’s assume the project is experiencing “technical difficulties”. That is a euphemism for “there is something wrong with your network”. We are trained to deal with these problems. We can often figure them out, but it takes time. This is when a project can fall behind schedule. Now it is Wednesday late morning. Everyone is on a first name basis. You are Bill and Sandy; we are Jim (always Jim). Lunch is suggested. The latest trend in engineering is Sushi or the company cafeteria. At lunch, credentials are exchanged. Guards are let down. Comments are made.

Weeks later I get a phone call from the CIO. “You know, Bill and Sandy had lunch with Jim while he was on the project. They really hit it off”. I am dreading this already. “Jim told Bill and Sandy that we should have bought the XYZ option not the XYZ option we purchased. And he said that he had never actually configured the software in a multi-terabyte environment on Windows Server 2003 SP7 (released while we were onsite) with a Do-Hickey storage array tuned to warp speed and the current patch level. What gives? I thought you said your engineers knew what they were doing?”

“Did they by any chance have lunch on Wednesday?”, I ask. The lesson that I have learned from all of this is that the earlier we are involved in the design process, the better projects go. If we can do the full blown data management design, great. If we can at least review the architecture before the XYZ option is purchased, that helps.

So, over the years during the new-hire orientation with many engineers, I have developed possibly my single best piece of advice. Have lunch with the customer on Thursday.