The Art Of Double-Indirect Sales And Product Marketing

By Frank Schirrmeister

The interaction between software and hardware development has been much discussed, with early software enablement being at the forefront of what system-level design in EDA tries to enable. The main reason why these discussions are so attractive to EDA – in my mind – is the impression that the number of software developers is significantly higher than that of hardware developers. If there would be just an easy way to get to them with an offering that they cannot resist!

I recently explored that relationship between hardware and software developers at various occasions, trying to understand app developers and their relationship to silicon, finding out where they reside and who defines requirements and most recently looking at some market data to understand their numbers in relationship to system-on-chip (SoC) design. Then I ran across the article “Mobile app development services market reached $US 20.5 billion in 2011”. In that article research from the mobile research specialists research2guidance is referenced, stating that “the market for mobile application development services, including application creation, management, distribution and extension services, has reached $US 20.5 billion vs. $US 6.8 billion in app downloads in 2011.”

Wait a minute? How can the market for services be bigger than the market for the products the service enables? I was thoroughly confused for a little while until I realized the inherent indirect selling and marketing relationship here. Of course, the actual market for apps is determined by the paid-for portion of applications downloaded through app stores. Apple has done a great pioneering job establishing the “tax” on that mechanism by providing the app store as channel and charging 30% of every download. Others have followed suit – like this overview of application stores nicely illustrates.

But looking at my iPhone and iPad, the number of paid applications is clearly in the majority. While my 7 year old daughter now has her own page of free games and talking animals, the majority of free applications I use are related to banking and other services. All of them have been free. While I have not paid a dime, their development has been paid for by the bank or service provider who enables them. For these companies,their value has been rolled into the offerings supporting their products, be they financial or more technical — like my data usage monitors to make sure that I am not running over while listening on Tunein radio on my iPhone to my favorite radio stations from my hometown of Berlin, Germany.

That same report mentions an indicator on how many app developers there may be, in referencing that “the prices for application development services differ depending on which region the developers are located in, while UK developers charge $US 626 per day, developers from India  charge, on average, $US 138 per working day.” If I am not mistaken, this puts the number of apps developers providing services at 80% load and 40 hour work weeks and assuming 70% at the lower cost point at around 70,000 developers. That’s a nice target number, considering that there is a large in house market as well.

So the bottom line is that the software development cost to fund all those developers is not directly paid by the software sales, it is funded via an indirect business model. This requires some artful, indirect marketing and sales activities as indicated in the graphic here using what I have referred to before as “Hogan-Triangles”.

That’s where the hardware side is facing a level of indirection. For the hardware teams to provide a virtual platform is like painting the fence on your neighbor’s side – you does not get immediate value yourself. Until virtual platforms become a natural by-product of mainstream development flows and are used as golden reference for verification and implementation, their development will be considered overhead. That overhead has to be rationalized by the advantages it indirectly provides to software developers, such as earlier availability shortening software development’s long tail, better debug and control and so forth. As a result the investment is often funded not by the hardware development teams themselves, but by executives who own both the hardware and software development.

So just like for software developers, the bottom line on the hardware side is level of indirection, in which the software enablement has to be rationalized and funded not by the teams who have the knowledge to develop them. Again, artful marketing and creative selling is required.

Why am I still optimistic that we will get to the app developers somehow from the EDA side? First, as referenced in a recent discussion I had with Richard Goering, virtual platforms in combination with high-level synthesis have the potential to become part of mainstream design flows. Second, when talking to customers, there is a small but proper subset of developers who need to see the hardware details to optimize their software development. Some of them are concerned about availability and status of hardware resources, others need to optimize their mobile applications for low power, avoiding some of the early experiences in which too frequent calls to the modem was draining the battery in minutes as opposed to hours. At least to this subset of apps developers, virtual platforms and even the other engines are useful vehicles to verify important scenarios.

Still, the double–indirect selling and marketing required to get all the way from tools enabling hardware development to software users whose services have to be indirectly funded because the software is free,  requires creative approaches and business models, keeping our life as high-tech marketers for system-level design interesting.