(photo copyright 2007, A. Barake)
Where I talk about more-or-less obvious but infrequently discussed strategies by Sun, IBM, Microsoft et al.I think it was in during the last century, with the advent of the hardware/software dichotomy that this type of strategy evolved. IBM may have been the first to use it successfully. A prerequisite is a pair of complementary things to sell, with at least one that you control completely, through secrecy, patents or a huge market lead. Let me describe it.
Suppose you sell hardware, and you make and sell software for it too. Your competitors also sell hardware and software of course. Your hardware is different and possibly proprietary or difficult to clone or
to re-brand. So the strategy is to make software that runs on both your own and your competitors' box. You under-price or give away the software, and call it bundling.
Better still, you give away stuff that is almost or as good as your competitor’s, and you value-add and sell a version that runs only on your platform.
Sounds familiar?
IBM with Java and Linux
Sun with Solaris
And both are also attacking Microsoft with Eclipse and
OpenOffice respectively.
Yet Microsoft thrives.
Explain in 2 pages or less....
Microsoft fights back using another strategy; they sell software that runs mostly on smaller cheaper platforms. They have an arrangement of co-dependency, as their releases grow and become more bloated, they require bigger and bigger Intel
horsepower, until that low-cost hardware begins to overtake the computing power of big boys. This is an attrition strategy; much vaunted in management theory courses.
Microsoft's core business is software, so it is the protected commodity. The hardware is Intel, but multi-vendor and
commoditized so competition drives the price down below the proprietary guys’ stuff. They are pursuing a software-first strategy and the other guys are pursuing a hardware-first strategy. Are you still with me?
It is with reason that IBM fears Microsoft more than it fears Sun or HP.
IBM and HP also sell Intel servers, but they are branded, not commodities. Both try to mitigate the hardware-first exposure by also making money on professional services (which can sometimes be an adjunct to sale - nudge nudge), server software and very big boxes. Forced upgrades due to byzantine dependencies among their software offerings help too, and the upgrade cycle is one way to drive this.
IBM has little software presence on the desktop except with
IDE’s and I’m not sure they sell workstations since the
Lenovo deal. In other words, they threw in the towel for now.
On the Internet side:
The classic version of this story is, of course, Microsoft vs Netscape, where hardware becomes system software and software becomes the browser. We know who won.
More subtle, as chronicled by others before me, Google learned a thing or two from this. They give away email, blogging,
API’s, server side apps - to counter Yahoo’s offerings in that space. Free and easy Web access for the masses, no emphasis on paid subscription modes, whereas Yahoo does act as an
ISP. Google’s core business depends on search and on page views, all the rest of their offerings simply draw customers into their portals while at the same time undermining Yahoo’s non-search
businesses. They are not evil but almost...they
followed in the footsteps of the well-tried IBM and MS strategies.
Yahoo - has no strategy that I can tell. They are like Sun. Java was a gift to the community that hurt Sun, since it is platform independent. I guess they thought that they could make an OS/hardware combo that ran the
JVM better than the other guys, but IBM with its marketing (and technical) clout claims that that is not the case. In a way, it is as if Microsoft had written Linux. That is what happens to a nice earnest tech company that swims amongst the sharks.
Is their hope for the "good tech" to overcome the "mediocre tech" with good strategy?
My proposal would be combine the Apple, Sun and Yahoo brands as the high-end stuff of computing. The champagne. Then market it to consumers and businesses as the cream of the tech-
savvy crop. Apple and Sun are an almost perfect match, and it would get Apple into that server market they so covet. R&D would be a plus rather than a risk, since the audience would want to take those risks, it would be cool, fodder for the early adopters. Yahoo would provide even more channels for Apple’s media side
There. Free strategy. Why don’t I command the multi-million dollar bonus?
I know many tech types who can't bring themselves to believe that that kind of “deep thinking” goes on; but this is exactly what the people who took biz courses when you were toiling to understand complex stuff end up doing, and they make the big bucks. Hustlers, thugs, ruthless opportunists... having the only kind of fun they can, since they can’t make things, are too competitive to collaborate with anyone, and certainly can’t code. I think they are missing out, because in the end, what's left is an abstract and hollow victory, scorched earth, and lots of resentment against inferior technologies. Real satisfaction can only come by making things better, and not just in the monetary sense as noted
here. The alternative is growing entropy until the next cleansing crisis.
P.S.
This just in.
IM/IT systems must align against the business organization (people and processes) to work well. Management must decide who must budge before a new system is put in place in either camp. When deciding whether to build or buy a system, this effect must be considered. Neglecting to factor-in the cost of the organizational change can cancel the perceived economic benefit of using commercial off-the-shelf software (COTS).
Organizations usually have to change to fit the COTS assumptions, especially for large enterprises with large systems such as enterprise resource planning (ERP). This can also apply to core business systems, since they differentiate the company from others. Think of mobile phone billing for example.
If COTS is chosen (for ERP for example), it is likely that the finance and personnel departments will have to change their processes significantly. There are many case studies that show that CEO support is required for such migrations to succeed, since it becomes a governance issue. It has become the common wisdom now.
Replacing custom-built software with COTS is a form of devolution. Size matters in this kind of decision because the “cost of re-organizing versus the benefit of saving on development costs” equation must be juggled. The bigger the org the more the cost of adopting COTS since the org usually has to change. The converse holds as well.
So where does the argument that COTS is preferable come from? Why does upper management often fear custom work? Why do they see it a a dependence on their technical staff, and why should this be preferable to a dependence on vendors? One possibility is that the pattern emerged from the computer hardware world? COTS for hardware usually makes sense for non-manufacturing sectors since the costs of custom hardware are prohibitive and it is generally ridiculous to suggest that one should build computers from scratch. Again, there are notable exceptions, Google apparently configures boxes quite heavily to suit their needs.
The COTS for software approach is not so obvious with the advent of open source and the devolution from mainframes towards lower cost systems, the proliferation of high-level development tools and the commoditization of the software stack. For example networking and OS are now mostly standardized, and much of the higher level layers are becoming standard - Mail/Web, database and application servers. Even development environment possibilities. The database-to-presentation layers are now the target of service-oriented architecture (SOA) driven commoditization, but the vendors are all looking for their own lock-in (i.e. avoiding commoditization) while claiming interoperability to get the sale.
For example vendor A’s ESB makes integration with vendor B’s apps much more difficult than with vendor A’s. Interfaces are easy to import but hard to export. Such pitfalls can be avoided by a vendor diversification strategy across the application layer that is coupled with good cost control and use of custom solutions where appropriate. Thankfully ESB’s are not a prerequisite for SOA, but this is not generally well understood.
So IT planning strategies need to revisit the seemingly popular notion that custom is always a liability. I think that if cost control is the business objective, then it should be decoupled from the “customization vs. COTS” argument. There is no direct mapping. The organizational size attribute has to be factored in, amongst other things.
Another ideology-prone minefield is standardization. Standards should really be orthogonal to this discussion, but are related in strange ways. Standards are sometimes perceived as a factoring exercise to reduce the proliferation of types of solutions and products in an IT department. This can work very well with hardware. Where standards are problematic is when they prescribe major system software COTS without taking into account organization structure (again). Why prescribe COTS through standards? Well COTS is good, right? And less COTS variety should be even better. Hummm.
Vendors claim and often try to provide the flexibility in their products to allow (some) business process mapping and legacy integration but usually at the cost of configuration complexity or alternately through costly professional service customization.
The benefits of these approaches over custom development need to be weighed carefully; there are plenty of case studies that show success with either approach and the cost-benefit is not at all straightforward, especially when you consider upgrade cycles and other dependencies.
If product/portfolio standards are adopted by an organization, then it must also adopt compatible organizational and operational standards, since software is really an extension of organizational processes and COTS will force an organization into a process relationship with the vendor. It is a form of outsourcing.
This can ultimately lead to having the hired-guns, the management change consultants and the vendor IT/IM professional services too tightly coupled, resulting in them having a profound influence on organization structure and operations. Are organizations prepared for this kind of loss of control in exchange for perceived but generally illusory cost benefits?
I think that one of the sub texts of the discussion is at root ideological - outsource development versus do it in-house. Yes, IT departments do have much influence and are complex things to manage, and require expertise, but control cannot always be gained through outsourcing or by buying COTS, unless you are very small or have very simple needs. Horror stories abound. Control and accountability concerns need to be well understood and documented and the business objective must be stated explicitly and decoupled from the implementation. There are no silver bullets, only smart management.