The secret to General Motor's success in unseating the dominant car vendor of the time, Ford, was in acting on the fact of the diversity of the car market itself, and not staying the course of Ford's "any color as long as it is black" strategy. When cars were new, the T-model and A-model Fords with their one-size-fits-all approach worked. With a low investment and low risk, the car buyer could learn about cars while enjoying the advantages of dependable if somewhat unreliable transportation. Once past that learning curve, reliability, fitness, comfort, and style became both possible and affordable. GM knew that classes of customers could afford these features and were eager to get them.
Something like this is going on in the Web Services vs XML-over-HTTP (aka, REST) markets. The XML-over-HTTP defenders are the new Ford. They take the position that a simpler system for building web applications is best and will triumph over the seemingly too complex set of web specifications for web services. The web services offenders claim that to build multi-domain enterprise applications, these must be built from composable parts that enable the designer to meet requirements where high reliability, security, fitness to task, and protocol independence are not nice to have, but essential and affordable. This group is emerging as the new GM, willing to step up to the challenges of mastering the web service stacks, of analyzing and correctly configuring enterprise systems, and of providing customization where affordable to classes of customers who are now past the initial learning curve of web applications and want more targeted products with efficient GUIs, great looks, and brandable appeal. Sex still matters.
The Ford group still seems to be of the 'lone hacker' mentality who want to innovate by building small compact systems that do one thing well. The GM group seems to be the team-oriented designers who understand the problems of designing, assembling, and maintaining large and complex systems that must do many things collectively.
For the Ford group, the problem is market share in a market that quickly can reverse engineer any innovation, and then it comes down to sales. This is the same problem of being an independent record producer who has produced a prodigy that might be the next Britney but can't afford to market the prodigy because access to the media is still the biggest expense, so has to put her on the road in the thousand mall tour in hopes a major label will notice her. Slashdot is the thousand mall market with blogs as the in-betweener gigs.
For the GM group, the problem is choosing a development framework that has effective implementations of all of the required web service specifications but does not impede interoperability with systems designed over other frameworks. Here, the choices aren't that many: Microsoft, Oracle, IBM, and Sun with BEA thrown in for their dedication.
Some think that web services will collapse of their own weight. Obviously, XML-over-HTTP is here to stay because it uses the most fundamental web protocols. On the other hand, it doesn't do much to ensure reliability and affordability for systems that need more than "any color as long as it is black" systems.
It seems to me that the Ford crowd is tilting at windmills, to mix my metaphors. If they don't need web services and are happy to build single domain applications, they have what they need to do that. They are wasting their time and a lot of bytes going after the big companies that provide web service frameworks. I think there is a certain amount of the "anything but Microsoft" and "we are the innovators" and "we are Sun and we are on the ropes so let's kick the tires of the competitors" in this movement. On the other hand, the bigCos are also beginning to take their specification development work offline into smaller working groups so that by the time they submit a specification to a standards body, it is proven and close to fielding. Sun has to play there to stay in business and independent developers have to work with them to stay ahead of the learning curve.
Given that the consumers of the frameworks are the real customers and these are development groups, not Mom and Pop at home surfing the web, the new GM has every chance of doing it again because selling enterprise systems is quite profitable in a market that needs both affordability and differentiation. The interoperability of markets that formerly didn't even give each other a passing glance is evident. These market players don't buy from lone innovators. They watch them for evidence of something worth requiring from their usual suppliers, the GMs of the world.
Using the ecosystem metaphor, the XML-over-HTTP players are distributed across the ecosystem in small market niches. The web service players are distributed but their market niches are large and the core technologies they rely on are provided by the large technology vendors who continue to work together on these specifications and implementations, and who are speeding up their work by stepping back from the processes of the specification consortia yet still are committing to standardization and royalty-free specifications. Given that, the work of the XML-over-HTTP community is done but I don't see a new source of energy to enable anything more than linear growth. On the web services side, I see a complex set of specifications, but implementations in the frameworks could substantially increase the applications of these.
The web is no longer a one-size-fits-all market. This comes down to the lifecycle of the enterprise markets (how often do they buy and in what quantity) and the acceptance in developer shops that what they have built with web services can be reused. What is the value of code that is simple but local and not visible on the wire? Does the XML-over-HTTP approach actually become more cumbersome as more complex operations have to be sustained (eg, duplex-messaging), long running transactions are the norm, messages have to last beyond the initial transaction, transactions where HTTP itself isn't the right protocol, where the endpoints even if independently built have to also be secured and versioned while still being composable into higher level blocks yet still be transparent and loosely coupled?
Sheesh.
Those are questions the developers concern themselves with but to the sales and marketing staff, they are as irrelevant as the composition of moondust. That one could make great cement from moondust is meaningless as long as the costs of mining and shipping are too high and effective alternatives are readily available. Even beyond that, a customer buys what a customer wants and the engineers have to build that. HTML was a rotten solution until it became popular. Last year's model of anything sells for less than next year's model. Never undervalue the sex appeal of the product. That is lesson one when selling to the mammals.
GM was willing to tackle the complexity of stratified markets and they dominated the car market over the innovator, Ford. Eventually, Toyota arrived and the higher quality even at higher initial costs took the market from GM. Regardless of the framework and the technique, it still comes down to affordability and quality, and that doesn't mean cheap and easily replaced.
Then, it is a matter of making sexy performant products. The web browser didn't stay grey for long, and two-tone cars with a lot of chrome plus automatic transmissions and power steering and brakes doomed the T-model Fords.
XML-over-HTTP is always there. The question is, is it enough? Smarter people than me don't seem to think so, but the bigger problem may be that the market really doesn't care about that kind of stuff. They want power steering and a sexy body.
No comments:
Post a Comment