Using “Little Data” to Gain a Competitive Advantage in Cost Controls, Marketing, Sales and Product Development

How Developers, Managers, CFOs, and Sale and Marketing Executives can Affordably Determine Competitive Advantages from the background Noise of Claims, Counter Claims and FUD

Introduction

 

We are all becoming familiar with the concept of “Big Data”. We already have experienced the intrusiveness of “data mining” be it from the grocery store that sends out targeted coupons, or other sources that seem to know more about us than we might want.

 

“Little Data” concerns the plethora of information existing and transmitted throughout the embedded industry. If surveyed properly, we can learn a lot of what developers are doing, using, liking, disliking, where they are located, what tools, chips, OSes, etc. they are using, and what their experiences – good and bad – have been. When combined into a tool we call the EMF Executive Dashboard, this information can be efficiently mined to determine many interesting aspects of the embedded marketplace, including comparative costs of development between operating systems (including a comparative analysis of the costs of using open source software and free Linux compared with commercial OSes) and determining whether modeling offers a cost savings as compared with similar developments that don’t use modeling..

 

Pick up any journal or read any “market research” paper and one can be left wondering. Is Open Source software really “free”? Is it better than commercial RTOSes? Does free Linux offer a cost savings over commercial Linux software or commercial RTOSes?

 

How does a senior financial manager or development manager gain insights into cost savings or better design outcomes? How is development cost measured?

By upfront cost of tools and software? Or can it be measured by total cost of development, cost of late delivery, time-to-market – or by other measures?

 

Who can managers and executives trust? Can a market research director who has never managed a real P&L or met a payroll really offer value and insights based on internal surveys and personal interpretations? What is the real cost of knowledge and is it of value?

 

Is there a tool that would enables managers or financial executives to look at the marketplace from their personal perspectives – or must they dependent on the graphs and tables published (or purchased) by journals or market research organizations? Moreover, the real issue is whether these managers or executives can test their vision of corporate reality against the underlying reality of the embedded marketplace.

 

The answer is YES and we will illustrate how it works.

Background

 

As we enter the new Internet of Things (IoT) world of information technology we need to be able to encapsulate and capture information crucial to the success of an organization – be it product development, marketing and sales differentiation, strategic planning and competitive analysis.

 

In 1948 Claude Shannon published his famous and currently compelling “The Mathematical Theory of Communication” in a 78 page monograph in “The Bell System Technical Journal”. Although originally focused on communications (be it telephone, television, data storage or other medium) Shannon’s careful and concise formulations have made his theories applicable to economics, genetics and other biological phenomena. Shannon’s concept of information is predicated on “uniqueness or unanticipated change”.  Consider an electrocardiogram (ECG). Watching the repeated QRST waveforms, Shannon information would be zero. It is only with change that information occurs. A change in QRS width or a change in an ST segment elevation or depression would impart significant information to the attending physician indicating a serious myocardial event.

Herein the data source is the patient and the channel is the ECG.

 

The same can be seen with TV transmissions. The source is the transmitter and the channel is the decoder. Without a proper decoder the Shannon information is zero notwithstanding the actual transmission. In the Shannon world all transmissions are through a channel from which signal must be separated from noise. All channels, communications, biological and economic, contain noise to different degrees, and Shannon information limits apply to all applications.

Central and essential to Shannon communications is that the channel remain changeless – thereby enabling the message in the channel to contain all information.

 

Enabling Access to the Embedded Marketplace

 

In the embedded world Managers and developers are confronted with the economics of disorder. Limited but contradictory claims are without a changeless channel thereby creating zero Shannon information. True information is lacking because of this. For example, Open Source advocates can appeal to “intelligent analysis”. “If the software costs nothing then it must be better than the stuff you have to pay for” say the advocates. Other thoughtful persons might rightfully point out (as we do frequently at EMF) that if the cost of using open source software is much more costly in terms of the total time of

 

development, the number of developers required, the percentage of designs cancelled or completed behind schedule, and the cost of missing a window of opportunity, then the software is clearly not free.

 

But how can this be measured or determined? The word of a few folks on either side of the argument cannot provide enough Shannon information to make an informed decision.

 

Here’s how EMF addresses the marketplace and provides a Shannon channel in order to provide a user to examine the marketplace from their own perspective (as well as to receive the EMF interpretation).

 

The data generated by the Annual EMF Survey of Embedded Developers is statistically accurate and authentic. See Appendix A for a complete listing of survey questions with optional answers from the 2013 survey:

 

Embedded developers and managers reported on their design results, including:

 

  • Number of developers per project
  • Vertical market of their design
  • Time to market,
  • Percent of designs completed behind schedule or cancelled,
  • Closeness of final design outcomes to pre-design expectations,
  • Testing outcomes
  • The tools they used (development, modeling, Java, Eclipse, and other development tools)
  • Their choice of OS, IDE, communication middleware, processors used as well as where they go to learn about new products, tools and concepts.

 

In addition, we break out for further detailed information including:

 

  • IDEs used
  • RTOSes used
  • Communication Middleware used
  • Modeling tools used
  • Requirements management, Validation/verification and Static Analysis tools used
  • Merchant computer boards used
  • Virtualization platforms
  • Microprocessors used – including multicore, 8-bit, 16-bit, 32-bit, 64-bit, 128-bit, DSP and FPGAs
  • OSes used – including Java and Ada breakouts
  • Standards used
  • Best practices used and chosen
  • Interconnect technologies used
  • Interfaces used – with specific TCP/IP and USB questions
    • Wireless protocols used – with specific Bluetooth questions

 

 

This constitutes the “Little Data” universe which comprehensively covers all aspects of the design and development process along with questions that address why the respondent would purchase a product (or not), what issues are most troubling in the design and development process and what were (if any) any “buyer’s remorse” factors.

 

The Shannon channel now must provide a method for being able to relate any question or question response to any other one – and to provide channel control to the user for whatever interrogation of the data they wish to explore. For example we could create simultaneous filters of developers that use up to 5 different RTOSes (or that use Linux, Java or open source software). Then we can look at how many developers are used for each filter; how long it takes to complete a design, etc. From this comparison we can compute the respective costs of development.

 

We call this channel tool the EMF Executive Dashboard. Every EMF subscriber gets their own unique Dashboard so that the Little Data universe can be explored.

 

The EMF Dashboard is a unique tool that allows;

 

  • The users to simultaneously compare similar products
  • Vendors to do competitive comparative analysis; and examine how their user’s responses compare with those users of their competitor’s products
  • Marketing executives to explore developer attitudes for sales promo and strategic planning
  • Developers beginning a project to compare the experiences of hundreds of fellow developers that undertook similar projects to gain insights into design outcomes before making a final decision
  • CFOs and senior managers to look at what tools and processes resulted in the greatest cost savings.

 

For the interested reader, the following link demonstrates the power of the Dashboard and how we used it in developing data:

 

http://www.embeddedforecast.com/EMF_DashboardIntro/EMF_DashboardIntro.html

Click this link if you would like to download a PDF copy of the complete white paper “Using “Litte Data” to Create a Competitive Advantage in Cost Controls, Marketing, Sales, and Product Development”

The Power of the Dashboard (the Shannon Channel Decoder)

Consider the data presented in Table I. This is an example of how the Dashboard can be used to look at comparative design outcomes between designs  completed using model-driven development (MDD) and similar designs completed without MDD.

 

At issue is whether the cost of purchasing MDD tools is justified based on potential cost savings. Moreover, since the MDD tools can be used on multiple designs can a CFO or engineering manager justify the acquisition cost?

 

 

 

    World Industry  WorldIndustry   Europe   Europe
MBD Non MBD MDD Non-MDD
Devel time Months 13.4 13.1 13.5 13.5
% behind schedule 44.3% 49.9% 48.0% 47.3%
Months behind 3.7 3.7 2.7 2.7
Ave Delay Months 1.63 1.83 1.31 1.28
% cancelled 10.1% 12.1% 8.0% 11.5%
Months lost to cancellation 4.2 4.7 4.7 5.2
SW Developers/proj 11.0 16.3 12.6 9.5
HW Developers/proj 8.9 10.9 5.8 16.0
Total project developers 19.9 27.3 18.4 25.4
Average Developer months/project 266.2 358.1 248.0 342.1
Developer months lost to schedule Developer months lost to cancellation 32.4  8.5 49.8  15.5 24.2  7.0 32.4  15.1
Total developer months/ project 307.1 423.4 279.2 389.6
At $10,000/developer month        
Average developer cost/project $2,662,098 $3,580,843 $2,479,807 $3,420,559
Average cost to delay $323,977 $497,835 $242,327 $324,335
Total developer cost/project $2,986,075 $4,078,677 $2,722,134 $3,744,894
  MBDAdv 36.6% MBDAdv 37.6%

 

Table I: Cost Comparisons between MDD and non-MDD Designs

 

 

Clearly, the use of MDD provides substantial savings over similar design efforts which do not use MDD. These savings accrue on the initial design project and can be used on future or parallel designs.

 

Imagine trying to make the case for MDD (called MBD by MathWorks) without the Dashboard. MathWorks, IBM Rational and Atego (Artisan Studio) each used

the dashboard to make unequivocally clear that an investment in their modeling tools was justified. The cost of trying to gather sufficient data without the Dashboard would be prohibitive.

 

So how did we use the Dashboard to get the data? The entire Little Data database, consisting of the responses of developers to every question is contained in the Dashboard structure. Let’s look first to what the dashboard looks like.

 

         
    Total North America  
  All respondents 669 303  
         
  No answer 7 0  
  Those responding 662 303  
         
  Hardware engineer 54 22  
  Software engineer 137 70  
  Systems engineer 91 41  
  Firmware engineer 105 57  
  Validation/verification developer 48 15  
  Software engineer manager 61 32  
  Hardware engineer manager 25 8  
         

 

 

 

This is a view of a Dashboard page that presents the responses to the question “Are you primarily a hardware, software, firmware, systems engineer or an engineering manager”? The first column represents the total response to the question whereas the second column was filtered on a previous question asking the respondent where they worked. The Dashboard allows us to create up to five simultaneous filters each of which constitutes a new database specific to the

responses of the chosen filter. The second column represents the responses of developers that work in North American.

 

Now we can go to any question in the survey and see how the views and activities of North American developers compare with those of the industry at large.

 

Now this is how we developed the data for Table I.

 

First we go to the MDD section of the survey and click on developers using MDD in their design.  This creates a new database consisting ONLY of data containing the responses of MDD users (that is the new database contains every survey question outcome as answered by MDD users). Next we do the same for developers not using MDD in their designs.

 

Next we use the power of the Dashboard to copy both of the MDD and non-MDD columns. So now we have two columns each for MDD and non-MDD. The first two columns we call Worldwide MDD and Worldwide non-MDD respectively since the data source was from all respondents.

 

Next we go to the question that asks where the developers work and we create a multiple filter on MDD and non-MDD users AND (Boolean) “work in Europe”. We now have the four columns representing Worldwide and European MDD and

non-MDD developer responses – as shown in Table I.

 

Now we go to the survey questions within the Dashboard that asks the following questions:

 

  • Number of SW and HW developers on a project
  • How long it takes to move from design start to product shipment
  • Percent of design cancelled – and how many months are wasted until the cancellation occurs
  • Percent of designs completed behind schedule – and how many months behind?

 

For this we can calculate the number of developer months per project (total developers multiplied by time-to-market); and the number of developer months lost to cancellation and to design delays. From this we can calculate the “total number of developer months per project (developer months multiplied by time-to- market multiplied by the percent cancellation/behind schedule completions multiplied by the number of months before cancellation or late completion).

 

Adding all of these we get the total number of developer months per project. Now since we have the four columns creating simultaneous (and comparative) calculations as shown in Table I, we can determine the cost savings of MDD for worldwide and for European developers.

Of course vendors can use the Dashboard to simultaneously compare their users to those of their competitors; cost-conscious executives and managers can use the Dashboard to make purchasing decisions or to use in their strategic planning; developers or their managers can look at the outcomes of other developers that have worked on similar projects to make design decisions.

 

In a highly competitive and rapidly changing marketplace, information is King.  If you consider the cost of information high, one must consider the cost of not knowing. One must distinguish between “noise” and valuable usable information. EMF’s philosophy is that only the cost of excellent knowledge is worthwhile – and who better to create such knowledge is a Dashboard user who is free to use the “Little Data” derived from extensive, comprehensive and accurate survey data.

 

We are aware that budgets today are limited and the cost of market information can be very high. That’s why we have put the cost of providing the tool for using “Little Data” (in addition to EMF detailed reports) at $1050/month which should be affordable for any user be they sellers or users of technology.

 

 

 

Or call Jerry Krasner, Ph.D. at 508-881-1850 or email  jerry@embeddedforecast.com

 

 

Leave a Reply