Today, for the second time this year, I had the opportunity to join Lotus Vice President Kevin Cavanaugh at a customer meeting. Until recently Kevin was the Vice President for Notes / Domino development, but now runs the messaging and collaboration business. Although I spend a lot of time talking about our products, it’s always useful to hear someone talk the talk and give their perspective – and when it’s the guy who’s been in charge of building the products for several years, it’s a good time to shut up and listen.
With version 8 there’s been a lot of focus on the client, but the Domino server seems to be the unsung hero. One of the things that struck me as Kevin laid out the strategy for the customer was how much the product has grown and improved over the past few years. Of course it should grow and improve, but the remarkable fact is that all these improvements have not required a change in the architecture – it’s been consistent for years and will remain consistent in years to come.
Kevin waxed lyrical about the performance improvement goals that he kept setting for the development team… which they kept on achieving. If you’ve seen my presentation on either version 7 or 8 you may remember a chart which shows the scalability improvements from 6.5 to 7 – the scalability on some platforms (Windows and pSeries) increased by 50%, but that was bettered by the whopping 80% on iSeries (sorry, System i) and Solaris. The team did such a great job on reduction of CPU usage in 7 and 8.0 that they then had to focus on I/O so that the server could catch up with itself (that’s layman terms).
Add to that the news posted by Rob Ingram on the Domino Blog this week… the database compression work planned for delivery in a later version was to be brought forward to Domino 8.0.1 – in other words, a capability delivered earlier than expected. Rob explains that the new compression technology reduces database sizes (and that includes mail boxes) by around 40%. This in turn has a beneficial effect on the I/O which in turn benefits the server performance. And we haven’t even played the 64-bit card yet (that’s coming soon).
Now, let’s re-iterate something here. All of these improvements have been delivered on a consistent architecture, one which has evolved but has not required rip-and-replace operations. I always make the point that I would never trivialise the process of upgrading from one version to another, but I make no bones about proudly showing the presentation slide in which the server versions are joined by lines labelled “upgrade”. Even if a customer jumps a version (e.g. 5 to 7 as some customers are now doing) it’s still an upgrade. There’s no requirement to migrate data or move mail boxes from one server to another. And although we can’t see into the future (this is just arse-covering) there are no plans to make this necessary. Why should we? The architecture is solid and keeps improving.
That slide I mentioned… upgrade, upgrade, upgrade, skip versions if you want, co-exist versions… ask those guys from Redmond to show you their version of that slide. I’ve drawn it myself and it’s not a pretty sight, but you don’t want to hear it from me… ask them.
hello dadams,thank you for doing this site i really enjoy reading and knowing you on here, lovely piece about my brother thankyou for that also, i will keep in touch and follow you on here love to hear from you! pam.