For the last few years at I've been honking like a goose about the commoditization of hardware and a hardware-centric company's need to build a strong software core competency upon which it can begin to build a whole-platform architectural franchise. The recent announcement of the "platformization" of Intel Corporation was music to my ears. In today's post I describe some of the strategies needed to begin building these architectural franchises.
Unfortunately there are a lot of people involved in strategy activities that do not understand the process. From what I have observed developing business strategy is sort of like teenage sex...
1. It is on everybody's mind all the time
2. Everyone talks about it all the time
3. Everyone thinks everyone else is doing it
4. Almost no one is really doing it
5. The few who are doing it are:
- Doing it poorly,
- Sure it will be better next time,
- Not practicing it safely.
I emphasize the word 'strategy' in this context because the effort is long term and a "bet the business" decision. When I use the word 'strategy' I mean a defined plan of action that will develop a business unit's competitive advantage and compound it.
I think there is a tendency to confuse strategic long range planning processes and the their outputs as strategy-making and strategy, respectively. I would submit that in their present form most of what I have seen more closely resemble mechanized marketing activities as opposed to development of a concrete plan to act and leverage competitive advantages for compounded revenue growth. Could it be that we just might be spending too much time trying to ring the cash register and too little time thinking about the long-term directions we should be taking and the technologies, resources, etc., we are going to need to get there?
I have seen lots of great long-range plans to build way cool technologies, but very few plans that show how the technologies already in place (or to be built) can be leveraged into an architectural franchise. Folks, bad technology and good strategy will always beat good technology and bad strategy. Just look at the success of Microsoft. From a software architectural perspective, the Windows operating system is an abomination. Definitely bad technology, but, oh my, what a wonderful strategy is behind it, no?
To build a platform level architectural franchise, a company is going to have to wage quite a battle in the marketplace. Market position as a hardware supplier will not give a company a significant advantage until it has closed the credibility gaps in those areas outside of the hardware business it chooses to enter. The operating system competition we are witnessing today between Microsoft and the open-source community are really architectural wars. As we are seeing or have seen, the architecture battles a company must choose will consist of one of four options:
1. fight them
2. become a countervailing power in a non-competing space
3. exit the space (alive or dead)
4. compete on implementation
So what should a company be doing to be ready to do compete and to win? To win any architecture competition, a business unit must sign up to a long-term, bet the business strategy and not be short-sighted because of near-term needs for cash flow. The components of such a long-term strategy must include:
1. A commitment to architect the state space and our products- backed by money, time, and talent with executive management backing.
2. Excellence in initial products- this is critical or you become the next Visicalc or Iridium, that is, you become the first to prototype a market for someone else to own (note: being first is not always a winning strategy). And remember, excellence is not defined by the technologist, it is defined by the user.
3. A plan for diffusion, versus retained control, across the market to establish leadership- as the architectural franchise opportunity takes shape contenders will appear offering the chance for alliances, licensing, and early architected products. This is one of the most difficult architectural challenges best met with a selectively open design; near seamless compatibility with supporting point products and commodity components; and wide, but carefully managed licensing.
4. Establishing and maintaining strong allegiances with after market products and users- supported by a broad, complex supporting infrastructure to increase switching costs, e.g., lots of toolkits with significant examples that reduce the customer's time to money.
5. A plan for harvesting and extending the existing architecture (most companies cannibalize themselves too late)- expansion and enhancement of architectural coverage while tightening proprietary control, yet leaving the architecture open and available. This means the architecture must be extensible enough to be extended from the initial niche into a steady stream of architected product lines and not just a series of point products. Static architectures will be devoured by clones!
6. Eventual architectural replacement- as the architecture ages develop new layers atop it to facilitate migration of its users and products to a new architecture, thus giving the new architecture a jump start on a new diffusion cycle. But before you throw the baby out with the bathwater, consider this story.
When Motorola first got into the GSM cellular business, it went out and purchased some protocol stacks thinking this would get them to the market quickly. Next it created its own "exec", a lean operating system kernel. It got both of these strategies backwards. The cellular protocol architecture is so interwoven with an overall system software architecture that to not have complete control over it means you are forever at the mercy of the supplier's own design. In effect, Motorola bought into a bunch of accidental complexities that ultimately led to a discard of this software and development of the complete stacks in house.
The exec design never met performance expectations and did not anticipate the future demands of new services not yet dreamed about. It, too, had to be discarded and replaced with an off the shelf product.
The point here is that the operating system was not the driver of the value add of the company's products. It supplied the usual services, but was something that any number of products on the market could do. There was no need to develop a new one in house. The protocol stacks, however, ubiquitously touched nearly every major software subsystem, yet the development team had no control over this design and had to dilute system strategies to accommodate the third party vendor's design. In effect, the tail was wagging the dog.
Like the item above implies, a company must hold onto the sand that becomes the pearl. All else can be bought on the open market, but we cannot afford to give up on an unfair advantage made possible by having complete control over a system architecture. This yields minimum accidental complexity and maximum chance for establishing an architectural franchise.
7. Intellectual property management- essential at every stage of the life cycle of the architecture and implies careful patent preparation and constant monitoring and enforcement.
Thanks for sticking with me this far. So, to conclude, what is the message here? Selling microprocessors, chipsets, motherboards, etc., is a credible first step, but companies must start planning and acting now for the follow on activities that will yield the greater returns. To me, those activities are software intensive and I have yet to see evidence that hardware-centric companies "get it" when it comes to software. When I run around honking like a goose about this topic I am usually met with the statement that "We are a hardware company. It has made us all plenty of money in the past, so why mess with success?" To my myopic friends I say, "Just because you're naked, that don't make you an emperor."