Jun 16, 2016Silicon Valley stalwart Tom Siebel has spent four decades developing enterprise software, beginning as an early executive at Oracle and later founding CRM software company Siebel Systems, which Oracle acquired in 2006. In 2009, he launched C3 Energy in order to help utility companies and grid operators better manage data and systems as they transition to smart grid technology. As such, C3 Energy was an Internet of Things company before such a term was in wide use.
Earlier this year, with nearly two dozen clients under its belt, C3 Energy relaunched itself as C3 IoT. While its core software platform remains largely the same, C3 IoT has a much wider purview, serving oil and gas, manufacturing, transportation, financial services and other industries.
IOT Journal spoke with Siebel about his company, how the IoT is evolving across all value chains and why heart attacks are really just another problem that can be solved with predictive maintenance.
IOT Journal: Earlier this year, C3 Energy became C3 IoT, in a bid to expand into new industries. Can you explain why you decided to broaden your scope?
Tom Siebel: From 2006 to 2008, I spent a lot of time thinking about energy, mostly from a philanthropic perspective. In 2006, there was a lot of discussion about peak oil, suggesting that our energy reserves would be rapidly depleted.
[When starting C3 Energy in 2009,] we took a close look at the value chain associated with energy. The electrical grid is a very large, complex machine—perhaps the most complex machine ever built. And it is going through an upgrade—all of the devices in the grid's value chain are becoming sensors so that they are remotely machine-addressable.
We spent seven years developing the C3 Energy platform; we spent a couple hundred million dollars building a platform to allow grid operators to build large-scale IoT applications for the smart grid. What has already been spent on the grid's value chain, this decade, is around $2 trillion, and it's one of the first value chains to be sensored. But all value chains are being sensored—health care, automotive, home, retail. The sensors are going everywhere.
What we've built is a general-purpose platform that can be applied to any value chain. So now [after re-positioning from C3 Energy to C3 IoT], we're using our platform to build predictive maintenance applications for APU [auxiliary power units] for Boeing 787s, for example. We're using it to build the next generation of CRM applications for cell phone manufacturers. One of the killer apps of IoT is predictive maintenance—even in health care, because if you're able to tell someone they're going to have a heart attack, then that is predictive maintenance.
You can think about C3 as a development environment for organizations to build applications, most frequently on Amazon Cloud, but it works on other clouds. It allows them to aggregate the data from the value chain, and then design, develop, provision and deploy very large-scale IoT applications that might have petabyte-size data sets and giga-scale sensor networks, which need to process millions of transactions a second. Take, for example fraud detection.
That is not unique to utilities—it applies to health care, telecommunications and other industries... Predictive maintenance applies to pretty much everything, whether it's tractors or aircraft or the human body. Our software enables companies to take these [sensor] devices that are out there and do something useful with the information.
IOT Journal: C3's marketing materials say existing IoT enterprise applications are attempts to develop a solution from "the many independent software components that are collectively known as the open-source Apache Hadoop stack," but that this does not a platform make. So, then, how does C3 IoT's approach to platform-building differ?
Siebel: If you look at the Apache Hadoop foundation, it's a good thing. But think of it like a flea market in the cloud, where independent software developers of various levels of professionalism and experience have built pieces of software that do something interesting and uploaded them to the cloud, and [have] said anyone can use these. There are literally hundreds of these products.
And virtually every alternative to C3 IoT in the market is someone who is taking an open-source Hadoop stack and trying to cobble together 100 products into something that works. This would include Pivotal, a division of EMC, which has spent $3 billion in the last three years trying to cobble these components into something that works. GE Digital has spent $4 billion building Predix, trying to cobble together this same [type of] stack.
I don't mean to suggest there are not useful products in the Apache stack—there are. But the idea that you can cobble them together to solve IoT doesn't seem to be working. So rather than trying to cobble these things together, we spent seven years, invested a couple hundred million dollars, wrote a million lines of Java code and built a unified seamless, cohesive platform.
IOT Journal: Sensors conform to a long and growing list of communication protocols. IBM has been a big backer of long-range, low-power local area networks through its development of the LoRa protocol. Sigfox has a similar but proprietary protocol. The cellular industry is developing its own approach (Narrowband LTE). From your perspective in the software business, does having so many protocols make it more difficult to do your job?
Siebel: I don't think device development is a constraint. At the industrial level, we have the best and brightest minds in the world working on smaller, faster, cheaper sensors. So who cares who wins? I don't care—but, then, I don't really have a dog in the fight. Ten years from now, how many sensors will we have embedded in our bodies, or how many will we be wearing? Probably 10 or 12. Sensors will track pulse rate, blood glucose, the plaque in our arteries. So, this is happening and it's fun to watch.
IOT Journal: But is data translation a difficult task, if you're pulling data in from huge networks of heterogeneous sensors?
Siebel: Yes, and we've given a lot of thought to handling communication protocols from unique, disparate devices and aggregating them. We do it today, so I don't think it's a difficult problem. When there's a new communications protocol, we just need someone to publish it and let us know what it is.