To steal a meme from the Nicholas Carr article that rocked the IT world two years ago — does IT matter when it comes to organizing and operating an online publishing environment?
Carr’s thesis was that IT doesn’t matter, or at least doesn’t confer sustainable competitive advantage to an organization, and that while vital to business operations, should be managed as a utility on a cost basis. This pushes the question of what, if anything, a web publisher should build inhouse or seek outside from the market.
As I am in the throes of an infrastructure rebuild, I can point to some fundamental assumptions about what technology needs to be directly under the control of the publisher, and what can be sourced elsewhere.
Beginning at the bottom of the "stack" — the server environment — few, if any publishers have ever considered a self-hosted environment where the racks were housed on their premises and managed onsite by their sysadmins. Decisions about operating systems, application servers, backend databases, have depended on cost constraints, the existing skills of the technology management team, and vendor preferences. At Forbes.com we launched into a Microsoft IIS/ASP environment because it appeared to be well supported and offered some environmental conditions — particularly in database publishing — that were compelling. Inevitably we had to suck it up and migrate to an Apache/Java world, which caused our developers and tech team a world o’hurt. Today — the preferred environment for many sites is LAMP, by its opensourced nature a commodity environment that further commoditizes further application development by opening up a wide community of opensource third-party apps ranging from WordPress for blogs to MediaWiki for Wikis.
Above the OS lies the tricky part: the content management system, ad serving system, and third party apps.
As I look at CMS options I’m restricting my intial scan of the market to five choices. They are:
- The incumbent home-grown solution (custom CMS development is a viable option, and indeed, the end state, even for customers of off-the-shelf solutions that require a high-degree of customization to fit their particular environment and variables)
- An open source solution — Bricolage, etc.
- A commercial solution I have experience with (in this case, Interwoven Teamsite)
- A hosted solution. ie, Websidestory’s Atomz
- A player to be named later
Continuing with custom development for the CMS forces the question "Should we develop such a system?" All technology sourcing questions — which it can be argued come down to build vs. buy? — need to assess staff capabilities and capacity against those functions which confer strategic competitive advantage and those which are "lights on/table-stakes" for staying in the game. Does a CMS confer strategic advantage? Should it be purchased versus developed? Would purchasing technology free internal application developers to focus on those activities which do confer competitive differentiation?
A great deal of internally developed web publishing tools were a matter of survival and economics — we need it, we can’t afford it, so we’ll build it.
The net of this scenario is cheap economics, and indeed, tailored apps, the result can be undocumented software which is a bear to train on, get users to adapt to, etc.
More to say on this topic anon …
