Digital Transformation
cancel
Showing results for 
Search instead for 
Did you mean: 

Re: 3 success factors you need for a DevOps transformation

mikeshaw747

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.

Mike Shaw
Director Strategic Marketing

twitter.gif@mike_j_shaw
linkedin.gifMike Shaw

0 Kudos
About the Author

mikeshaw747

Mike has been with HPE for 30 years. Half of that time was in research and development, mainly as an architect. The other 15 years has been spent in product management, product marketing, and now, strategic marketing. .

Comments
Guest House Malang

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

mikeshaw747

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.

Labels
Events
June 6 - 8, 2017
Las Vegas, Nevada
Discover 2017 Las Vegas
Join us for HPE Discover 2017 in Las Vegas. The event will be held at the Venetian | Palazzo from June 6-8, 2017.
Read more
Each Month in 2017
Online
Software Expert Days - 2017
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all