Olivier Le Moal - Fotolia
Editor's note: In "The evolution of IT: From 'IT doesn't matter' to value creator," George Spalding, executive vice president at ITSM provider Pink Elephant, explained that many IT organizations function like it's still 2003. That's when a series of events -- including Y2K, 9/11 and Carr's bombshell Harvard Business Review article, "IT Doesn't Matter"-- gave rise to a view of IT that prevails to this day in some quarters: IT was a commodity and, therefore, of no competitive advantage to companies. Moreover, because of the critical role this commodity played in business operations, IT systems presented a serious risk to a company if they failed.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The IT industry's reaction -- its bid to prove its business value in 2003 -- was to build safe, reliable, virtually bulletproof systems. But now it is time for a change, Spalding asserts, mainly because the business definition of IT value has changed. The advent of Agile has helped IT keep up with business demands, but the evolution of IT still has some evolving to do. Here, Spalding discusses IT's raison d'être and the value transformation DevOps can bring about. For good measure, we've included his assessment of the Waterfall and Agile methods.
Value transformation and IT's raison d'être
Where do we begin in our discussion of value transformation? Let's start with a simple question for IT: "Why do you exist?"
Some network geek may make a snarky comment about users slowing down the network, but it shouldn't take too long to get to the realization that "IT serves at the pleasure of the business." Period.
With that true north guiding principle in mind, we soon realize that IT's entire raison d'être is to provide value to the business. So far, nothing too controversial here. Now, it gets tricky. Who defines value to the business? The business, right? OK, this is not rocking my world ... but wait for it.
Can the business change its mind as to the definition of value? Yes. Aha! There's the rub! The business can, and often does, change its mind as to its definition of what constitutes value. Development (dev) and project management (PM) now get it. But ops didn't get the memo. Many IT ops groups are still operating under the 2003 definition of business value. It's time for ops to join the party. Enter DevOps.
DevOps represents a change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach. DevOps emphasizes people (and culture), and seeks to improve collaboration between operations and development teams. …
DevOps is really a cultural movement that is completely dependent on improved communication, collaboration and teamwork across the entire value chain. It combines the principles of Lean and the flexibility of Agile with the latest automation to deliver high-quality services and increased value to the business faster than ever before. DevOps is a vehicle for value transformation.
How much better is a high-performing organization embracing DevOps? A recent survey from Puppet Labs revealed the following IT and organizational measures.
High-performing IT shops:
- Spend 21% less time on rework or unplanned work
- Spend 44% more time on new or value-add work
- Deploy new software 46 times more frequently
- Enable changes 440 times faster
- Recover from failures 96 times faster
- Are 80% more likely to deploy successful changes
High-performing organizations are more than twice as likely to achieve or exceed the following objectives:
- Quantity of products or services
- Operating efficiency
- Customer satisfaction
- Quality of products or services
- Achieving organizational and mission goals
Organizations that are embracing DevOps are the leaders in the value transformation happening right now. Lean and Agile in the context of IT operations and automation is the formula for real transformation in today's enterprise.
Value transformation in two-week sprints
The Waterfall method, introduced in the 1950s, was created to build products -- physical things that would be manufactured in volume and, eventually, go to market in volume. In the Waterfall method, requirements are set; we design to those requirements, build that design and implement the build. All the investment is front-loaded and all the business value is received only after implementation. With Waterfall, we have one shot to get it right, one chance to define the scope -- and that is in the requirements stage. Get it wrong there and we have to do it all over again from the beginning.
When computers began to make headway into the businesses of the 1960s, we needed a method to develop new software. The only project methodology around that made any sense was the Waterfall method. But that method was never designed to produce software -- it's simply all we had at the time. No wonder we have a 65% failure rate for IT projects.
But in the late 1990s, some new and radical development methods (all based on object-oriented programming) began to gain popularity: Extreme Programming, Dynamic Systems Development Method and Scrum, to name just a few, blossomed. Proponents of these and other similar methods codified their key values and beliefs in 2001 with the Agile Manifesto. And Agile was born.
Agile is an iterative development method with each iteration as short as two weeks. Each completed iteration produces ship-ready code. This means that for a minimal investment, the business can begin to see value after only two weeks.
Built into this two-week schedule is time for feedback from the business, which means the scope can be adjusted every two weeks. This may seem a bit disorganized and, in truth, it is. But it turns out that most software development is actually far better if the end customer can provide feedback and commentary and tweaks along the way. Agile allows development and project management to operate in sync with the needs of the customer for the first time. Development can begin to keep up with business demand while delivering software that is exactly what the business wants. Truly a win-win-win -- a value transformation -- for dev, PM and the business.
About the author
George Spalding, executive vice president at Pink Elephant, is regarded as one of the world's most insightful and engaging ITSM industry experts, executive management consultants and trainers. He holds certifications as an ITIL Expert, a Business Relationship Management Professional, an Organizational Change Management Practitioner and a Lean IT Professional.
A strategic CIO plays the long game
Need for speed propels DevOps
Masters of low-cost, low-risk change