It used to be that when you flew on shuttle from Boston to New York (or vice versa) you'd see a bunch of magazines laid out for you to pick up at the gate - all for free. That's the only place in the US where I've seen that. When you fly from California to Chicago or Denver or Boston or New York, there are no free magazines. And you never see free magazines at the gate for flights between Northern California (SFO, OAK, SJC) and Southern California (LAX, SAN, BUR, SNA). But on that shuttle flight between BOS and EWR, there they were. So you pick one up, and half the time you end up not even reading it.
If that seems like strange behavior for distribution and consumption of a magazine, consider the fact that we behave the same way in downloading apps for our iPhones. If you have more than three screens' worth of apps, I bet there's at least one that you downloaded but haven't even tried yet.
People who don't have an iPhone find it crazy that people will download a good number of iPhone apps that they use for a couple of weeks before abandoning, or they end up not using them at all. The odd thing is that a surprising set of applications that seemed trivial at first have stayed on our phones as regular stand-by apps.
First of all, by calling these things "applications" we're already confusing ourselves. Because of the mobile device context, these apps must be extremely simple, intuitive and useful. So we expect to be able to pick them up without any need for a "user's manual" or even a "getting started guide." While we call them applications, they bear no resemblance to the things that we used to install by inserting multiple floppy disks into a personal computer. They're more intuitive than most websites.
Secondly, we can acquire and dispose of these apps as easily as a song. People with years of experience in the "mobile industry" like to kvetch that there have been "mobile application stores" for years. But the fact that the iPhone app store put them all to shame so quickly indicates that these mobile app mavens didn't know what they didn't know.
Lastly, we - the phone owners - are changing. For years we have consumed entertainment - especially music - and gladly discarded last year's hits in favor of new sensations. But that was content that required little conscious attention. Games are actually more interactive, so we have a more conscious, interactive engagement with them, as well as a more conscious decision when we dropped one in favor of another. But mobile applications are a step beyond games. Like games, apps are interactive, but more significantly, they play a critical role in our "real lives."
The iPhone apps we choose to keep become our companions in our daily lives, and the ones we choose to discard (no hard feelings, right?) are dropped after days and weeks of trying to fit them into our lives. I'm not kidding about this. People actively debate which weather app makes the better call on the hour-by-hour forecast, or which shopping app finds the best prices. And let's not even start with Gowalla versus FourSquare.
Forget about "augmented reality" that requires heads-up-displays and real-time 24x7 cameras. Millions of people are augmenting their realities every day through their iPhones. Grok that, and you see the seismic shift that Apple created that everybody else has to keep up with.
We arrived at this point not by careful planning and strategic selection of the best applications for mobile users, but by the establishment of a big, imperfect marketplace for mobile applications. Nothing in the future is guaranteed. But the lesson is there for us to see: the future of the mobile experience will be characterized by hundreds of thousands of options, and consequently, individuals trying out hundreds or even thousands of application experiences, most of which will be abandoned.
So here's to the disposable mobile app. It's a sign that we're going in the right direction.
Wednesday, April 28, 2010
Tuesday, April 27, 2010
Three Types of Expertise
It's commonly accepted that there are two types of knowledge - "knowledge about" and "experience doing." The former can be acquired by studying, but the other kind of understanding comes through hands-on experience. Both are necessary. Conventional wisdom favors real world experience over book learning. But the ability to step back from a situation and objectively examine all your options requires both kinds of knowledge.
I'm a big fan of my kids' pediatrician, Dr. Joe. A good while back, before my oldest could speak, she suddenly stopped eating. She would literally burst into tears whenever she put anything in her mouth. Even a sip of juice would spark a painful outburst. As new parents, my wife and I were confused and worried. But when we brought her in to Dr. Joe, he identified the problem with one glance inside her mouth. She had stomatitis on the back of her tongue - a painful infection that went away in a couple of days.
That experience got me thinking - you might know enough about stomatitis to pass exams medical school, maybe even do well in a pediatric internship, but with the average doctor seeing scores of patients a day, can you catch it and diagnose it correctly within seconds on the first visit? That's the difference that practical experience makes. Dr. Joe knew that the infection is most common in one and two-year-old children (all that drooling gives a lot of opportunities for oral infection). What's more, Dr. Joe's protocol for a pediatric exam led directly to the tell-tale symptoms on the tongue.
I'm not saying that a younger, less experienced doctor would have missed the call. But this is just an example of the difference made by decades of practical experience.
Here's another example: when our second child was a newborn, he was feeding irregularly so he lost more weight than he should have. Dr. Joe put us on a strict feeding schedule, which we followed precisely for the next four days. At our next visit, the nurse weighed the baby and entered his weight on the chart. According to the chart, it seemed that our baby was continuing to lose weight. Dr. Joe interviewed us in detail. Had we stuck to the feeding regimen? We assured him that we had. Well, he said, there's only one explanation. He went over to the infant scale, calibrated it carefully to zero (which the nurse had forgotten to do), and weighed the baby again. Much to our relief, the baby had in fact gained weight.
In our most recent visit to Dr. Joe, I encountered a third kind of expertise. Our younger child had developed a respiratory infection, and Dr. Joe prescribed the appropriate antibiotics to treat the infection, as well as medicine to reduce the swelling of the airway, to facilitate breathing. He was adamant that we monitor the boy's health very carefully (you don't mess around with respiratory infections, he advised us) and come back for a follow-up visit in two days. The follow-up visit was with one of Dr. Joe's colleagues, and I was impressed by how much her protocols and treatment were in synch with Dr. Joe's. What's more, she told us that this respiratory bug had been going around for more than a month and it was a tough one. It might take two rounds of antibiotics, but with consistent treatment we would clear it up.
That led me to think about the third kind of expertise - an awareness of what's currently happening in your field. In a larger practice, with a team of doctors that communicate well, there's a collective intelligence that's aware of the most currently relevant information. Later, as the current bugs and drugs and research are displaced by newer issues, the "currently relevant information" becomes "experience" - which might be summed up as "previously relevant information that is now possibly future-relevant experience."
We take this transformation for granted - it's captured in the heads of doctors in a practice. But if you were to look for it in the practice's records - those enormous shelves of patient charts, you wouldn't find it.
In the business world, one of the key benefits of the new "Enterprise 2.0" technologies is that they give knowledge workers an effective means to complement their "book knowledge" and official reports with the other two kinds of knowledge. People can communicate their first-hand experience in a timely manner, so relevant expertise is both shared and discovered more easily. In addition, communication is more current and timely than it could be in tradition systems that were designed to archive documents. Inevitably, a system that works this way will seem more conversational in nature, which might give the impression that it's less "professional." But to dismiss conversational communication as less professional is to mistake form for substance.
The Tayloristic mind-set sees a water cooler conversation happening in a social network and thinks "those people should get back to work." But in fact, knowing each other - and what each of us is currently working on or seeing in our work - that is our work. Perhaps by thinking about the three types of expertise we might help people to understand this idea better. What do you think?
I'm a big fan of my kids' pediatrician, Dr. Joe. A good while back, before my oldest could speak, she suddenly stopped eating. She would literally burst into tears whenever she put anything in her mouth. Even a sip of juice would spark a painful outburst. As new parents, my wife and I were confused and worried. But when we brought her in to Dr. Joe, he identified the problem with one glance inside her mouth. She had stomatitis on the back of her tongue - a painful infection that went away in a couple of days.
That experience got me thinking - you might know enough about stomatitis to pass exams medical school, maybe even do well in a pediatric internship, but with the average doctor seeing scores of patients a day, can you catch it and diagnose it correctly within seconds on the first visit? That's the difference that practical experience makes. Dr. Joe knew that the infection is most common in one and two-year-old children (all that drooling gives a lot of opportunities for oral infection). What's more, Dr. Joe's protocol for a pediatric exam led directly to the tell-tale symptoms on the tongue.
I'm not saying that a younger, less experienced doctor would have missed the call. But this is just an example of the difference made by decades of practical experience.
Here's another example: when our second child was a newborn, he was feeding irregularly so he lost more weight than he should have. Dr. Joe put us on a strict feeding schedule, which we followed precisely for the next four days. At our next visit, the nurse weighed the baby and entered his weight on the chart. According to the chart, it seemed that our baby was continuing to lose weight. Dr. Joe interviewed us in detail. Had we stuck to the feeding regimen? We assured him that we had. Well, he said, there's only one explanation. He went over to the infant scale, calibrated it carefully to zero (which the nurse had forgotten to do), and weighed the baby again. Much to our relief, the baby had in fact gained weight.
In our most recent visit to Dr. Joe, I encountered a third kind of expertise. Our younger child had developed a respiratory infection, and Dr. Joe prescribed the appropriate antibiotics to treat the infection, as well as medicine to reduce the swelling of the airway, to facilitate breathing. He was adamant that we monitor the boy's health very carefully (you don't mess around with respiratory infections, he advised us) and come back for a follow-up visit in two days. The follow-up visit was with one of Dr. Joe's colleagues, and I was impressed by how much her protocols and treatment were in synch with Dr. Joe's. What's more, she told us that this respiratory bug had been going around for more than a month and it was a tough one. It might take two rounds of antibiotics, but with consistent treatment we would clear it up.
That led me to think about the third kind of expertise - an awareness of what's currently happening in your field. In a larger practice, with a team of doctors that communicate well, there's a collective intelligence that's aware of the most currently relevant information. Later, as the current bugs and drugs and research are displaced by newer issues, the "currently relevant information" becomes "experience" - which might be summed up as "previously relevant information that is now possibly future-relevant experience."
We take this transformation for granted - it's captured in the heads of doctors in a practice. But if you were to look for it in the practice's records - those enormous shelves of patient charts, you wouldn't find it.
In the business world, one of the key benefits of the new "Enterprise 2.0" technologies is that they give knowledge workers an effective means to complement their "book knowledge" and official reports with the other two kinds of knowledge. People can communicate their first-hand experience in a timely manner, so relevant expertise is both shared and discovered more easily. In addition, communication is more current and timely than it could be in tradition systems that were designed to archive documents. Inevitably, a system that works this way will seem more conversational in nature, which might give the impression that it's less "professional." But to dismiss conversational communication as less professional is to mistake form for substance.
The Tayloristic mind-set sees a water cooler conversation happening in a social network and thinks "those people should get back to work." But in fact, knowing each other - and what each of us is currently working on or seeing in our work - that is our work. Perhaps by thinking about the three types of expertise we might help people to understand this idea better. What do you think?
Tuesday, February 16, 2010
Being On Time
Jeffery Zeldman has posted a wonderful article about being on time. The message is obvious:
The post is compelling because Zeldman places the reader not in the shoes of the person is perpetually late, but the others, who made major and minor sacrifices to be on time, and are left waiting.
Punctuality has always been one of my pet peeves, especially in business, and it's hard to reconcile with people who just don't make it a priority. The thing is, if I arrive early, I don't feel like I've wasted the time I could have put to better use by leaving later. Rather, I put those extra minutes to some good use - checking a to-do list, reading a book or a magazine, or simply relaxing and mentally preparing for my appointment.
On the other hand, if I spend my journey rushing in nervous anticipation of arriving late, even if I arrive on time, I still feel edgy from the trip. If a meeting isn't worth an early arrival, maybe it's not worth having at all.
"If you plan to arrive early, then you are covered when circumstances beyond your control conspire to make you late.
"This is simple and obvious but many otherwise brilliant professionals clearly don’t think about it. The result is that they often arrive late. It’s never their fault, and yet it’s always the same people who are late."
The post is compelling because Zeldman places the reader not in the shoes of the person is perpetually late, but the others, who made major and minor sacrifices to be on time, and are left waiting.
Punctuality has always been one of my pet peeves, especially in business, and it's hard to reconcile with people who just don't make it a priority. The thing is, if I arrive early, I don't feel like I've wasted the time I could have put to better use by leaving later. Rather, I put those extra minutes to some good use - checking a to-do list, reading a book or a magazine, or simply relaxing and mentally preparing for my appointment.
On the other hand, if I spend my journey rushing in nervous anticipation of arriving late, even if I arrive on time, I still feel edgy from the trip. If a meeting isn't worth an early arrival, maybe it's not worth having at all.
Tuesday, December 15, 2009
Does your Alma Mater help you find job opportunities?
I had an interesting experience today. At work, we're recruiting for a specialized position, the kind that you have to have a certain kind of advanced degree for. There are a good number of graduate programs whose alumni would be ideal for this job, and given the current unemployment situation in the US, I thought that approaching these schools' alumni networks would be worth a try.
What made my quest particularly interesting was the mixed results that I had. Before I say more, I should say that we are gladly paying both generic job sites and specialist industry associations to list the position. But I wanted to reach out through alumni networks as well, because graduate programs' alumni networks tend to be a good resource for job-seekers, even years after graduating.
Some of the best programs (Carnegie Mellon and University of Texas stand out in my mind) make it dead simple for employers to post job listings. Best of all, their programs have a very straightforward navigation to an "Employers" button that led to an e-mail link or a web form to submit a job description. You'd think that this would be pretty obvious - after all, these are professional programs whose graduates expect to go on to successful careers. But surprisingly less than half of the sites I viewed made it clear how an employer could list positions for interns, new graduates or alumni. One of the worst offenders in this regard had an absolutely beautiful site - as long as you are a prospective student who wants to learn about the program's courses and faculty (which are top-tier). But if you're an employer wondering how to reach those students, good luck.
Most sites had an e-mail address for an actual human being - an important feature. But a surprising number of programs had links for employers that led to complicated registrations. What's more, in many of these programs, once past the complicated registration process, the site required payment to post the job. As I said, we have gladly paid job sites and specialist associations to carry our job posting. But it's just impractical to fork over several hundred dollars to every academic program in the country.
My question is - if you're a graduate that spent thousands of dollars and years of your life to earn your advanced degree, and you give what you can as a loyal alumnus of your university's graduate program, are you being shortchanged if they drive prospective employers away? In times like these, shouldn't your alma mater be one of your best sources of opportunity, rather than a gatekeeper that charges prospective employers for the privilege of communicating to its students and alumni?
Thursday, October 8, 2009
News Flash: Twitter down, millions get back to work
Like everybody else, I was mildly surprised to see my Twitter updates grind to a halt this morning. So I had a good old-fashioned conversation (analog, face to face) with some folks I work with, and then I went back to work.
Oh, and I wrote this. What surprised me was how shutting off my Twitter client gave me the same kind of feeling I have when I hear that a meeting has been canceled. "Oh great, I get an hour of my life back!"
Did you feel the same way? Does this indicate a "Twitter problem"?
Friday, September 18, 2009
Two new sound apps for the iPhone
I just noticed that my most recent receipt from the iTunes store includes two purchases, both sound apps, that were purchased separately, and certainly in different frames of mind:
1 Army of Darkness Soundboard, v1.0, Seller: MGM Studio
2 Air, v1.0, Seller: Opal Limited
The first one let's me play "Give me some sugar, baby" as a ringtone. The second lets me re-arrange the sounds of Brian Eno's ambient soundscape "Music for Airports".
I like 'em both. That's why when people say there's no need for any more iPhone apps, I think "well, maybe not for you..."
1 Army of Darkness Soundboard, v1.0, Seller: MGM Studio
2 Air, v1.0, Seller: Opal Limited
The first one let's me play "Give me some sugar, baby" as a ringtone. The second lets me re-arrange the sounds of Brian Eno's ambient soundscape "Music for Airports".
I like 'em both. That's why when people say there's no need for any more iPhone apps, I think "well, maybe not for you..."
Saturday, February 14, 2009
Builders and Shoppers
In the IT world, I think there are two types of decision-makers: Builders and Shoppers. A Builder is a person who investigates how new technologies might enable new approaches to current needs. A Builder might study a new technology and ask - how would we work differently if we used this? Would things be better somehow? In contrast, a Shopper usually learns about a new technology in the context of a product evaluation.
Builders are not simply do-it-yourself types. Builders try new products all the time. Builders are extremely interested in knowing what leading technology providers are coming up with. So it's wrong to say that the difference between Builders and Shoppers is that Builders will only build solutions and Shoppers can only buy solutions. But I think it's fair to say that Builders set the direction and definition for their objectives independently of what's commercially available, while Shoppers tend to rely more on product claims to set the direction of their project and define requirements.
There's also a difference between Builders and Shoppers after a technology has been implemented. Builders accept the fact that new requirements will emerge, and that even after project is "done" there will inevitably be a second project based on changes in the business's operations or emerging requirements. Shoppers tend to see a project as "done" until the vendor releases an upgrade or patch.
When I began working with Web services some ten years ago, I found that one of the greatest problems we had to overcome was helping line-of-business managers understand why they would want to use Web services to do anything. Web services were a technology solution looking for a business problem, so within different organizations they were advocated in a variety of ways:
- As a better, faster cheaper kind of EAI.
- As the back-end connectivity for B2B integration projects.
- As the secret sauce in next-generation portals.
- As the secret sauce in next-generation business intelligence
- As a short-cut to customer data integration.
- As the foundation for improved BPM.
- As a mechanism for consolidation of IT operations.
Looking back on these messages, I can see that some of them were designed for Shoppers - Web services can displace an expensive EAI application, portal solution or some other product. Other messages were designed for Builders - consolidate IT operations, or improve BPM.
But the challenge we faced was that while most enterprises were thinking like Shoppers, the greatest benefits of Web services only resonated with people who thought like Builders. Web services were a new way to provide interfaces for applications. The question was - what capabilities could we (or should we) build on the organization's existing applications (and new ones as well) with this new type of interface? To really get excited about Web services required the imagination of a Builder.
Then, as always happens with new technology, all of a sudden every enterprise technology product or service was labeled a "Web Services" offering as well. In a desperate attempt to convince the Shoppers that they weren't missing out on an essential technology, a "Web Services" sticker was put on every box -- the enterprise IT equivalent of "Zero Trans-Fats" or "Heart Healthy".... And so confusion reigned.
Where were the experts in all of this? Many of them were right there in the trenches, working with the Builders to get things right, sharing knowledge and designing architectures that would have previously been very difficult, if not impossible, to manage and maintain. Many experts weighed in with thoughtful, detailed analyses of the major vendors' efforts and cautioned against the perils of thinking like a Shopper when making Builder decisions.
But too many experts became a kind of "super-Builder". They veered off into the weeds, piling complexity on top of confusion. Dogmatic debates over architectural principles led to a tangle of standards that almost nobody even tried to use. Different vendors supported entirely incompatible families of Web services standards, which had the ironic result of turning a technology that was supposed to be both vendor and technology neutral into yet another means to lock a customer's architecture into a single vendor's product line.
Meanwhile, many in the open source and hacker community - rather than taking sides in a fight they had no stake in - took a different course. Many began stripping out the bits that they didn't need. Such hackery wasn't sanctioned by standards committees, but it was the slow pace of those bodies and (for some) their closed-doors discussions that had frustrated the technologists in the first place. Besides, given the choice between standards compliance and just getting the job done, the hackers chose the latter.
Across technology domains, there has been a steady divergence between the simplicity of lightweight technologies and the complexity of "enterprise" technologies. It would be wrong to say that one trend has been driven by Builders and the other by Shoppers. Builders are involved in everything, but while the deep pockets of the Shoppers kept the enterprise technologies moving forward, it was a groundswell of Builder communities that enabled lightweight technologies to flourish as they have.
As the Java Enterprise Edition specifications grew more sophisticated, developers flocked to Tomcat, POJOs and the Spring Framework. For every student in an expensive RDBMS class, a hundred developers downloaded MySQL and began to tinker. As Web services specifications became impossibly convoluted, the practice of caching a bit of XML on the browser (which had been going on for years without any official industry-wide sanction) was suddenly blessed with the wonderfully marketable acronym AJAX (Asynchronous Javascript and XML). Lightweight technologies didn't eliminate the need for more robust ones. But they did empower Builders to choose the right tool for each job, depending on the criticality of its function and operational requirements.
And as they did so, an interesting thing happened. Many of the "lightweight" technologies overtook their "enterprise" counterparts. Giant server farms running MySQL on Linux, open source Java technologies, and a host of other proof points showed that the price-performance trade-off had become a scatterplot - "most expensive" no longer meant "most reliable" or "best performing", and you needed Builders to figure out the real story.
Now we are living in a world of Web 2.0, cloud computing, open source, and phones that behave like computers. Our systems are mashed-up, distributed and accessible from our iPhones. We still live in a world of Builders and Shoppers, but the number of Builders continues to expand. Implementations of the Apache web server, GNU-Linux operating system and MySQL database number in the millions. Within the first two years after opening the Google Maps API, more than 50,000 mashups were built. In the six months following the launch of Apple's iTunes App Store, some 15,000 applications have been made available for the iPhone. The Builders are taking over.
So where are the Shoppers? They're still alive and well, mostly in corporate IT departments. Organizational structures and policies evolve slowly, so corporate IT Shoppers are relatively safe, with RFP processes and lists of Approved Vendors. But there's a problem - while the options available to Builders have exploded, the Shoppers are looking at almost the opposite scenario. Driven by Builders' curiosity and creativity, options for programming languages, platforms and frameworks have proliferated. Driven by Shoppers' financial constraints, the software industry is consolidating. It's true that the Builders' world may seem chaotic and fraught with risk. But the Shoppers' world is suffering from a diminishing range of choices.
Of course, no organization is purely Shoppers or purely Builders. But I'm sticking with my distinction, because I think that an IT organization tends to have one kind of culture or the other. Also, it gives some perspective on Nick Carr's famous question "Does IT Matter?" If you've worked in an organization that has an IT culture of Builders, you know that it matters. If you depend on superior knowledge work or operational performance for competitive advantage, I hope your IT organization has a Builder culture. It does matter. A lot.
Builders are not simply do-it-yourself types. Builders try new products all the time. Builders are extremely interested in knowing what leading technology providers are coming up with. So it's wrong to say that the difference between Builders and Shoppers is that Builders will only build solutions and Shoppers can only buy solutions. But I think it's fair to say that Builders set the direction and definition for their objectives independently of what's commercially available, while Shoppers tend to rely more on product claims to set the direction of their project and define requirements.
There's also a difference between Builders and Shoppers after a technology has been implemented. Builders accept the fact that new requirements will emerge, and that even after project is "done" there will inevitably be a second project based on changes in the business's operations or emerging requirements. Shoppers tend to see a project as "done" until the vendor releases an upgrade or patch.
When I began working with Web services some ten years ago, I found that one of the greatest problems we had to overcome was helping line-of-business managers understand why they would want to use Web services to do anything. Web services were a technology solution looking for a business problem, so within different organizations they were advocated in a variety of ways:
- As a better, faster cheaper kind of EAI.
- As the back-end connectivity for B2B integration projects.
- As the secret sauce in next-generation portals.
- As the secret sauce in next-generation business intelligence
- As a short-cut to customer data integration.
- As the foundation for improved BPM.
- As a mechanism for consolidation of IT operations.
Looking back on these messages, I can see that some of them were designed for Shoppers - Web services can displace an expensive EAI application, portal solution or some other product. Other messages were designed for Builders - consolidate IT operations, or improve BPM.
But the challenge we faced was that while most enterprises were thinking like Shoppers, the greatest benefits of Web services only resonated with people who thought like Builders. Web services were a new way to provide interfaces for applications. The question was - what capabilities could we (or should we) build on the organization's existing applications (and new ones as well) with this new type of interface? To really get excited about Web services required the imagination of a Builder.
Then, as always happens with new technology, all of a sudden every enterprise technology product or service was labeled a "Web Services" offering as well. In a desperate attempt to convince the Shoppers that they weren't missing out on an essential technology, a "Web Services" sticker was put on every box -- the enterprise IT equivalent of "Zero Trans-Fats" or "Heart Healthy".... And so confusion reigned.
Where were the experts in all of this? Many of them were right there in the trenches, working with the Builders to get things right, sharing knowledge and designing architectures that would have previously been very difficult, if not impossible, to manage and maintain. Many experts weighed in with thoughtful, detailed analyses of the major vendors' efforts and cautioned against the perils of thinking like a Shopper when making Builder decisions.
But too many experts became a kind of "super-Builder". They veered off into the weeds, piling complexity on top of confusion. Dogmatic debates over architectural principles led to a tangle of standards that almost nobody even tried to use. Different vendors supported entirely incompatible families of Web services standards, which had the ironic result of turning a technology that was supposed to be both vendor and technology neutral into yet another means to lock a customer's architecture into a single vendor's product line.
Meanwhile, many in the open source and hacker community - rather than taking sides in a fight they had no stake in - took a different course. Many began stripping out the bits that they didn't need. Such hackery wasn't sanctioned by standards committees, but it was the slow pace of those bodies and (for some) their closed-doors discussions that had frustrated the technologists in the first place. Besides, given the choice between standards compliance and just getting the job done, the hackers chose the latter.
Across technology domains, there has been a steady divergence between the simplicity of lightweight technologies and the complexity of "enterprise" technologies. It would be wrong to say that one trend has been driven by Builders and the other by Shoppers. Builders are involved in everything, but while the deep pockets of the Shoppers kept the enterprise technologies moving forward, it was a groundswell of Builder communities that enabled lightweight technologies to flourish as they have.
As the Java Enterprise Edition specifications grew more sophisticated, developers flocked to Tomcat, POJOs and the Spring Framework. For every student in an expensive RDBMS class, a hundred developers downloaded MySQL and began to tinker. As Web services specifications became impossibly convoluted, the practice of caching a bit of XML on the browser (which had been going on for years without any official industry-wide sanction) was suddenly blessed with the wonderfully marketable acronym AJAX (Asynchronous Javascript and XML). Lightweight technologies didn't eliminate the need for more robust ones. But they did empower Builders to choose the right tool for each job, depending on the criticality of its function and operational requirements.
And as they did so, an interesting thing happened. Many of the "lightweight" technologies overtook their "enterprise" counterparts. Giant server farms running MySQL on Linux, open source Java technologies, and a host of other proof points showed that the price-performance trade-off had become a scatterplot - "most expensive" no longer meant "most reliable" or "best performing", and you needed Builders to figure out the real story.
Now we are living in a world of Web 2.0, cloud computing, open source, and phones that behave like computers. Our systems are mashed-up, distributed and accessible from our iPhones. We still live in a world of Builders and Shoppers, but the number of Builders continues to expand. Implementations of the Apache web server, GNU-Linux operating system and MySQL database number in the millions. Within the first two years after opening the Google Maps API, more than 50,000 mashups were built. In the six months following the launch of Apple's iTunes App Store, some 15,000 applications have been made available for the iPhone. The Builders are taking over.
So where are the Shoppers? They're still alive and well, mostly in corporate IT departments. Organizational structures and policies evolve slowly, so corporate IT Shoppers are relatively safe, with RFP processes and lists of Approved Vendors. But there's a problem - while the options available to Builders have exploded, the Shoppers are looking at almost the opposite scenario. Driven by Builders' curiosity and creativity, options for programming languages, platforms and frameworks have proliferated. Driven by Shoppers' financial constraints, the software industry is consolidating. It's true that the Builders' world may seem chaotic and fraught with risk. But the Shoppers' world is suffering from a diminishing range of choices.
Of course, no organization is purely Shoppers or purely Builders. But I'm sticking with my distinction, because I think that an IT organization tends to have one kind of culture or the other. Also, it gives some perspective on Nick Carr's famous question "Does IT Matter?" If you've worked in an organization that has an IT culture of Builders, you know that it matters. If you depend on superior knowledge work or operational performance for competitive advantage, I hope your IT organization has a Builder culture. It does matter. A lot.
Subscribe to:
Posts (Atom)
Posts
