Is EDA the Rodney Dangerfield of software, or is there a way of getting paid for real value?
He’s a comic legend. The master of the one-liner. I had the good fortune of being in a comedy club in New York City one evening a long time ago when Rodney stopped by to try out a new comedy routine. He simply walked in and took the microphone for 45 minutes. Apparently, he did those impromptu appearances a lot “back in the day”. One of Rodney’s most famous one-liners is “I don’t get no respect,” and that’s the topic of this Early Edition.
I’ve ranted about flawed business models and the Original Sin in other posts. That’s not the focus here. Instead, I want to pose one simple question: “Why is EDA the only complex business enterprise software product that is expected to work out of the box?” And what does a lack of respect have to do with the question?
Let’s examine the market of complex business enterprise software for a moment. Yes, EDA software is complex business enterprise software. It performs highly specialized tasks on mission critical company data and interfaces to other supply chain functions. So does product lifecycle management software, enterprise resource planning software and shop floor control software.
Here’s the difference: Those other forms of software require customization to fit into the company’s infrastructure and use model. That customization is done through highly specialized software deployment services. It can take months and sometimes years to integrate and deploy an enterprise-level software system. The customer expects it, plans and budgets for it, and works closely with the integration team to make sure things are successful.
So then, why are such services so inappropriate for EDA software? Anyone who has tried to sell such services to the EDA end customer knows the response. “I paid you for the software, and now I have to pay you again to make it work in my environment? No!” While enterprise resource planning or product lifecycle software is expected to require customization, EDA software is not. Yet EDA software is every bit as complex as those other applications (EDA developers will argue their code is substantially more complex), and making such a system fit into the customer’s design flow clearly is not a “drop in” exercise.
If you examine the financial statements for enterprise software companies, you will find that services revenue is typically around 20% to 25% of total revenues. The number is way smaller for most EDA companies – customers won’t stand for it. Yet, the result of that point of view is significant methodology, data management and efficiency challenges. From 20 feet away, this just doesn’t seem to make any sense. Unless you come to the conclusion that “EDA don’t get no respect”.
My wife came by earlier today and asked me what I was writing about. She’s done marketing work in EDA, semiconductor and enterprise software companies, among others. So her opinion is relevant beyond the fact that I have a marital duty to listen to her. When I explained the premise of this piece, she said “enterprise software is more expensive than EDA software, so people pay for the implementation service to protect their investment”.
That was the “aha” moment for me. Problem solved. Let’s raise the price of EDA software, say 10X. Customers will now pay to protect their investment, and EDA tools will work together in a much smoother way. I wish I had thought of that sooner.
Leave a Reply