Webster’s Dictionary defines “Platformification” as – OK, you got us.  It’s not in Webster’s.  Even Microsoft Word gives us the squiggly red line telling us we’re treading on dangerous ground.  Wikipedia – no better.  We got diverted to some articles about Mario Brothers and other games where characters jump around from platform to platform – not unlike embedded systems designers choosing and then abandoning various combinations of processors, operating system, and peripherals powering their creations.

Intel tried to stick us with the word “Platformization”, and we briefly considered that, but their definition – the combination of several chips into a standardized platform, is too specific.  “Platforming” is apparently a long-recognized method for separating petroleum products during refining, so that one was out as well.  We decided on “Platformification,” and a quick Google search validated our decision.  Our hope, of course, is that Google will list this article among the authorities on Platformification soon enough, with Webster’s and the other Luddites to follow. So, with apologies to both Intel and the English Language – here we go.

Platformification is the polar opposite of “NIH” — the Not Invented Here syndrome.  We’ve all faced NIH in our engineering careers.  Some engineers suffer from acute and seemingly incurable NIH.  At home, if they want bread for a sandwich, they plant their own grain in the back yard, grind it with their own millstone, take yeast from their own culture… you get the idea.  While this purist approach gives the engineer absolute control over the finished product, one has to look at the tradeoffs involved.  Use of a commercially-produced flour would definitely reduce the effort involved in baking the bread.  While the engineer would give up some control, the quality of flour produced by a company that specializes in that operation might also be higher. 

In product design, the make-versus-buy decision is usually shrouded in accounting and finance language – what is the true total cost of building versus buying or licensing from a third party?  Do you account for market window revenue lost if building takes longer than buying? (This factor can easily trump all your engineering-related costs, if you’re not careful.) 

As engineers and marketers of technology products, however, we need to think from a different perspective.  We need to pay particular attention to what value and innovation we bring to the table and how that innovation creates real differentiation in our product.  Technology products, you see, are usually not commodities like flour, where consistency, quality, price, and availability are the driving factors.  Technology thrives on the magic of product differentiation, and that is where we need to laser-focus our engineering efforts. 

In embedded design, we could start each project by engineering a new processor architecture and instruction set.  We might be able to optimize each one for the particular demands our product will place on it, saving some power and area and gaining some performance in the process.  Most of us can agree, however, that project-specific processors would be a bad idea (unless, of course, you’re using some automated technology like, say, Tensilica’s, to automatically generate specialized, optimized processor cores, but that’s not what we’re talking about here.)  We typically grab a processor or core from the people who specialize in those things and spend our energy on parts of the product where we can add more value.

Platformification, then, is the packaging of those “not to be invented here” parts for our ready consumption.  If we want to build our product on an ARM-based platform, for example, we get a lot of stuff done for us for free as part of the platform.  We gain access to IDEs, operating systems that basically plug right in, middleware for many common peripherals and interfaces… — the list of stuff we don’t have to invent is staggering.  Platformification is hierarchical, too.  Inside your ARM-based platform are other components that are similarly packaged.  Somebody has developed a key technology, realized that it has broad applicability to a number of products, and decided to bundle it all up so we can buy it.  Other developers wrap that platform inside a platform of their own and sell us the result.

While we’re accustomed to the Platformification (can we stop capitalizing it yet?) of things like processor architectures and operating systems, a number of other key system components are becoming platforms as well.  Interconnect standards like PCI (particularly the “express” flavor), USB (and the 2.0 version), and all the rounds of Ethernet from 10 to bazillion-base-T have long been packaged as platforms, and we’d do well to take advantage of it.  It’s a rare product that will blow away the competition because it has a REALLY COOL implementation of the Ethernet interface.  No matter how clever your design may be, it just isn’t going to happen. 

More recently, user interface components are falling into platforms as well.  If you’re using a touch screen, a standard LCD display, a keyboard, a microphone, a speaker… – you’re really not going to make your product stand out from the pack by one-upping the off-the-shelf options already on the market.  You’ll save time and get done faster (leaving the marketing people more window weeks to milk money from the masses) using a platform than designing your own.  The only exceptions are if you have a truly innovative user interface technology that sets your product apart, but even these ideas – voice recognition, advanced image processing and the like, are starting to be available as pre-packaged platforms for your ready adoption.

So, should we all just give up and go home?  We could readily relegate the process of picking and combining platformified hardware components to our twelve-year-olds and forget all that engineering school.  As more capable and optimized platforms become available for just about every component of our system, how will we differentiate ours from the pack?  Will industrial designers take over technology’s reins as the metal-flake paint job becomes the big item that attracts buyers?

Certainly for awhile it has seemed that the answer is “software.”  While the hardware side of embedded technology continues to become more and more generic, the complexity of the application layer leaves enormous opportunity for product differentiation.  Even though the underpinnings like operating systems and middleware have rolled into the off-the-shelf domain, the applications layer remains a defensible fortress.  Consumers are already making the mental adjustment to comparing the user experience of various products based on the contribution of the software, even if they’re not aware that software is what they’re comparing.

Innovation in hardware is by no means dead, either, however.  It’s just that, as a trend, we’ll see more of that innovation poured into re-usable, multi-application platforms rather than individual products.  This makes sense, if you think about it.  If you have a world-changing idea for a hardware innovation, why relegate it to a single product when it could potentially be licensed across a vast array of products in different industries – all sharing the same standard platform as a building block.  The return on technological investment is potentially much greater. 

Platformification does mean a slow evolution of our careers as electronics engineers, though.  If you’re doing low-level engineering on components that are becoming available as standard platforms, you need to either raise your personal level of abstraction and expertise or find a new job at one of the companies producing the platform.  Otherwise, you’ll witness firsthand the ugly side of platformification.  As engineers, we need to always be aware of our personal value-added and not let platformification sneak up on us so that we outlive our usefulness.  Otherwise, we won’t see “platformification” as a happy word  — like “productivity tools” or “design re-use” — that makes our jobs easier.  We’d be more likely to see it more in the category with words like “redeployment” or “downsizing” – not the best friends of the average engineer.