I've been hiding in meeting rooms much
of yesterday and today, talking with the press about this week's announcements
and the state of the market. Yesterday afternoon, I met with three
Japanese journalists for what was one of the best interviews I've done
in a long time.
These guys were prepared! They had excellent questions which reflected the Japanese cultural tendency to think long-term and in multiple directions. I don't speak Japanese, but I know a few of the key phrases and intonations of the language. Combine that with the "Engrish" (romanji character) pronunciation of many of the technical words, and I was able to understand most of the questions even before they had been translated. The eye contact was intense, the laughter reflected in the creases in the corner of the eye, and it all worked despite my constant reminder to myself to say "hai" at appropriate points and never to use the word "no".
So what was the question worth blogging? It was, essentially -- four years ago, you announced a J2EE-based collaboration strategy. It was a two-lane highway. Today we hear a lot of news about ongoing investment and enhancement in the core Notes/Domino technologies, and no two-lane highway. What has changed and why?
I love this question (and I told the Japanese that I do). The question is asked at user groups, by journalists, by CIOs. It requires a philosophical answer, but is one that I get asked enough that I've honed the philosophy.
When Al Zollar stood on that stage four years ago and announced collaboration for J2EE, a number of things drove the decision. The primary two still make perfect sense today.
1) Software is becoming componentized. You can see it in the way IBM and others build solutions today. The new Sametime uses an Eclipse framework, a Codec from someone else, etc. Making components to provide collaborative capabilities is a good idea.
2) J2EE, or alternatively .NET, have become the primary languages for application developers. The forecast in 2002 was that by 2005, 80% of all new apps would be written in one or the other. I don't think it happened that way -- for a variety of reasons, I think the number is lower. But it is still a fact that a new computer science graduate from unversity is more likely to be focused on Java or .NET than anything else. And convincing them learn to develop in Domino Designer is a challenge, because it's "proprietary" to one (albeit incredibly popular) platform.
So we had to start getting behind one of these development platforms, and as IBM, it makes sense that we chose Java. The Workplace Collaboration Services, and many of the Workplace-branded products, reflect this. But a funny thing happened on the way to J2EE-based collaboration -- market adoption of Notes/Domino continued, and more importantly, existing customers grew their Domino investments through larger user populations and increasing numbers of applications.
The problem with the "two-lane highway" was that there was an implication you would eventually have to move to the other lane, and it would take some superhuman feat to do so. There's no ROI in migration, and IBM -- unlike our primary competitor -- just don't believe in it. So instead of following separate and parallel development paths, we started finding ways to integrate the new, Java-based, componentized technologies with the existing Notes/Domino products.
This results in several things you saw/heard yesterday -- at the client side, Notes integrates with the Workplace Managed Client as a plug-in. The next version of Domino will integrate portal technologies into the server. They are still Notes and Domino -- running every Notes application that you do today, with no architectural changes required. But now we integrate the Activities model into Notes; we integrate the components into Notes (Sametime 7.5 will provide the IM plug-in for Notes "Hannover"). It becomes the best of all worlds -- continuing investment and innovation for the products in use by 61,000 customers today, while adopting for the "nextgen" of Java-based programming. Tools like IBM Workplace Designer help bridge the two, by providing a Java-based development tool that works like Domino Designer. In a future version, it will even build rich client applications.
I have been at Lotus through this entire transition and journey. And when I see what the development team has done to leverage our strengths and heritage, combined with tooling for the future, it makes me incredibly proud to be a part of all of this. We're doing what's right for customers, not just what's convenient for us (whehter that be a 64-bit migration or an obsolesence of existing product APIs). It takes more work, but the best and the brightest are making it happen. And the best part is, it has made Notes even more powerful, and more useful, for the next sixteen years of its lifecycle.