Sunday, January 23, 2011

Knowing What You Don't Know

We are involved in a project for a large software development company. It's all under NDA, so I can't give too many specifics. But, basically, they want to release a new product and they need a few "real world" installation stories.

Easy peasy nice and easy.

Our first two clients were very different. And the difference highlights one of my favorite paradigms for understanding the world at large:

Know what you know;
Know what you don't know.


All too often, we "think" we know something, but the thing we think we know is not true. Is such a case, we don't know what we don't know.

As professionals, we all have specialized knowledge that others don't have. You've probably said to yourself at some point that you don't expect clients to know about . . . [TCP/IP; mini-drivers; patch management; memory leaks; web development; etc.].

I don't know which needle the nurse should use. I don't know insurance policy is best. I don't know the difference between two legal phrases that sound identical to me. Those are specialized knowledge of the people in those fields. When I hire someone to take care of my "stuff" I need to know the line between what I know and what I don't know.

Well, some clients know what they know and some clients don't know what they don't know.

In the world of small business, there are a lot of people who don't know what they don't know. They hobble together Frankenstein Networks that "work" but they have no idea how inefficient or dangerous they are. Let me explain.

Premise:
We're working with a technology from "Major Software" vendor. We'll just use the initials MS.
The product in question is a version of their Super Big Software package. We'll call it SBS.
One of the features of this Super Big Software package is that it wants to be the only Super Big Software package on the network. Otherwise, trouble ensues.


Client One: Knows What They Know

Client One brings us in and we see that they have eleven workstations plus a 12th machine just to show videos and PPTs in the conference room. Cool. There is an SBS device on the network, but it is only used for storage. Literally, it is used as a NAS device.

Workstations are all in a workgroup, which makes them a pain in the butt to manage.

We are going to drop in a new SBS Device, scoop over the data, and then begin attaching the workstations to the new network. They will move from a workgroup to an Active Directory structure. Everyone will lose their profiles.

Client knows this. Client knows the old machine has to go away. Client knows the difference between workgroup and domain. Client knows that profiles will be replaced by plain vanilla. That's the deal.

Client has a line of business application that might not make it into the 64-bit twenty-first century. He has moved this to a workstation and we need to make sure the data are backed up to the server.

Client knows all this. Client knows what they know. When we start discussing cooler new backup strategies, client fully admits that this is new to him. He knows what he doesn't know.

This client will save a LOT of money, hassles, and downtime because he has an honest assessment of his own knowledge about his network.

All good.


Client Two: Doesn't Know What He Doesn't Know

Client two tells MS that he has three computers, no server. No special needs. Plain and boring. Easy install. No real requirements.

Uhhh . . . So we do our network audit. Client Two owns two companies. They are separated by a wooden door. Company Three has three PCs, one laptop, and a an SBS device connected into a 10/100 switch, which he happily calls a Hub. They also have some network printers.

One line from the switch goes into the back of the firewall owned by Client Two. Client Two has plugged a series of 8" home made network cables from the back of the firewall into his patch panel. These connect three PCs, one laptop, and two specialty workstations that are only used for watching streamed Netflix. They also have some network printers.

The two offices must share network printers.

Client Two has no idea that the firewall is working overtime to manage traffic for four machines, two printers, the entire office next door AND two machines streaming video. All local and internet traffic goes through the switch on the back of the firewall. I don't know if it's just 10 MB or 10/100. I don't care.

When I sit down at Client Two's PC and run IPConfig/all I see that DNS, DHCP, and Gateway are all the same address. Cool. I also see a WINS server at a different address. I open a web page and VOILA! I see the SBS device.

At this point we explain that the two networks are joined, there is no security, and the old SBS machine is going to shut down 30 days after we set up the new office. Dude thinks we're trying to rip him off for the cost of a router to separate the two networks. (Cuz, you know, I'm going to totally retire on the profit from one cheap router.)

He explains to us that the two offices are completely separated in every way.

He does not know what he does not know.

Stop.

Let me reiterate: I don't expect clients to know what they don't know. But if they want to save money and increase uptime, I really need them to be open to accepting the line between what they know and what they don't know.

The problem is NOT that the client is not a network engineer. I don't expect him to be. The problem is that the client honestly thinks he totally understands his network AND therefore thinks that our recommendations are intended to screw him out of his hard-earned money.

He doesn't know what he doesn't know AND he's not willing to admit the limits of what he doesn't know.

We want to put Client Two's office on a nice, separate switch so that they have 1GB bandwidth internally for their medical imaging systems. It's a cheap and easy way to make things go VERY fast.

We want to install a low-end router between the two companies so the SBS machines can't see each other. We can still map printers because we know what we're doing. Again, cheap, easy, and allows them to keep their other server.


In the end, this whole adventure is generated by MS's need to understand what happens if you sell this product OEM at places like Best Buy and let Joe Average install it in his network. What can go wrong? It works perfectly in the lab. But the lab is clean and simple to understand.

The clients who will have installation disasters are the clients who don't know what they don't know. They think they meet the basic requirements, but they don't even know how screwed up their network is because it "works" for them. It might barely work. But it works. They don't know that for less than $500 they could make it screaming fast and secure. It works.

Too bad the MS SBS software can't detect that wooden door that separates the two companies.

:-)




Now Available:
Introduction to Zero Downtime Migrations
Seminar on MP3 Download



2 comments:

  1. You and I must share the same two clients :0

    ReplyDelete
  2. Great way to illustrate your point, Karl. I think I am really excited to learn someday who the Major Software company is and what their Super Big Software package might be all about. Sounds like something I might be able to sell to my clients one day if I'm lucky. LOL.

    ReplyDelete

Feedback Welcome

Please note, however, that spam will be deleted, as will abusive posts.

Disagreements welcome!