Forward to the Past
One session I did catch at the IMA conference was a conversation with Sue Gardner (CBC) and Paul Brannan (BBC) moderated by Tom Mohr (now at Charles River Ventures). Not only do I think these well-intentioned folks are going in the wrong direction, I was disappointed that the 400 public-radio folks in the audience seemed to be thinking the same way. What they heard is the kind of logic that makes emotional sense but simply doesn’t play out in practice. I know my comments will be controversial, and it’s not really my place to criticize high-level people in an industry to which I’m an outsider, but hey…that’s never stopped me before. Someone has to point out the flaws in their strategies.
The right answers aren’t always the ones that “ring true” to one’s gut. Sometimes the right answer isn’t the obvious one. It’s not the one that causes everyone in the audience to nod in hypnotic agreement. Consider needle-exchange programs to reduce the public-health problems associated with IV-drug users’ sharing of needles. At first it sounds like it would only make the problem worse by encouraging IV-drug use, but when you study what’s really going on, you discover quite the opposite is true.
Sue and Paul talked about some of the problems they’re trying to solve, and what were they? Standardization in things like Flash players. Okay, that wasn’t the only example, but it was typical. Sue said CBC suffered from having too many different players on their web sites, and it was part of her job to set a standard for what players the many CBC web sites should use. All I could think was, “You’ve got to be kidding me!” She referred to other problems she’s trying to solve by setting corporate standards, and by centralizing control of various aspects of their web technology. She specifically said something to the effect of not wanting to give their journalists access to certain web technologies so that the journalists would be more productive and to minimize their support requirements.
It’s 1984 all over again. I know; I was there in 1984. (Not at CBC, but the same situation.) The IBM PC was starting to sneak its way into corporate American, and IT departments freaked out. IT managers did everything they could do to control and limit the spread of PCs. They actually threatened users, telling them that if the users installed software that wasn’t approved by IT on their PCs, IT would no longer support their machines. Average users wanted to install Supercalc and later Lotus 1-2-3 to create their own spreadsheets, and the IT folks said this, quite literally: “No, we won’t permit employees to create their own spreadsheets. We don’t have the resources to train them, support them and fix their PCs when something goes wrong. Instead, they should write a request for their spreadhseets and we will schedule them for implementation on the mainframe, which should take no longer than a few weeks.” This wasn’t unusual. This is how it was done. The idea of giving employees tools for which they were not “trained” for tasks not part of the skill sets required for their jobs was considered at best unproductive and at worst a threat to the organization. The same thing happened when email entered organizations the next year. Executives were convinced it would destroy productivity.
We all know what happened. People ignored IT and created their own damn spreadsheets. They bought PCs for home and figured it out on their own. Did they make the most elegant spreadsheets? No. Were the spreadsheets built using “standards” and were they reusable in other applications as those created by IT were supposed to be? No. But they worked and they got the job done and at a fraction of the cost to the organization of the traditional method.
The PC empowered the employees who were lucky enough to get them. The same thing eventually happened with desktop databases and other applications. Eventually everyone was allowed to write their own letters instead of dictating them to stenographers and secretaries. The companies and departments that flourished were those that gave their employees tools that allowed them to explore and experiment and discover unintended consequences. To innovate beyond the scope of what the IT department might imagine for them.
Organizations today should be doing the same. They should not be setting standards for applications, they should be providing tools. Rather than mandate what applications or other software must be used, they should be making sure their data are standardized so that they can be used by any applications. Convert your content to XML and make that a standard, but don’t tell people what they must use to create that data or make use of it. Standardize the formats not the software.
And what’s this about Flash players? Who cares if every web site has a different player or a different skin? If some of them are no good, then let the owners of those sites solve that problem. You might provide information and resources and recommend what Flash players are good, but don’t mandate. As soon as you do, someone will find a better Flash player and want to use it. What are you going to do, fire them for subordination. Don’t waste your time at that level. Standardize on MP3 and even FLV for video (if that’s what you like), but don’t limit the ways in which those files can be played, displayed or syndicated.
Make sure you enable your data and content to be used in as many ways as possible. And don’t (!) try to figure out ahead of time what those ways might be. Don’t waste your time and money with traditional Requirements Analysis meetings and documents. Any attempt to design systems to meet all needs will fail. Guaranteed. The needs will change and they won’t be properly understood in the first place anyway. Instead, just try to understand the data and design a simple and extensible XML schema for it.
Do not (!) specify the applications, operating systems or programming languages to be used. All you’ll be doing is limiting its usefulness. Use the simplest, most interchangeable format you can find — don’t look too far; it’s going to be some variation of XML — and get the data and content into that format ASAP.
Want to go farther? Start developing APIs to existing applications that allow yet-unknown applications to interact with them, extract and (where possible) inject data or invoke functions.
And if you want to learn more, I have a book to offer you. 