"Round about the accredited and orderly facts of every science there
ever floats a sort of dust-cloud of exceptional observations, of
occurrences minute and irregular and seldom met with, which it always
proves more easy to ignore than to attend to... Anyone will renovate his
science who will steadily look after the irregular phenomena, and when
science is renewed, its new formulas often have more of the voice of the
exceptions in them than of what were supposed to be the rules."
- William James
|
This will NEVER work!
We’ve heard the reference to certain people as being a “Negative Nelly”, i.e. a person who always sees the glass as half empty, as opposed to the eternal optimist who always sees the glass as half full. By most people’s standards, engineers would fall into the Negative Nelly category. Engineers are paid to design to specifications that consider the worst case scenario. In fact, if engineers were not trained to think and design in this manner, I’m not sure as many of us would be that enthused about flying commercial airliners. Sales and marketing teams would tend to tilt on the eternal optimist side of the equation, and we also tend to like this characteristic in these individuals as well, except of course, when their optimism lands the CFO on the wrong side of a Sarbanes-Oxley audit. Overall though, given ethical, moral, and competent executive corporate management, these two extremes in corporate cultures seem to balance each other out.
This blog entry’s title phrase, “what can” identifies a Designer mindset that says, “…this is what we can do with the resources that we presently have.” It is an engineering equivalent of saying that our glass is half empty. The corresponding phrase “what could” identifies a mindset that says, “…IF we had access to this or that, with no restrictions on our resources, then this is what we could accomplish.” In essence, the Designer/engineering equivalent that says our glass is half full.
In my previous analysis, using Value Chain Evolution Theory as applied of the semiconductor supply chain, I identified four (4) disruptive innovations that overlaid on four (4) supply chain stakeholder “identity profiles”. One of those identity profiles was the “Designer” class identity profile. The Designer class identity profile is applicable to many engineering or technology related supply chains, not just the semiconductor supply chain.
I profile Designer class cloud computing users by the following characteristics…
- Is in a Research & Development role.
- Active in product development (1) architecture, (2) engineering, (3) implementation, (4) verification, (5) quality control or (6) support.
- Generates product-related intellectual property that is part and parcel to the core business operations of the company.
- Work methodologies are engineering centric.
- Uses computing-aided design methodologies and/or applications in some form for execution of their daily activities.
I’ll probably expand upon these definitions as I continue to think about it, but I am seeking a generalized use case profile for Designers that can be ubiquitously applied across many RnD disciplines.
This blog entry will focus primarily on the following indirect network effects of WorkFlow-as-a-Service (WFaaS) cloud services have upon the Designer class cloud identity profile, namely this…
- Is there a change in Designer class operational behaviors when SW application laden workflows are provisioned through demand-based utility computing services, i.e. WFaaS enterprise architectures?
- How are Designers “constrained” by present software licensing models, and why do WorkFlows-as-a-Service represent “opportunity” for Designer class utility computing users?
- What impact do these WFaaS-induced behavioral changes have upon Software-as-a-Service (SaaS) revenue models?
- Can such WFaaS operational changes be quantified in a constraint model that can then define the opportunity cost benefit of WFaaS cloud services?
- I propose here the use of SysML (systems engineering) parametric models that constrain AND integrate BOTH architectural performance features AND financial & marketing metrics to create a quantitative model to be “solved” under constrained parameters.
- Such models can then be visualized and iterated through a suite of parameter ranges.
Let”s walk through the early budgeting and scheduling cycle for a semiconductor chip project. The use of computer-aided design software and processing resources is fundamental to the project execution and must be addressed at the inception of the project management. Electronic Design Automation (EDA) software applications are among the most expensive software licenses that can be purchased, where a single license can list as high as $1M. If you are a small/Tier 2 chip design company that is not considered an “enterprise” customer for an EDA company, discounts off of these list prices will be slim.
The chip project manager must begin the scheduling & budgeting analysis by first determining what percentage of the project budget can be assigned to EDA software.
Let’s stop right here!
Why is the schedule involved in this decision? Because the amount of EDA software you can afford will have a direct impact upon how fast you can get your chip completed. If the chip team could only afford ONE (1) simulation license, they would NEVER be able to run enough simulation cycles to verify the chip’s functional behavior. If the project purchases too many licenses needed for a particular phase of the chip design, then a lot of wasted money has just been flushed. If a company could only afford the base logic synthesis license and unable to afford a physical synthesis tool, then the designers would spend ten times as much time trying to optimize the chip using older technology methods. The point here is that the volume and sophistication of EDA software that your company can afford will become a determining factor in HOW FAST and WITH WHAT QUALITY your design team will be able to get the chip ready for manufacturing and product deployment. And remember, without the quality, the chances of a first pass manufacturing false start are extremely high and will usually mean the death of the chip, maybe even the company.
Let’s just pause for a moment here and think about the implications of the project manager having to trade off the ultimate success or failure of the project on how much EDA software the company can afford. During a chip design project the use of EDA software is NOT an option. The project will use upwards of ten different critical EDA software tool applications in the development of the chip. The use and volume of licenses of EDA software will come at different times in the development process. Therefore, astute project management teams will take the time and effort to try to match the use demand of the software they need to the date in the project schedule that their design teams need the software.
Software licensing management appears more constraining than liberating!
EDA sales teams do not like this type of negotiation. They are seeking to close the maximum amount of revenue to meet their sales quotas. Herein lies the dichotomy that is plaguing this software/design project relationship, namely, what is good for the software company, IS NOT good for the customer. If you are operating your business with this underlying premise, you are not going to have a happy relationship with your customer base. Am I exaggerating this? Go ask any chip project manager how much he loves the annual visit from his assigned EDA sales account manager, and you will find out how satisfied they are with the present status quo.
If there was ever any industry software relationship in more dire need of a Software-as-a-Service (SaaS), demand use model, it is the semiconductor design industry. Oh sure, the EDA companies will often cite their “RE-MIX” policy where they GENEROUSLY allow their customers to exchange their software licenses on some prorated basis, but does anyone actually believe that this is addressing the customer’s FUNDAMENTAL needs? No! Again, ask any chip project manager if this is what he/she had in mind when EDA software companies offered software license re-mixes as their solution to demand-based utility computing? You get my point!
Cars-as-a-Service (CaaS)?? – Opportunity costs in the automobile industry
I’ll reiterate another point in the debate on cloudonomics that I recently read.
The discussion surrounded who car manufacturers are willing to sell their cars to. We think about three (3) profiles of car buyers: (1) consumer sale, (2) rental cars, and (3) taxicabs. Car manufacturers initiated their business models through the sale of their product directly to the end users. Clearly, this business represents the overwhelming percentage of sales. However, car manufacturers do not prohibit the sales of their cars to companies that are in the rental car business. For the most part, car manufacturers actually embrace their rental car customers in strategic alliances for exclusive sale of their cars, going so far as to actually acquire large rental car companies as separate business units of their operations. It is also not strange that some people use a rental car company as a channel for a final domestic sales decision for a particular model by renting the prospective model from the rental company and drive the car around for a weekend to see if they like it. In a similar vane, car manufacturers sell cars to taxi cab companies. Pricing of course is commensurate with the target market.
Unless we live in Manhattan, we do not all drive around in taxicabs all day, because it is simply not an economically viable means of transportation. However, taking a taxicab to the airport makes a lot of sense and the regulatory rates charged by taxicab companies seems to be a business model that profitably keeps the taxicab companies in business. Similarly, neither do we all drive around in rental cars, but rather on extended stays during business travel. Renting a car in these circumstances makes a lot of sense, and a healthy rental car market keeps rates competitive.
The existence of the rental car and taxicab markets represents a transition from CONSTRAINT TO OPPORTUNITY! I contend that the demand use model exhibited by the rental car and taxicab companies is the PERFECT example of opportunity costs that should be considered by the software industry. The car manufacturers simply view these adjacent use models for their products as part of their NATURAL market. They do not view these markets as anomalous behaviors that must be controlled or repressed by non-free-market strategies.
In this light, neither should software companies view the utility demand pricing models offered through ubiquitous computing services as a market threat that must be controlled through collusive activities among competitors. These changes are nothing more than a live examples of Value Chain Evolution (VCE) theory at work. Software businesses that seek to maximize their revenues will be positively served by adapting to these market forces. The key component in forming an adaptation strategy for cloud computing is to seek OPPORTUNITY NOT CONSTRAINT!
Skeptics immediately contend that the heavy manufacturing business of automobile manufacturing has virtually no resemblance to the creative science of software design. After all the fixed and marginal cost models between software and automobile manufacturing represent perfect diametrical positions. In addition, such skeptics may contest that VCE Theory does not apply to the software industry. But aren’t software workflows an example of modularity?
It is easy to dismiss VCE Theory and disruption as not applicable to one’s own business sector, and seek to “spread fear in the name of righteousness.” Their attitude should be more closely aligned with Intel’s Andy Grove, i.e. paranoia. Don’t run from change, embrace it! That is precisely what Intel did when the company changed their corporate strategy to focus on the microprocessor market rather than the memory market. Intel’s executives were able to see how the market changes would affect their corporate strategy and subsequently embraced the changing market conditions to the company’s magnificent advantage and success. The same must be true for software companies who must embrace the business and technology changes being ushered in by the cloud computing market.
More to come…
J. Marc Edwards' techno-blog 