The DevOps movement is in full swing. I consider it one of the most important developments in full lifecycle IT management in recent years. (By full lifecycle IT management, I mean the set of concerns faced by enterprises that build IT systems in order to run them for their own purposes.)
A great ferment of ideas is happening at the level of actual software development and deployment – new tools, techniques, and best practices for moving the bits into production while preserving stability. There is a wealth of DevOps material available on the web, but I only discovered this extended discussion recently – probably the best intro I have seen, with a nice visual exposition of the notorious “over the wall” dysfunction.
But is this innovation being reflected in higher order IT management processes and systems? Unfortunately, not yet. In far too many cases, the Project Management Office and its supporting systems (traditionally aligned with software development) remain organizationally and technologically distant from IT Service Management (in ITSM’s more limited operational sense).
Thus, the “wall” between Dev and Ops is being undermined from the bottom, but still is thick at the top. Practically speaking, PMO tools like CA Clarity, HP BTO’s Demand/Portfolio, and Planview are usually implemented as silos, far removed from traditional service-desk based ITSM frameworks such as BMC Remedy and CA Unicenter. (And this silo implementation of course reflects long running IT organizational boundaries between the development and operations worlds.)
And just as lack of integration between development and operations causes many problems at the systems management level, so does lack of integration between the PMO and ITSM areas cause problems at the higher level.
One of the biggest failures of such arrangements is the unmanaged demand for IT staff time. I can attest from experience at multiple large IT shops that project assignments (typically expressed as an expected “%” of your time) are rarely if ever brought together into a common queue with service requests, incidents, audit responses, and the various types of continuous improvement activities always in progress.
In general, there is little visibility into the aggregate demand represented by the combination of development and other activities. IT staff become overworked, their management cannot effectively defend or advocate for them, and the resulting execution problems coupled with lack of transparency continue to give IT a very bad image.
BMC purchased the ITM product some years ago, rebranded it as part of their IT Business Management initiative, and has currently being absorbing it into the Remedy ARS platform. The most recent release introduces integration of Project and Change management, a necessary first step towards supporting DevOps at an IT process level. They also are making strides integrating IT Governance at a practical level with operational IT data from the Remedy suite.
ServiceNow has had the luxury of greenfield development, and created their own Service Portfolio Management offering as another module on top of their integrated platform. Because of this, process level integration between the development and operations worlds is easily achieved (at least at a system level), and the concept of a “universal queue” was specifically presented at their recent Knowledge11 conference.
These solutions are distinct from the systems management infrastructure DevOps requires. They don’t move code, change configurations, or check for integrity. But as the pipeline from development to operations becomes a unified system the IT governance and process management worlds will have to adapt and become seamless as well. As we move into a world of less specialized agile IT teams, working on smaller increments of value in a smoother flow, traditional distinctions between the “project” and “operations” worlds are eroding, and the need for unified IT management platforms is clearly increasing.
I am sure others are working in this space as well. Please contact me if you have something to share.