Prediction and the Good Analyst: IBM Rational

I have been unable to find a clear source for this quote, but some author in the 1970s or before defined science fiction as exploring any of three premises about the future – “ (1) What if? (2) If only … and (3) If this goes on …” Rearranging the premises, slightly, what we have is a good description of the role of prediction in analysis, especially for a good analyst:

1. “If this goes on …” is extrapolation. It uses a model based on historical data, and predicts by assuming that things will continue to operate according to the model. For the analyst, this means looking at a vendor’s product release and figuring out how people will react to it, based on how they have reacted in the past.

2. “What if?” is stress testing. It introduces new events or players not seen before, but which have some reasonable chance of happening, and sees what happens within the model. For the analyst, this means asking whether new products from other vendors, or new trends, will positively or negatively affect the product.

3. “If only” is normation[1]. That is, it seeks to identify changes that will make for a better outcome for some or all people affected by this future. For the analyst, this means identifying ways that the product could be made better in the future, or ways in which another combination of products can provide better results.

I am reminded of this way of looking at the analyst’s job by recent news regarding IBM Rational. At IBM’s Software Connect, the group announced initiatives including “completing the software lifecycle” by linking development and operational information about software, improving software delivery predictability by applying risk management and analytic techniques, and new ways of integrating IBM’s rapidly proliferating array of software. This was complemented by a Dec. 16 press release that noted change management, collaboration, embedded-system development, SOA-based development, and requirements management improvements to existing Rational products. All this, as Steve Mills noted in his Software Connect keynote speech, is in service to IBM’s commitment to creation of “smarter” products – with instrumentation, automation, and reporting.

To understand my reaction to this news, you should walk back with me over a decade and a half of applying extrapolation, stress testing, and normation to Rational, and then IBM Rational, software development offerings. If you remember, Rational’s original claim to fame was as the most effective purveyor of object-oriented design tools. This focus on development of sophisticated and formalized control tools for large-scale and complex development projects continued until as recently as three years ago.

However, during all that time, there was an alternative – first embodied in the 4GL offerings of the mid 1990s, and then in the agile development community of the early 2000s – that stressed flexible, iterative, solo or loosely collaborating, open-ended development. My recent research suggests that agile development has a paradoxically positive effect on project risks, development times and costs, and organization ROI and agility – and except in very complex projects such as design of the latest Boeing plane, the Rational approach (as it was then) does not. So extrapolation suggested that Rational tools would serve an ever smaller percent of the development market; stress testing suggested in the mid-2000s that adoption of agile development techniques was beginning in offshore development firms as well as small shops in the US; and normation suggested that IBM could leverage the efforts of agile development methodologies such as SCRUM as well as the rapid prototyping features of non-Rational software such as WebSphere Portal to quickly implement a strong agile-development product and focus. Still, as late as 2007, there was no clear indication that IBM, via Rational, would change its focus from “formal” to “agile”.

That was then; this is now. Over the last three years, IBM Rational has clearly made a major transition to focusing on agile rather than just “high-end complex” development, and its announcements represent the culmination of that effort. IBM Jazz, the in-house-developed product for agile mashups, receives top billing; older Rational products have been retrofitted to integrate with agile development tools and support a “spiral”/iterative rather than a “waterfall” (i.e., no going back to a previous development stage) model; and there is a welcome focus on constant incremental upgrades to software via infusion of runtime “operational” data on a piece of software in the development process. What’s not to like?

Ah, but that was then, this is now: it’s time to apply extrapolation, stress testing, and normation to the new Rational. Extrapolation says that the agile focus will make IBM of much more use to a wider array of developers. Stress testing says that while IBM’s competitors at all levels may have some advantages in having “built from the ground up” agile development tools, IBM’s ability to scale development to the high end offers advantages to larger customers. However, stress testing and normation suggest that the new Rational has one glaring hole: lack of tools to handle the “instrumented world”, as IBM calls it, or the “sensor-driven Web”, as I call it.

New types of data – including RFID, GPS, and cell phone photos and videos – are being passed over the Web, and within the enterprise, in massive amounts. The architecture to handle these appears to be evolving as the “event-driven architecture”, a filter on top of an Enterprise Service Bus, in which a “one-size-fits-all” program filters events passing over the bus, aggregates them and places them in context, and then either takes action itself according to pre-defined business rules, or sends notifications to a human that action may be needed. The software for these programs is fundamentally different from most past programming models, because it requires “near-real-time” response, and because the structure is trigger/response rather than input-process-output (old-style programs) or loosely-coupled communication (today’s object-oriented programs). If a development vendor fails to provide competitive tools to handle this new model over the next three years, and if other vendors do, the laggard will miss out on a major part of tomorrow’s development market – just as IBM ceded a large segment of the of the medium-sized, medium-complexity “sweet spot” in the development market to others from 1995-2006.

The good news for IBM is that, its competitors Oracle, Microsoft, and HP also appear to be quite some distance from creating a full-fledged sensor-driven Web development tool – and at least IBM recognizes the opportunity. It also appears that moving in the direction of such a tool will not be such a stretch for IBM, given their existing “stream processing” tools. However, because of IBM’s recent history of “missing an opportunity and then buying a third party” in areas such as global repositories, I won’t count IBM Rational as a leading-edge sensor-driven Web development tool until I see some quality productized code.

So, two cheers for the agile IBM Rational heading into 2010; and an echoing silence where the third cheer ought to be. To figure out where that third cheer went, they might apply a little extrapolation, stress testing, and normation; or they could ask a good analyst …

---

[1] A made-up word. It means the process of developing normative recommendations from data.