|
|
Embedded is a Services Industry - Part 2
2006-06-19 Article Rating:  / 0
Foreword -- Positioning the intellectual property that goes into embedded systems as "service" rather than "product" distributes risk more evenly between client and vendor, writes embedded services company founder Curt Schacker. The service model fits the "no-cost" nature of software copying, and has been proven successful by free software vendors, Schacker argues in this guest column.
Readers are invited to comment using the link at the end of the article. Enjoy . . . ! by Curt Schacker Last month, I argued in a column here at LinuxDevices.com that much embedded software really constitutes a service rather than a product industry. At the risk of incurring the reader's wrath, I'll take the argument one step further and describe how a service model can serve everyone's interests -- vendors and OEMs (original equipment manufacturers) -- more effectively than a product model does. I will also illustrate the point with a pretty common example. Before going on, though, one point of clarification: these arguments are directed at software 'intellectual property' that gets embedded into a device, rather than at the software tools that engineers use to develop embedded devices. This wasn't clear in my previous article. Let's compare the two approaches by looking at what happens at that key event in all of our lives -- the commitment to buy, i.e. when a customer issues a purchase order to a supplier. When a software product company secures a booking, payment of the corresponding invoice is pretty much just a function of time, usually 30-60 days. Barring some type of unforeseen circumstance, the vendor usually does get paid. But what happens if the product doesn't perform as advertised (which is often very difficult and time consuming to discern with complex software technology), or as is more often the case, has an architecture or implementation limitation that impedes or restricts the OEM? It's clear here that the OEM has taken on more risk than the software vendor in this transaction -- the OEM may be stuck with a product that doesn't work for them; they've lost invaluable time in their schedule; and, they now have to find a substitute solution. By comparison, the software vendor has probably lost the opportunity to do business with that particular customer. Incidentally, I believe this risk imbalance is well-understood, and finds expression in the form of relatively low license fees in relation to the cost to develop and support embedded software, which is why so many embedded software vendors struggle for profitability. Let's look at a pretty typical example. A common software component to every embedded device is the device driver. Countless times, I've seen device drivers packaged up as standard 'products' with an advertised set of features. Only after this product is integrated in the application environment does the OEM find out that it does not meet their performance requirements because the driver's author assumed "large packet size, no compression, and did not implement DMA support," whereas the application requires support for "small, bursty packets, flow control, and full DMA support." The typical embedded vendor's answer today is, "The product is provided in full source code; you can change it." But the reality is that the vendor, under a services model, is in the best position to make the changes and support the OEM in most cases. Now, let's describe the purchasing scenario under a services model. To a services vendor with a substantial intellectual property (IP) base, a booking really only represents the potential to get paid. Actual payment is subject to a successful delivery of the work proposed (usually defined in an accompanying agreement called a "statement of work"), which is confirmed through acceptance testing by the OEM. Let's examine the distribution of risk in this model. If the vendor fails to deliver as promised, not only is he unlikely to be paid for a large portion of the work, but he is also out the real cost of doing the (under-performing) work. This is a fairly disastrous scenario for a services vendor, and one that very few companies could withstand at any level of frequency. Make no mistake, it's no picnic for the OEM either -- a failure to deliver still hurts their business badly -- but at least the folks on the other side of the table are equally motivated to perform. Under the service model, the vendor is unlikely to commit to requirements that they cannot meet due to known limitations in their IP. In the product model, often times a vendor will "hope for the best" when licensing a standard off-the-shelf product, and allow the OEM to try and mitigate risk through an evaluation. Imagine a conversation with two sales representatives, one from product company A and one from service company B. A: "I've got this totally awesome product that'll do everything you guys need at the highest possible performance, and it'll run on any hardware platform out there. Just license it from me and you'll see!" Hmmmm. And B: "We can customize a solution for you that will do everything you need, and here's what it's going to cost. I need some of the money up front, and you pay me the rest when your acceptance testing verifies that we've done everything we committed to do." If you are an OEM, which sounds better to you? I can see some people saying, "Isn't this just an academic argument? How do you just wave a magic wand and change a product to a service? A car is a product and a car wash is a service." All valid, except that software exhibits this one little peculiarity -- it doesn't cost anything to produce another copy. That fact has interesting implications (just ask the music and movie industries). What it means in the embedded business is that it is quite feasible for a services engagement model to be applied to what are currently thought of as software products. Rather than a product being a shrink-wrapped item whose functionality is fixed between releases, and rather than being licensed "as is," a product could serve as a very advanced starting point toward a services engagement that proceeds as described above. Think of the product as sort of raw 'intellectual property' that still needs to be combined with other ingredients and baked into a customized solution. And a unique and differentiable solution is what a typical OEM needs to tackle specific applications and to be competitive in their market. I think it's fair to say that this is very much the model that has organically evolved around open source software, and for good reason. Commercial embedded software vendors would do well to examine why this is the case. A more equitable distribution of risk between vendors and OEMs, which a service model engenders, can only result in more successful engagements, better profits for vendors, and a healthier industry for all of us.  About the author -- About the author -- Curt Schacker has spent his entire career in the embedded industry. He started out in 1985 developing flight software for NASA's Hubble Space Telescope before moving to embedded software pioneer Ready Systems. In 1990, he joined Wind River Systems, where he served in the roles of Field Applications Engineer, Northwest Regional Manager, and Vice President of Marketing. In 2002, Schacker co-founded Embedded Solution Partners, an embedded software and services firm based in San Mateo, Calif., where he currently serves as CEO. He holds a BS in Computer Science from Wright State University in Dayton, Ohio.Do you have questions or comments about this article? talkback here Related Stories:
|
news feed
