Remember when the IBM acronyms dictionary was a must-have for IT professionals? Every single possible TLA redefined in several different ways - with the acronym subtly updated as technology fashion changed.

Well, that was the old IBM and I'm seriously impressed with the new IBM's vision, most recently presented at Innovate 2012 - and its ability sometimes to laugh at itself helps me with this. I'm always distrustful of the sort of Vision some companies present - where if the po-faced mask cracked, the whole thing would fall apart in laughter. Today's example? Why is OSLC important? Well, lots of good stuff about integrating different tools with open APIs ("like Open Source specs - except we're a bit faster with changes"), but, "lets face it, OSLC was Danny Sabbah's baby at Rational and now he's at Tivoli; well, of course integrating Rational's tools and Tivoli's tools with OSLC turns out to be important" (as one presenter said, more-or-less). Actually, I think Sabbah's right as usual - my only concern is whether people outside of IBM and its partners will adopt OSLC; being truly open may not be enough and, although integrating tools across all vendors (not just the IBM community) makes lots of sense, not everyone wants to play with IBM.

However, returning to the IBM TLA dictionary, it's now moved up a stage from the TLA and is apparently redefining portmanteau words like DevOps. Not that that matters much, because nobody knows what DevOps means and nobody outside of the DevOps evangelist community uses the term much anyway. Is DevOps Developers taking over Operations or Operations taking over Development? Well, more the latter than the former - but its a lot more than that and, talking with Ashok Reddy at Innovate, I think IBM may just have got its DevOps vision about right.

Ashok and I decided, over drinks at the Innovate networking session, that it was all about "governance" in the end. Not primarily about continuous delivery using automation, not primarily about removing bottlenecks to agile delivery of software into production, not primarily about increasing collaboration between Development and Operations - although all of these are important aspects of DevOps.

No, primarily DevOps is about delivering automation (whether new in-house development, packaged software or cloud services) effectively and efficiently so as to optimise delivery of a business outcome; it's about involving all stakeholders (not just developers and operations people) so that all affected trust the delivery process; and it's about providing a feedback loop between customers and deployed applications and developers. Trust comes from just-enough governance, so that the business is confident that the automation has been tested on a realistic analogue of the production system (not just on whatever VM images were lying around); so that security is confident that security was designed-in (not bolted-on); so that business users are confident that their new automation not only works but is actually comfortable and productive to use; and so on. As a side-effect of all this, the walls between Operations and Developer silos will have to come down but this isn't the prime objective - it's not nearly as useful as enabling the optimisation of business outcomes. I explore this in more detail in my Research Note on DevOps and Governance.