So here I am in sunny Florida at another RSDC (Rational Software Development Conference, now including an added Telelogic user conference). This one is in hard times and IBM seems rather keen on emphasising the financial benefits from not just doing it right, but from doing the right things too, which is as real as it gets!

So the key insights from Danny Sabbah's keynote, it seems to me, were his talking about development "maturity models" and the business-level metrics or "measured outcomes" a mature organisation uses to ensure success; and also his talking about the importance of EA models to ensure that what developers produce is aligned to what the business wants—or needs (assuming that the business is mature enough to know the difference).

Products to look out for in this space (apart from Rational System Architect, its EA tool) are, I think, IBM Rational Insight, a Jazz-based BI tool (powered by Cognos) which analyses and reports project data; and IBM Rational Focal Point, an immensely powerful and flexible product and portfolio management tool (and more), which can effectively prioritise business requirements using pair-wise comparisons that should largely take the politics out of the process. There were a lot of announcements at RSDC, see here.

This is only a short overview of Day One of RSDC, however. I was also impressed by Greg Sikes—emphasising the importance of "actionable architectures"—an enterprise architecture should be more than just a drawing (failure to recognise this is probably a prime cause for EA projects failing). I think he agrees with me that one could visualise the EA model as a CIM or PIM in OMG MDA (Model Driven Architecture) terms, parts of which transform into UML models and then even to code. And I was pleased to hear Janie Thomas talking about IBM's Measured Capability Improvement Framework (which supports Sabbah's talk of maturity and metrics) and reporting one customer claiming a 30% cost saving simply by avoiding requirements rework.

The analyst buzz seemed to be around Cloud Computing and IBM's "developer cloud" initiatives. But I couldn't help feeling that this was all just a repackaging by the marketroids of established ideas around virtualisation, self-provisioning, SaaS etc. Don't get me wrong, I think that Cloud computing as I understand it is important—it marks the end of the "computer says no" mentality—but the term "Cloud" means many things to many people and sometimes changes meaning mid-conversation. I think "Cloud" is becoming an instrument of confusion and obfuscation.

There was less of a buzz around the Measured Capability Improvement Framework—something possibly even more important than the Cloud. IBM Distinguished Engineer Murrey Cantor, ably supported by Per Kroll (Chief Solution Architect for MCIF) and Bob Noble (Dir WW ISSR Infrastructure at Rational), did a good job of selling me the idea that IBM was poised with tools that actively enabled practice improvement (think of a more incremental, more pragmatic, less command-and-control analogue of CMMI, perhaps). The 4 phases of MCIF are to establish business and operational objectives; to prioritise practices and define a roadmap; to accelerate adoption with tools and services; and, finally, to report, analyse and act on results. IBM has or will have tools to support every phase. Just picking a few that seem particularly interesting, for Phase 2 we have IBM Health Assessment for Software Delivery and, for phases 3 and 4, IBM Rational Self Check for Software Teams, which is particularly interesting as getting away from the (largely failed) "big brother is watching you" assessment metrics that people have used to manage programmers in the past. And IBM Rational Insight, which I've already mentioned, brings operational BI to systems developers in phase 4. MCIF is very promising, I think, although from a user panal session, there only seems to be significant experience with Self Check outside IBM as yet, not the rest of the framework.

All interesting stuff—capability and maturity will be key to delivery of holistic business services, I believe; and while CMMI still has a part to play (if used properly ), it is just as well if it isn't the only game in town (it is very easy to abuse CMMI if it is used without enough thought and management buy-in).

But my current enthusiasm is EA, as part of the transformation from business vision to instantiated code—or manual business process. IBM is a strong player here with System Architect product and it was interesting that Murray Cantor and I both seemed to think that parts of MCIF (Process Definition/Practices, I suppose) were essentially part of the EA model for an organisation.

Another interesting twist here came from IBM's Focal Point roadmap. Release 6 is the first release of this re-badged Rational instead of Telelogic but a key sign of the fundamental importance of this product, to me, is its new integration with System Architect. For now it's a one way export relationship, in a later release it'll be 2 way and, ultimately Focal Point "assets" could be integrated with EA models.

But I finished off the day over a glass of wine or 2 or 3 with Richard Crisp (Director, Requirements & Quality Product Delivery Team, Rational Software) talking about Requirements Management with Focal Point—if you have trouble seeing Focal Point as a developer tool instead of a tool for managing product portfolios or managing projects (it's those too), remember that a "requirement" for a new development is really much the same as a "feature" of a software package, but seen from the other side.

Most requirements management tools only do part of the job (some only manage a very small part of it indeed—they just store pieces of text). To my mind, testing starts with testing requirements—breaking them down to atomic requirements and questioning the real need - the business benefit delivered—behind a requirement. The most expensive mistake you can make is to develop for the wrong requirements, so you should think of testing—validating—requirements. Every requirement should be testable which means more than just linking it to some coded test cases at the end of the process. And this is where Focal Point contributes, as it implements pair-wise comparison which lets you prioritise requirements independently of the politics usually associated with working out which requirements really matter. And Richard wrote the algorithms for this.

Oh, and before I leave Day 1, Microsoft may "eat its own dogfood" but IBM claims that it "drinks its own champagne". Well I suppose it would...

RSDC2009