Back in 2007, when the Information Technology Infrastructure Library reached version 3, I spoke with Brian Johnson, who at the time was CA’s worldwide ITIL practice manager and a member of the team that created ITIL for the UK’s Central Computer and Telecom Agency.

I asked him if the set of best practices for supporting business through its IT operations had anything at all to do with developers, and he said that ITIL is not about application development, although it does touch on it.

Last month, I hosted an SD Times webinar on ITIL Release Management and Automation, and I asked Urbancode technical evangelist Jeff Fredrick the same question. ITIL, he explained, is now the bridge between developers and operations.

“ITIL intersects with the rise of release management,” he said, “which is a relatively new role in IT.” DevOps and release management: now those are very relevant to developers.

ITIL v3, at its core, addressed IT services strategy, design, transition and operation, as well as continual services improvement, Fredrick said. The trouble implementing it arose from the very generic language used to write ITIL, and it doesn’t provide any guidance for implementation once you get the language issue sorted out.

For instance, he cited a section that reads: “A service is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks.” Or this gem: “Service management is a set of specialized organizational capabilities for providing value to customers in the form of services.”

Got it? Me neither. How are you supposed to get that done?

Fredrick offered a “rather stuffy” translation of ITIL terms taken straight from the v3 glossary, which also includes four pages of acronym definitions. To Fredrick, an ITIL “configuration item” is a unit of stuff. The “build environment” is the controlled environment to assemble stuff. The “release” is all the stuff, not just the software. The “definitive media” is the only place to get software stuff for a release. “Deployment” is moving the stuff to a live environment. The “release window” is the agreed time to move the stuff, to minimize conflicts and the impact on the environment.

The concept on release management in ITIL is to “deliver the capability and provide the services specified by Service Design, and that will accomplish the stakeholders’ requirements and deliver the intended objectives.”

Release management can be taken quite literally as “super project management” that runs out to operations, or release managers that can act as gatekeepers, making sure all milestones are hit before transitioning the project from one environment to another. It can also be viewed as a kind of post office, in that it doesn’t inspect the contents of the package but rather ensures it has a stamp (of approval), or as simple facilitation of deployment.

That is to say, when software is moved into production following an automated, auditable process of checking software artifact dependencies, creating execution logs and comparing with historical data throughout the application life cycle, the organization will have a high degree of confidence that it will be successful and deliver that value to stakeholders.

And that’s a beautiful thing in any language.

David Rubinstein is editor-in-chief of SD Times.