No, this is not about bring your own device. That discussion about letting employees hook their own devices into the corporate network is getting old even before it is broadly adopted. Here's why that BYOD trend will be popular in companies: the bean counters have figured out that letting the employees bear the cost of their personal hardware equals more money for the company's bottom line. Nuff said, let's move on from that BYOD discussion.
No, I'm talking about BYOD as in build your own device. And this is a topic that engineers should embrace. The desire for companies to build the devices that run their infrastructure used to be restricted to proprietary widgets of limited appeal that did not have the volume required to interest the big manufacturers.
But that is changing. Consider:
The secret sauce for many of the big web companies is a mix of building their own data centers and building their own servers to sit in those data center racks. How strange does it get? Google is sufficiently paranoid about its server designs to run its operations in one shared center in the dark with engineers wearing those old miner like helmets and lights to make sure no competitor sneaks a peak at their secret box (or actually a board, no one puts their servers in a box anymore). The build it yourself data center has sufficiently spooked the big server vendors to force them to create their own divisions to try and compete with the in-house engineers.
On the other end of the spectrum are smart phones. Would a company actually build their own smartphone rather than buy a contract. Well, you wouldn't go build an iPhone but an Android based phone is a different story. I'm not crazy (at least about this). Boeing is building a secure version of an Android phone that uses security lessons learned from the government and, to my thinking, would be a welcome addition to the Android lineup.
And what about that middle ground between secret servers and secure smartphones? As my colleague over at InformationWeek recently wrote about the CIO at Union Pacific railroad which when they investigated buying or building communications radios they discovered the following as Rob Preston outlined, "For example, it was going to buy communications radios for its locomotives from a specialty manufacturer, but the engineers who work in UP's technology R&D lab said they could do the custom electronics for less. By developing the 8,000 radios it needed in-house and farming out their fabrication to a contract manufacturer, UP not only saved $7 million to $8 million, says CIO Lynden Tennison, but the subsequent sale of about 5,000 of those radios to a couple of competitors generated enough money to more than cover development costs."
So, there you go. Forget the bring your own device discussion—that one is already in the works—embrace the build your own device argument and see your star rise in your company. Eric Lundquist is vice present and editorial analyst for the InformationWeek Business Technology Network.
@weflynnJr: you got the Linux thing backwards. Here's what really happened: a bunch of software engineers found the off the shelf stuff wanting, and then realized that the owners of the shelf will prevent them from fixing it. So they created their own tools in a way that enables them to scratch their itches.
Your concern for TCO and opportunity cost is justified, but Linux has demonstrated that it stands on its own when used correctly and competently.
Sounds a lot like the Linux thing: A bunch of software engineers that wanted to ensure they had jobs convinced some bean counters it's better to use something like Linux because "it's free". But the long term support costs are pretty staggering compared to something that's off the shelf unless you already own 300 engineers that are under utilized.
This is just the hardware version of it. Somebody needs to look at the opportunuity cost of BYOD.
Join our online Radio Show on Friday 11th July starting at 2:00pm Eastern, when EETimes editor of all things fun and interesting, Max Maxfield, and embedded systems expert, Jack Ganssle, will debate as to just what is, and is not, and embedded system.