Earlier in the week I put on my blue shirt and socks and headed down to the UK Rational Software Development Conference 2007  at IBM Bedfont Lakes site.

Bran Selic’s talk on IBM’s strategy for supporting industrial systems development was my main reason for attending but there were many other interesting speakers covering the whole life cycle and range of Rational products.

Bran is in charge of IBM’s tool strategy for the systems space so it was a chance to hear about this from the source as it were. He began by noting the key issues for developers in the systems space:

• complex, flawed and volatile requirements
• the need to deal with complex real-world phenomena
• poor integration between tools leading to traceability issues - traceability being achieved currently through documents or with point-to-point tool integrations
• an increasing need for governance
• (geographically) distributed development teams

IBM’s approach to this space is based around four key strategies:

• Model-Driven Systems Development
• Standards and open frameworks
• Risk-driven iterative software development
• Objective evaluation methods

Model-Driven Systems Development is based on two fundamental concepts:

Abstraction - hiding the details and complexity of the underlying implementation. Since software systems are now among the most complex artefacts produced some form of abstraction is essential to understanding them.

Automation - the transformation from model to target (e.g. source code) is performed without programmer intervention and so is less error-prone and more productive than a manual transformation.

As Bran rightly states, you can’t argue against these concepts even if you may be sceptical about their realisation in current tools.

In Model-Driven Systems Development, the organisation moves from a document-centric to a model-centric approach. Models are created to capture requirements, design etc. in a formal way.

As an example of a modelling langauge for achieving this Bran described SysML, a  UML-based domain-specific language (his term, not mine) for systems development. Using UML as the basis for this leverages the knowledge of existing developers etc. who are familiar with UML and allows organisations to continue to use their existing tools . (But listen to our ‘UML vs. Domain-Specific Languages‘ audio recording for debate on this point.

Bran described a MDSD case study of a telecomms network controller. In this study a team of over 200 developers worked on a single model. The generated output was 4.5 million lines of C++ code. The resulting system performance was +/- 15% of hand-crafted code. Furthermore they recorded a 200% productivity gain and 80% fewer bugs.

According to Bran attempting to encode requirements in a model early-on can also help verify and validate those requirements.

Bran had less to say on the other three strategies but I did note that IBM is continuing to take a federated approach by working with best in-class tool and service providers and their strategy continues to be based on Eclipse - although with the new Jazz team collaboration platform to the fore.

In the follow-up Q&A I raised the issue of resistance among software developers to the idea of model-driven development with Bran. He also sees a lot of scepticism among developers about model-driven approaches.

However, he observes that developers are wrong to be sceptical of these methods due to a fear of a decrease in performance of the finished system. As the case study he described noted this was comfortably close to that of an equivalent hand-coded system. Instead when you’re considering MDD tooling you should think about issues such as scalability and the expertise needed to implement such tools. Does the organisation have the skills to develop code generators for example? (This ties into a recent post at Peter Bell’s application generation blog on involving consultants early-on in your code generation adoption).

Hopefully I’ll get a chance to go along to the conference in the future. It was a well-organised event - and a must if you’re a Rational user I would have thought.