TAKING THE PLUNGE

OEMS EMBRACE SOFTWARE

Note to OEMs venturing into software: Those millions of lines of code are a whole different animal. They’re not a physical good like the things you know and build. They’re also not easy to create, price, sell, or support, and you’d better not confuse them with your existing business.

COURAGE, PILGRIM

People always confuse risk-intolerance with being backward or “being behind,” but in some cases it might just come from not wanting to die. Take a walk down to the Software Tar Sands and look at the petrified limbs of the manufacturing giants sticking up in the air, and you’ll know what we mean.

All software is virtual reality. The “virtual” part is that it’s nothing but lines of code that somebody typed into a text editor. The “reality” part is that when those lines of code are fed into a microchip, tiny voltages appear or disappear, and based on those voltages airplanes fly or fall, cars stop on command or race out of control. If you build airplanes or cars, those heart-sinking facts might make you never want to touch software again.

But history went another way. Software is now in everything. It’s indisputably eating the traditional profits and revenue models across many industries, including transportation and shipping, oil and gas, energy and mining. Hardware OEMs literally have no choice but to embrace the creation of code. The questions are: How, where, and to what ends?

Manufacturing companies have actually dealt with software for a long time. But their expertise has always been in hard-coded, purpose-built software embedded in their machines. You needed it to make the hardware work, so OEMs bundled the firmware, or the configuration program, or the driver software with their physical product and didn’t even charge money for it. They’d grown up in an environment that was all about physical control, and they remained challenged by data acquisition, value, and analytics.

Meanwhile, the end customers were waking up to the new value represented by networked hardware and applications. Engineers and developers wanted to serve them, but they were trapped inside the traditional industrial software model. Therefore, machine-data was left trapped in silos, there was no larger context for operations, and devices were created to be tied to simple applications.

This left the manufacturers open to disruption from multiple directions. On one side, it was the big IT infrastructure players like Microsoft, Google, and AWS. On the other side, it was their own customers, who were now saying, “We can’t work with you because you’re not providing technologies that allow us to use data to create new applications and services.”

Since they didn’t know how to develop software on their own, the OEMs responded by acquiring other firms. But when hardware players buy software companies, they need to keep them close enough to get synergy, but not so close that they strangle the business. Unfortunately, expecting OEMs to keep their hands off businesses that they didn’t grasp culturally was too much to expect. And now today the manufacturers are realizing that they poisoned the water by not understanding the companies they bought, or the software business in general.

SOFTWARE & HARDWARE ARE DIFFERENT ANIMALS

The economics, design and development protocols, financial treatment, and scorekeeping are all diametrically different in software development versus hardware manufacturing.

For physical equipment and machines, the product is paid for once and has to work from the moment it’s installed in the customers’ operating environment. Both the manufacturer and the customer know what to expect from the product and its performance—from its dimensions and weight to its reliability/MTBF, throughput, servicing, and so on. In software, users and customers pay on a monthly or similar basis for a continuing stream of new features, upgrades, patches and improvements, but with less predictable product performance parameters such as easier workflows, app integrations, self-configuration, automatic updates, faster onboarding, etcetera.

For manufactured equipment and systems, the product’s margin is the primary measure of its profitability. But in software, product margins make no sense as a performance measure, and applying traditional hardware cost-reduction lessons to software is incoherent. Hardware pricing starts with cost-of-goods and manufacturing costs, and then OEMs add their target margin and adjust for competition or market conditions. Software costs, when compared to equipment and machines, are far more intangible and far more about finding and keeping the best developers rather than finding the cheapest components.

For manufactured equipment and machines, the design and engineering/development cycle is, of necessity, distinct and separate from the manufacturing cycle. In software, design and development are completely integrated. OEM leadership is quite accustomed to driving out costs and improving the performance of their machines and equipment. That is completely orthogonal to the software business.

OEMs tend to give software away as an incentive to the customer to buy their machine or to protect their pricing of the equipment, and they treat incremental software value as hardware value in their accounting systems which turns the software business into a cost center. This in turn makes it even harder to justify hiring more software resources because the ROI does not work.

In the software business, software is distinctly charged for and it’s assigned a real value in the accounting system so it can be treated fairly when it comes to investments. Giving software away for free devalues it for the OEM as well as for the customer, and forces most OEMs to view software as an expense, not as a distinct strategic value.

BRITTLE SPAGHETTI & A CLASH OF CULTURES

Because code is nothing more than typing on a screen, it’s easy to change, and so it’s changed frequently, often with no master plan in place. The cost of rewriting an entire code-base from scratch is prohibitive, so revisions and new features are layered on top of existing code that may be years old. The result is “spaghetti code,” but that metaphor clashes with its key attribute: Spaghetti code is brittle. It often breaks as soon as a new developer touches it.

It also tends to have complex and subtle bugs. The cause of Toyota’s fatal “unintended acceleration” bug in the mid-2000s was finally traced to internal conflicts in spaghetti code. The two recent fatal crashes of Boeing’s 737 Max airplanes, though not yet resolved, are being widely blamed on software issues—in this case greatly complicated by the presence of AI algorithms in the mix. Everybody wants to win, and if winning means shoving the latest and greatest features into legacy systems, so be it.

Everyone we talk to in the OEM space is telling us the same thing: software is very challenging. Hardware players have never been good software business people. They’ve never understood software culture, never learned not to confuse software with their own core equipment business and value propositions. And they have continued to think that they can do anything to anyone, and everyone will have to keep playing by their rules.

But that story is over. Substantial value has already shifted from the physical system to software, and the question on everyone’s mind is, “Who is going to be the Google or SAP of the future OEM software business?”

EMBRACE DEVELOPERS & RELINQUISH PROPRIETARY TRANSPORT & MESSAGING PROTOCOLS

Software product realization is not like hardware product realization. Jet engines have to work the instant they’re released and keep working over a long life of service. Software is never finished, never “done.” Thus, it’s almost understandable that manufacturers act like they’ve never heard of the software developer community. But that has to change. Ecosystems now need to include developers as well as diverse strange bedfellows like system integrators and professional services firms. Manufacturers need to get onto developer exchanges where someone posts something and someone else sees that it can be used to solve a problem.

Software development is scaling so fast—beyond the mobile world into AI and machine cognition—that it’s outstripping the capacity of developers to meet the demand. The joke in the software industry is that there’s not enough human beings in the world to build the software we need. We have to get to a more modular reusable model.

Everyone involved in development needs to understand that the tools for making software need to change to support more intuitive development of code. Developers can’t “run” thousands, never mind millions, of lines of code in their heads. The gap between typing text and the effects on the physical world has now grown too large. We need new protocols and processes to develop software for the world of machines, equipment and devices.

Against the confusion caused by the IT and OT hardware and software providers, another approach that’s gaining momentum is open-sourcing the key components around messaging and data representation. This echoes the development and adoption of the Internet and the Web, where the enabling technologies were all open standards. No one talked about proprietary transport and messaging layers, but rather about innovating on top of those things. If companies took this tack, it would free them from being trapped by large incumbents who are trying to control the entire technology stack.

Arlen Nipper, who co-authored the open-source MQTT (Message Queuing Telemetry Transport) protocol, which is analogous to HTTP for machine data, said in a conversation with us, “Microsoft, Google, AWS, and other infrastructure players are happy to provide networking infrastructure, microservices, server capacity for data lakes, and machine-learning algorithms. But they don’t know or want to know what a flow computer managing a pipeline is. All they care about is that you’re using their data highway.” This is one obvious opportunity for OEMs like Rockwell, GE, Schneider, Hitachi or Siemens, who have Intel quad core processors in their machines, to leverage their capacity for edge intelligence.

Whatever approach the OEM community decides to take on this phenomenon—call it digital transformation, Industry 4.0, the Internet of Things, or any of its other names—engaging meaningfully will require that we stop wrangling over enabling technology and start collaborating on solutions. ◀︎

This is part 2 of a 3-part series entitled “Creative Software Evolution.” See part 1, “The Trillion-Dollar Risk.”

Please visit our website to download our Technology Insight “Taking the Plunge.”