Archive for October, 2011
Outsourcing IT, call centers, component manufacturing and other business functions is now a way of life. A few simple rules can make the difference between great success and terrible failure.
Some outsourcing has gone well, finding suppliers who provide a quality component or service at a better price, or a better service level. Some outsourcing has gone terribly wrong, leading to loss of data, poor quality of service, or even counterfeit aerospace parts.
Outsourcing is not a panacea. Outsourcing is not easy. Outsourcing something can initially be more difficult than doing it yourself. Outsourcing does not always save money, or time.
One of the people I’ve worked for over the last eight years is a pretty smart guy. Under his leadership we have looked at outsourcing carefully selected IT and QA functions throughout most of that time. Some things have been successfully outsourced, some we’ve decided to keep in-house and we have some new projects where it is too soon to tell. So far, we haven’t had any of the outsourcing failures that seem to be so common.
That’s probably due to the care and careful consideration that he has imposed on all outsourcing decisions.
Here are the outsourcing rules under which we operate:
1. Strategic Benefit: The benefit must be strategically important to our company, so that outsourcing a function improves time to market for a product, avoids capital expenditure, or takes advantage of another company’s economy-of-scale.
2. Not a core competency: The function that is outsourced must not be a core competency for our company. For example, knowing how to manage a data center is a core competency, while actually performing the management with company staff is not a core competency.
3. Contract: Our company must understand the function to a level of detail sufficient to write a complete management contract that will survive the authors.
4. Relationship: There must be a compelling reason for the outsourcing vendor to be a strategic supplier to our company, based either on the size of the contract, partial ownership, market sector dominance, beneficial publicity, or technology leadership.
I’ve been interested in IPv6 for years. I actually wanted to play with it when I was at SDSC (1993-2003), but there was never time and the software support was too brittle.
Boy, have things changed. And for the better. Of course, my ISP doesn’t offer IPv6 connectivity; few do, and none in my area, at least for home service. I’m happy with my DSL connection, and the free static IP addresses that I have. Since I could practically throw a rock at the CO (I can see if from my house!), I have the theoretical maximum DSL speed available if I want it.
With no native IPv6 connectivity available, obviously a tunnel is the solution. I’ve spoken to the nice folks at Hurricane Electric over the past few months about GigE-level IPv6 connectivity for work, so I decided to give their tunnel server a try.
I completely configured an IPv6 tunnel from my home server and tested IPv6 connectivity on my home LAN and to the Internet tonight. In about 30 minutes. And a lot of that time was figuring out the new syntax of the Linux networking tools (route, netstat, etc.) for IPv6.
I was able to verify IPv6 connectivity via ping6, traceroute6 and even made some SSH connections on IPv6.
Next challenge: see the @#$(*& dancing turtle at www.kame.net on my MacBook Pro. There’s something truly odd about the IP stack here and it’ll take some time to sort that out.
And that’s a project for another evening.