Innovate2011 – Fytte the 2nd, Software Economics and Collaboration

Well, as another IBM exec says, I wish I were as energetic as Steve Mills (head of IBM’s software group). Personally, I suspect it’s tiring.

Anyway, Millls’ key point perhaps was “if you still want to able to write software in future, and I guess you all do, you will need to think about how it’s deployed and used”. In other words, unless what you do contributes to a business outcome valued by the business, the business is going to be disinclined to pay you.

It’s perhaps interesting that he’s still concentrating on the IBM experience, although he has other supporting case studies too. I think that IBM makes an excellent case study; but I also think that driving software development by business outcomes—using software econometrics—is very much at the early adopter stage now. There are significant “early adopter” examples but mass acceptance is a long way off yet. Nevertheless, perhaps the idea is beginning to filter through to the masses as a possibility…

Dear to my heart, there was a real focus on “governance” from Mills and on what I think of as “real” governance, not GRC. Designing automated services without worrying about waste of storage resources, say, is a governance issue. The organisation is wasting money on IT—spending more money than it needs to in order to deliver a business outcome.

So, designing for operations is a governance issue too—if an application is hard to install and use, insecure, and hard to maintain, IT isn’t being governed properly. In other words, the investment in IT isn’t being made effectively.

And, its all about management and reuse of the organisation’s assets, which include its software assets. Mills says “nothing has improved IBM’s economic position more than reuse”. Notice the link between a software issue, reuse, and economics—it only matters if it supports a business outcome.

Mills’ other focus was on “development as a team sport”. Not just collaborating development teams but making sure that all stakeholders have an input to the process. This is “design collaboration”, which you’ll surely hear more about and Mills pointed out that Innovate was starting to attract line-of-business executives, not just IT executives, to its Executive Summit at Innovate—surely a good sign.

Harish Grama, VP of product development at IBM Rational, underlined all this with a demo of collaborative development in action, with the stakeholders in a real issue (brake failure in a motorbike can be a software issue these days, using different tools sharing the same information and models on the Jazz platform). Impressive; Jazz is reallly coming together, in the IBM world at least, as an open platform for tool orchestration. I also welcome the Jazz Hub, available here, making cloud-hosted Jazz tools more accessible to academia.

Jazz is underlaid by an emerging open standard, OSLC (Open Services for Lifecycle Collaboration), about which more later. This needs some thought before I blog in detail—it isn’t a metadata export/import framework like OMG’s XMI but a set of services enabling loosely coupled communication between tools—I think. This is an open standard too and supported by an OSLC community. Although OSLC is not an Eclipse project, an Eclipse project has started for the OSDLC SDK, which should make it more accessible. 

OSLC is obviously very important to IBM and is attracting support from other vendors and even IBM customers (using it to integrate in-house tools with IBM tools). The main question I have at present (apart from some interest on how configuration management for all the linked models will work in detail), is whether OSLC will get much traction outside of the (huge) IBM community. This is something I’ll be talking about with tool vendors such as Aptero, operating in the BPMN and OMG space—I do think that OSLC is potentially very important, it’s just how widely it will be adopted outside of IBM’s customers.