May 10, 2004
Beware the Platform I
It’s easy to get sucked into obsessing over the platform. In fact, in coming weeks I’ll probably spend a fair portion of the writing I do here obsessing over the platform. There are a couple of different modes of obsession that bear discussion here. One is obsessing over building a platform. The other is obsessing over requirements for (or, alternatively, coping with) a particular platform. I’ll talk about the first of these here and save the second for a later post.
There’s this seductive lure to the idea of building the ultimate toolkit. You think: if you can build the universal tool, then you can sell it to everyone — wow, that’d be a great business. Plus, it’s so cool to work on the problems involved; platform development is one of the prime arenas for demonstrating technical machismo. The danger is that you can easily work yourself into a big, huge, complicated mess with far too many knobs and dials to ever be usable, and yet too compromised to really be useful. Our experience over the past few years has forced us to accept that different kinds of applications have differently shaped envelopes they want to go in; there is no universal platform.
Nowadays, web application platforms are a huge business, dominated by huge companies like Microsoft, IBM, BEA, and Oracle. A huge portion of the attention (and money) currently being directed to platform issues goes in these guys’ direction.
However, an MMOG or virtual world system does not fit happily into the canonical web application envelope. It’s too interactive, too real-time, and it’s multi-user.
The converse, however, is not necessarily true. One of the things we discovered at State Software (our most recently deceased venture) is that an architecture originally shaped by the needs of virtual world -like applications can really kick ass when it comes to a lot of web-centric, traditional business applications. Starting from server concepts originally evolved for the community social space, we developed a web application platform that was able to offer a level of interactive responsiveness and user interface flexibility that was consistently superior to what could be done with a traditional J2EE or CGI style app server, as well as being able to easily support a variety of real-time and multi-user applications that traditional app servers couldn’t touch. The sheer size of the market made it an attractive target. Even though the big guys can squash you like a bug if they have a mind to, there are so many niches available that you can make a very nice living filling in the cracks that are too small for the big guys to care about.
Unfortunately, the unkind companion lesson was that this didn’t matter. A better paradigm is a different paradigm, and a different paradigm is nearly unsellable. The problem was that in order to enable customers to do things they couldn’t do in app servers (and which they wanted very much to do), they had to do things that you just don’t do in app servers (which was simply unacceptable). We were selling a technically superior solution, but one which asked too much of its customers. It wasn’t that what were asking them to do was hard — you could get proficient in our system in a few days of playing around with it — but we were asking them to adopt a completely different view of application architecture, and that’s just not the kind of change people make without an overwhelmingly compelling reason. We were so small that the only way we could try to give them such an overwhelmingly compelling reason was to try to tell them about our system, and this ran smack up against the you can’t tell people anything problem.
The paradox of the platform business is this:
- Innovation is required
- Innovation is regarded with great suspicion
Our short summary of this was, “the IT guys have it out for you,” but that’s an oversimplification. An application platform is but one component of a much more extended ecosystem that encompasses not only the developer community but the entire supporting cast of consultants, book publishers, trade show organizers, training seminar gurus, industry pundits, standards committees, corporate and institutional IT organizations, and vendors of affiliated technologies — not to mention the customers themselves. Among these diverse interests develops a self-contained, almost hermetically sealed worldview that is very difficult to breach. Our solution was outside that worldview, which made it a very hard sell indeed, notwithstanding the fact that breaking out of that worldview was a prerequisite to solving the problem they wanted solved. Perhaps if we’d had another $5-10 million for marketing we might have been able to do it. On the other hand, perhaps if we’d had another $5-10 million for marketing we might have just pissed away another $5-10 million on marketing and wound up in the same place in the end. In any event, the risk was just too big for anybody (investors or potential customers) to sign up for, and so this technology sits on the shelf.
One might think that taking this technology back to our roots in the games world might make sense. While I’d certainly use this technology as a base if I were starting out to develop an MMOG-type product today, I’m dubious about the broader prospects for a platform business per se. At entirely the other end of the spectrum from business software developers, game developers have historically been much more inclined to roll their own solutions rather than build with what they can get off the shelf. And, while some standards, such as the IP protocol suite or OpenGL, have proven a boon to the game development community, game developers have not been driven by the kind of slavish (one might even say cargo-cultish) obsession with standards that characterizes much business application development. To the extent that game developers remain compelled by competitive pressures always to be pushing the outside of the technical envelope, I suspect this bias towards home-grown solutions will stick with us. Even with all the stuff that’s now available for network application developers, I don’t think this has changed much recently. Couple this with the generally marginal economics of the games business, and I’m inclined to think that the platform business is unlikely to be a winning proposition. I fear that this does not bode well for MMOG platform companies like Zona or Butterfly.net who have positioned themselves in this space, irrespective of whatever merits their products may possess in purely technical terms.
…game developers have not been driven by the kind of slavish (one might even say cargo-cultish) obsession with standards that characterizes much business application development.”
I think this is primarily due to the demographics of the users rather than the developers, don’t you think? Business users want something staid, familiar, and easy(Why doesn’t this work like Hotmail?).. Game users typically want something cool, novel, and different (Hey! That leg bounced off four walls and sprayed blood all over). In no other area of application development does the UI get completely rewritten for every one you do (genre-specific convention aside).
Posted by: sp | May 18, 2004, 2:57 pm
That’s a good point. I think you are probably at least partially on target with respect to the elements of a system that extend out to the user (notably the UI, as you mention). However, this still doesn’t explain the drive within many organizations to embrace standards which are irrelevant or even contrary to their mission, simply because they are standards (I’d put many applications of XML in this category, for example).
Posted by: Chip | May 18, 2004, 7:49 pm