DevOps? ITIL? DevOps versus ITIL? There’s still lots of talk around which approach companies should take. But thankfully, there’s a growing appreciation that both approaches have a part to play in better IT service delivery.
The DevOps movement is still only eight years old, and it’s sometimes hard to believe that it’s younger than the smartphone – iOS or Android – in your hand. The ITIL IT service management (ITSM) best practice framework is one of the granddaddies of IT management frameworks, dating back to 1989, with its most recent update published in 2011. But despite the closeness in time of DevOps’s creation and ITIL’s latest edition, and the fact that they’re both part of the same IT family tree, there are a number of obstacles to exploiting both.
If you’ve ever worked in a manufacturing environment, then you certainly know what Work In Progress (WIP) looks like: stacks of partially-completed products waiting for the busy staff’s attention.
Easy to see that those part-made things have already cost money: the investment can’t be recovered until the product is complete and can be delivered to the customer. The longer it waits (as WIP) to be worked on, the farther away the cost recovery, and hopefully profit, gets.
This was the situation: my customer had a dysfunctional business. It wasn’t a large company, and many employees had been there for years; and discussions were led, and decisions were made, by committees and reports. Life wasn’t good, and the competition was nibbling away at opportunities that the company should have won.
More importantly, there was a regulatory requirement the company needed to meet, requiring a new process across all of its customers, for which no action had commenced. The CFO wanted a way to get a conversation going, that would wake up her CIO and his teams and make the required change happen.
The lack of movement wasn’t for a want of trying – Agile, Lean, DevOps, all sorts of things had been tried but with little sustainable success. It had more to do with how disparate leaders and teams worked, or didn’t work, together.
Many companies still need to manage their software asset investments better – to reduce risks and financial “wastage.” It can be a huge undertaking but it can also be very rewarding – so start small if you need to, building up your software asset management capabilities over time.
Software asset management (SAM) is an underused IT management discipline that should be employed by IT departments to manage, control, and protect their software assets at an enterprise level. Done well, SAM will not only reduce the risks of compliance exposure, it will also save your organization time and money on maintaining its software estate as part of the overall IT service delivery ecosystem.
If you’re a software asset manager, or have responsibilities involving IT assets, then please read on for seven tips that will make you more effective in your role.
COBIT might have started life as a tool for IT auditors, and the requirement for IT-related internal controls (hey, there’s no need to yawn), but it has since blossomed into a good-practice framework for both IT management and governance. Read on to find out how COBIT can help your organization and the IT service management (ITSM) practitioners that work within it.
Following on from my previous blog on IT4IT, this blog provides a “beginners guide” to COBIT (formerly also known as “Control Objectives for Information and Related Technologies,” which was dropped with version 5), a good-practice framework for IT management and governance created by the international professional association ISACA. In particular, I focus on information about COBIT’s seven enablers and how their use will help your organization.