Showing posts with label Popkin. Show all posts
Showing posts with label Popkin. Show all posts

Sunday, April 13, 2008

IBM Acquires Telelogic 2

After several months of internal discussion, IBM has finally explained how the Telelogic acquisition (announced in June 2007) is going to be folded into the Rational brand. I have just listened to an analyst call with Danny Sabbah (general manager of Rational) and Neeraj Chandra (EVP of Telelogic).

Let’s take the minor headlines first. IBM has announced three main areas of integration across the extended product family.
  • end-to-end, extensible, open standards-based platform
  • community-based collaboration
  • preserve and protect client investments in Rational and Telelogic products

This seems to be about interoperability between the different products, interworking between teams using different products and upward compatibility (i.e. no forced migration) of client models and other assets built using the different products. These are the inescapable challenges of software industry consolidation, which IBM and its customers are very familiar with.

But it’s the other three headlines that are the interesting ones, because they reveal what IBM thinks it is gaining from the Telelogic acquisition. According to IBM, the Rational product family is extended in three main areas:
  • systems with embedded software
  • product lifecycle management
  • enterprise architecture
with an emphasis on sectors with complex requirements for systems and software
  • electronics
  • aerospace & defense
  • automotive
  • telecom

What I find interesting about these two lists is what they leave out.

Firstly, requirements management doesn’t get a headline mention. Requirements management was a major strength of Telelogic, and DOORS is the market leading tool. Perhaps we are supposed to believe that Rational already had a perfectly adequate approach to requirements management, and Rational System Architect works fine, thank you very much, except in a couple of specialist areas (systems engineering, product engineering).

Secondly, it ignores the current push towards enterprise architecture in other sectors, notably Government, where I understand Telelogic’s System Architect tool (ex-Popkin of course) has a significant presence. (The IBM materials mention DODAF and MODAF but not TOGAF, FEA, or xGEA.)

And thirdly, not much mention of SOA, except as an enabling technology for back-office systems. Telelogic System Architect had come out with an SOA-enabled version shortly before the acquisition announcement, but it isn’t yet clear where this is going. Danny Sabbah did mention expanding the opportunities for Telelogic's architectural frameworks products in the SOA space, but this seemed to be in reference to sales rather than development.

There are two domains in play, according to IBM: an IT domain (supporting business operations) and a systems domain (producing products). Although Neeraj Chandra wanted us to know that Telelogic could contribute to the IT domain as well, the official Rational line seems to be that the Telelogic is to be used primarily in the systems domain.

For systems domain read systems-of-systems domain. Examples cited include aerospace systems and consumer electronics, where interoperability between multiple systems is needed to solve a complex requirement.

But as I have long argued, SOA itself is essentially a systems-of-systems approach – interoperability between multiple services to solve complex sets of requirements. So I hope IBM doesn’t intend to bury SOA somewhere in the IT domain. Shouldn't there be a separate services domain?

There are of course plenty of outstanding questions. In answer to a question on reuse, Danny talked briefly about architectural governance, but I'd like to have a much longer conversation about this. And Neeraj mentioned methodology and workflow, but it wasn't clear how any of this gets plugged into RUP (or perhaps RUP/SE).

I do think the acquisition of Telelogic gives IBM Rational a tremendous opportunity, but clearly they have plenty of work to realise this opportunity. Certainly not the end of the story.

Monday, June 11, 2007

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)

Saturday, December 11, 2004

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.