With about 41,000 attendees, 1,800 sessions, and a whooping 63,000-plus slides, Oracle OpenWorld 2010 (September 19-23) in San Francisco was certainly a mega event with more information than one could possibly digest or even collect in a week. While the main takeaway for every attendee depends, of course, on the individual’s area of interest, there was a strong focus this year on hardware due to the Sun Microsystems acquisition. I’m a strong believer in the integration story of “Hardware and Software. Engineered to Work Together.” and really liked the Iron Man 2 show-off all around the event; but, because I’m an application guy, the biggest part of the story, including the launch of Oracle Exalogic Elastic Cloud, was a bit lost on me. And the fact that Larry Ellison basically repeated the same story in his two keynotes didn’t really resonate with me — until he came to what I was most interested in: Oracle Fusion Applications!
A recent conversation with executives from Clarizen, a software company in the work/project/task management realm, shows how profoundly SaaS can change the innovation process in technology companies. However, you won't get the most beneficial changes unless you're willing to make an investment.
During our briefing, I asked the CEO of Clarizen, Avinoam Nowogrodski, and the VP of Marketing, Sharon Vardi, whether being a SaaS vendor made it any easier to resolve the sort of questions that vex technology vendors. Their response: "Of course it does."
Here's one of those vexing questions: Why don't more customers move from a pilot to full adoption? The usual first answers blame someone else's department for the disappointing conversion rate: Your product stinks. Your leads stink. Your salespeople stink.
Round-robin finger-pointing like this thrives in an informational vacuum. If the only hard fact available is the conversion rate, marketing can accuse sales of presumed incompetence; sales can claim that the current bug count might have an effect on customer satisfaction; development can claim that it's bogged down in too many special requests from strategic customers; and so on.
During last August's Agile 2010 conference, I attended a session that used a board game to simulate the collaboration between developers and UX professionals. The object of the game was to coordinate the schedules of these two groups, who normally follow the beats of different metronomes. On top of that basic timing challenge, unexpected events complicated this dance between development and UX.
While this session does show a novel application of serious gaming (one of my favorite topics, in case you hadn't noticed), the interesting aspect of this session is that it happened at all. Until recently, UX was not a major concern for Agilists – or most people developing software, for that matter. The phrase, "And then we'll throw a UI on top of it," summarized the indifference of all too many development teams to UX concerns.
In the last few years, many teams have learned a new attitude. Instead of treating UX as a tarpaulin, thrown over the application to clumsily hold it all together, UX is as much a part of the system as the technical architecture or the application logic.