Some ideas pop up in every culture.
An old Islamic proverb advises you to “Trust in Allah, but tie your camel.” Former President Reagan translated the Russian version — “Trust but verify.”
And we chip-heads have extranets.
I gave my first speech about extranets to the Minnesota Telecommunications Association in 1993, not that I was smart enough to coin the term.
It was a simpleminded speech. The World Wide Web was just getting started, e-mail gateways were expensive and unreliable, and the office suite wars were still raging with no clear winner yet in sight. So I guessed wrong on many of the specifics. The key point was right, though. IT’s focus was typically internal — on WANs, which improved communications with ourselves, not on ways to improve communications with customers.
An extranet is a private network connection between two or more companies built around standard Internet technologies. I’ve recently moved from speechifying to setting one up, finding out first-hand that successful extranets have some tricky, trust-but-verify-related design issues. For example:
Security policy: Does yours describe the level of trust you assign to your customers’ employees? You can’t toss this problem over the transom to your security group either: Their job is to implement your security policy, not to create it.
Firewalls: You need one per company, of course, not a particularly sophisticated insight by itself. Each company needs to protect its network from its trusted partners. Don’t, by the way, economize by using the same firewall for your Internet and extranet connections. Each implements a different security policy. Internet users are total strangers. Presumably you trust extranet users more.
Authentication servers: If an extranet is a good idea for one customer it’s a good idea for lots of them. And once you’ve established an extranet connection to two customers, you’ve connected their networks to each other. They may even be competitors.
Authentication servers restrict the use of extranet connections to trusted individuals, protecting your customers from each other. A key point here: Your role is to encourage your customers to implement this technology. They each have to install and administer it. Otherwise you’ve taken ownership of their network security, along with the liability if something goes wrong.
In the Fun-You-Don’t-Need department, think about compatibility testing. Authentication servers require client software on every system that accesses the extranet. Different customers may choose different authentication servers.
Server ownership: In some cases this is a non-issue. What if you’re running a joint project, though? Like a lot of issues, this one’s easy to resolve if you remember it. One company or the other owns and administers the server and puts it inside their firewall.
Mobile users: This is the toughest design issue your network engineers face. When you’ve established a joint project team and a customer’s team comes to visit, you should be able to provide desks and network connections. They should be able to work without right-clicking on Network Neighborhood to reconfigure their IP settings.
Problem resolution: Don’t forget this one. Although every device on your extranet may be fully managed, the end-to-end connection is not. When something fails, nobody knows whose device is at fault. You’ll need reporting and escalation procedures. Probably, each company’s employees will call their own help desks. Instead of pointing fingers at each other, the help desks will work together to solve the problems.
And last but by no means least: Make sure everyone involved knows why you’re doing this. “Improving communications with our customers” sounds really great, but as Gertrude Stein said about Oakland, there’s no there there. If you think through the tangible benefits up front, everyone involved will know what they’re trying to accomplish.