3 success factors you need for a DevOps transformation

michael-garrett2.jpgI recently wrote about DevOps and the 4-phase model HP has for helping large enterprises on this journey. Resolving the historical contention between Dev and Ops is crucial to the success of IT.

 

Why the friction? Dev and Ops are measured on two fundamentally different things that put them in opposition. The business drives Dev to release applications as fast as possible, so developers are measured on how quickly they release code. At the same time the business measures Ops on availability. As a result, Ops is afraid to let Dev anywhere near its production network, for fear new applications will break it. This has been going on since the days of mainframe computing, but it’s reached a critical stage with the rise of mobility.

 

For mobile platforms, it’s crucial to quickly release a new application or patch to support an operating system change or a new device. Otherwise you risk decreasing customer satisfaction—and revenue.

                                                                                                                                                           

3 components of a DevOps transformation

In HP Software Professional Services we’ve helped numerous large enterprises on their journey to DevOps. We know that that 80% of the work of DevOps is transformation and people. You’ve got to undo 20 years of animosity between operations and development. Here’s how.

 

  1. Recognize that you’ve got these opposite measures and you’ve got to bring them together. The business still needs developers to release code quickly, and it still needs operations to maintain availability. So you’ve got to look at the way people work and the tools they’re using so that when Dev releases to Ops, Ops has confidence this release won’t break anything. HP has a tool that can help with this. The HP ALM integrated solution can monitor your build systems, so that you can intelligently automate and synchronize them.
  2. Accelerate projects by putting in place an ongoing education and adoption platform. DevOps relies on continuous integration and development. This needs to extend beyond testing to how the two teams, Dev and Ops, work.  Having a single education platform that is flexible and can continuously be updated by both teams is another piece in the adoption puzzle.
  3. Implement management of organizational change. DevOps in large enterprises is transformational. In any kind of transformation you’ve got to create a strategic plan that outlines how to incorporate your business processes, systems and applications into a flexible architecture aligned with your business goals.

 

Evolving an enterprise organisation with all of its complexity and legacy applications to a DevOps world is a journey. We can help by giving you the means to bring these two teams together.

 

Contact HP Software Professional Services to learn more. And check out our new ebook, “Deliver business value” for more on how HP Professional Services helps you on the journey to the New Style of IT.

 

Related links:

Blog post: SaaS isn't the only way--today software is all about choice

Blog post: A roadmap for DevOps: 4 steps to greater agility

Blog post: 5 elements to successful enterprise mobile apps

Blog post: 3 success factors you need for automation

Blog post: 6 months after your software project is finished, will this mistake come back to haunt you?

Blog post: IT leaders: You’ve delivered the project, but have you delivered the value?

Labels: DevOps
Comments
Guest House Malang(anon) | ‎06-16-2014 01:02 AM

This article is very useful to increase my knowledge. I hope to publish more articles like this. thank you

mikeshaw747 | ‎06-24-2014 02:44 AM

I agree - aligning dev and ops' objectives is essential, otherwise they will be fighting against each other thru no fault of their own - the objectives will be at 90 degrees to each other. 

 

I think that another key ingredient is getting buy-in to the idea of "continuous". Today, we view apps as a one-off. Like a hand-made car by Rolls and Royce 100 years ago. We need to move to a view of app release as a factory production line - there will be a version of the app in dev, one in test, one being released and one in production that we are managing. In other words, we need to think "continuous delivery". This is easy to say, but harder to achieve. 

 

Not least, upper level management needs to understand that there may be no "done". Each app release is an experiment and the next version will be along soon. And so, "is it done yet?" needs to be replaced with a more business-orientated question like, "is it getting five stars yet?" or "is it better than the compitor's yet?" or "do customers love it yet?".

 

Also, very importantly, we need to setup a single model. A single model that goes from dev, is added to in test, is mapped to an actual deployment specification in deploy, and is plugged into the management system so its performance, security, compliance, change control and back and recovery can be managed. Unless we have this single model flow thru and dev and ops, every time we automate, we have to recreate the model, and the cost of automation becomes very high. If the modeling "hump" for automation is too high, then that modelling won't take place and we'll always find a reason why we haven't yet done automation.  So, when we "think continuous delivery", we need to also "think continuous model" all the way thru too. 

 

And we need to think of quality as a two-way flow. Traditionally we think of quality as something we build in (hopefully we build it in and don't just test it in). But feedback from production can improve quality too. Customer feedback and feedback from the support desk can improve the quality of a product quickly. How about using HP Autonomy to "understand" what customers and support engineers are saying about a product's quality - for auto-catagorizing, for clustering of comments and for figuring out the trending of comments.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation