IBM acquires Telelogic

A couple of weeks ago, I was discussing the future of modelling tools over breakfast with Danny Sabbah, General Manager of IBM Rational Software. The modelling tools market is growing fairly slowly, and Danny made it clear that Rational was looking to increase its market share substantially.

So today's announcement [note 1] that IBM is going to acquire Telelogic makes a lot of commercial sense. Telelogic has an impressive portfolio of tools, especially since its acquisition of Popkin in 2005, and it has a strong position in Requirements Management (DOORS) and Enterprise Architecture (System Architect). Popkin contributed significantly to the Business Process Management Initiative (BPMI), and was closely allied to John Zachman.

Telelogic's tools and methods didn't suit every user company, and in the past I have sometimes had occasion to be mildly critical of Popkin, especially from an SOA perspective. The Popkin acquisition was billed at the time as a move into SOA [note 2] but this promise was only just starting to be realised with the announcement last month of System Architect for SOA [note 3].

If IBM had wanted to buy a pure SOA modelling company, there would have been other, perhaps worthier candidates. But Telelogic is undoubtedly more attractive to IBM, because of its other assets and relationships; IBM can be relatively unconcerned by Telelogic's weaknesses, and should have little difficulty reassuring the customers of both companies.

But growth by acquisition is only one piece of Danny's strategy for IBM Rational. Another important piece is a shift in focus - from selling tools and technologies to selling process and business value. This means selling to the business, not selling to developers. Instead of being billed as a software engineering methodology, RUP may come to be positioned as an industry model for the software development industry, which IBM should be able sell in the same way it sells industry models for banking, insurance and other industries.

Modelling tool vendors have always faced the problem of growth. If the tools are good, they may get a loyal community of keen developers, but that is not quite enough. Rational itself had reached a plateau as an independent vendor before its acquisition by IBM in 2002. Is there more consolidation to come?

[Note 1] IBM to Acquire Telelogic to Advance Global Software Delivery Strategy (June 2007), IBM beats HP in bid for Telelogic (June 2007)

[Note 2] Telelogic's Popkin Purchase Prepares the Way for SOA (April 2005), Telelogic looks to bring modeling to SOA (Nov 2006)

[Note 3] Telelogic Facilitates Service Oriented Architecture Adoption (May 2007), Telelogic Adds Business Process SOA Solution (May 2007), Telelogic tools tie software services to business processes (June 2007)

Independent Modelling Tools

It's an old debate.

Firstly, are you are going to do model-based software development?	I have been an strong advocate of model-based development since the early 1980s, and I wrote my first book on data modelling in 1984. For over ten years, I worked for a company (JMA Information Engineering, which became part of Texas Instruments Software) that designed and sold modelling methods and tools.
Secondly, are you going to use a proper tool?	For me, this means not just loads of stand-alone diagrams (e.g. PowerPoint) or linked diagrams with standard notations (Visio), but a repository capable of supporting several users working on a single large model, and perhaps offering several different diagrams with a common underlying semantics (e.g. IDEF, UML).
Thirdly, are you going to use the modelling tool that is integrated with the implementation platform, or an independent tool?	While I have a strongly held position on the first two questions, I do not have a strong position on the third question. I can see advantages both ways.

Independent	Integrated
Allows you to have a single modelling approach across multiple platforms. Allows you to build the model before you select the platform. Allows you to switch platform without changing the model. Allows you to use the special features of a particular modelling tool.	Simplifies coordination and change management between conceptual model and software design. Supports "round-trip" software engineering. Integrated models may also support rival platforms (although possibly with lower levels of integration).

With the latest ("Atlantic") release of the Rational product family, IBM is bringing the modelling tools closer to the platform. Meanwhile Keith Short's team at Microsoft is developing an integrated approach to modelling. (Keith was also at JMA/TI and was the architect of Integrated CASE.)

Thus market forces may be tilting the balance towards the integrated tools. Can the independent tools survive?

Some consolidation is probably inevitable, and presumably some of the other platform vendors would be interested in beefing up on the modelling front. I noted a small announcement last week from Popkin, who are getting cosy with Oracle. Is this a sign of things to come?

Popkin/Oracle announcement (December 2004)
Earlier post on Consolidation (October 2004)
Earlier post on Models and Code (July 2004)
Earlier post on Software Factories (July 2004)

---

Update December 16th 2004

In a useful reply to Grady Booch (December 3rd, 2004), Jean-Jacques Dubray (December 14th, 2004) contrasts the Microsoft version of MDA with the OMG version.

Meanwhile, IBM has its own version of MDA, based on Eclipse. Although Eclipse may be supported by many vendors, it is still a platform, and the Eclipse Modelling/Management Framework (EMF) can hardly be regarded as truly platform independent.

Although EMF is currently aligned with UML, it may be able to accommodate a broad range of other modelling languages, including both older languages (IDEF) and newer ones (BPMN?). Thus third party modelling tool vendors may find themselves a niche within EMF. However, the extent to which they can be fully integrated into the software lifecyle remains unclear.

Models and Code

Both IBM and Microsoft seem to be adopting a strategy of physical convergence between design models and software code.

The key idea is that instead of having an entirely separate repository of models, the models are simply ways of viewing the code, while the code contains all the information necessary to (re)construct the model, and to display it in any supported notation.

There are many advantages of this convergence, since it eliminates the synchronization problems of having the model repository separate from the code base.

It also helps to bridge between the two opposing development subcultures - coders and modellers. (Coders will not actively embrace modelling, but these platforms give them modelling anyway.)

But whatever IBM and Microsoft say about standards and interoperability, most people will assume that this increases the coupling between the model platform and the code platform. We seem to be moving away from the CASE vision of platform-independent models.

Where does this leave the independent modelling tool vendors (and their customers)? They will have to find a way of demonstrating the advantages of a separate and independent modelling tool/repository in a world where models and code are converging, where the line between software development and system operations is becoming blurred, and model-based development is expanding into model-based management.