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

How to get to Continuous Delivery and thus, Continuous Innovation


As we discussed in a previous blog post , Fluid IT must be able to Continuously Innovate, which means that they must be able to Continuously Deliver new versions of their product. Which in turn means that new application versions will be constantly moving thru the application development lifecycle and into production. This is not something dev and ops are typically setup to handle.  We need to change our tools, their integration, our attitudes and behaviours and our measurements.

 This is known as DevOps and it is the second cooperation area between Fluid IT and Core IT (here is the blog post that introduced the idea of Fluid / Core IT cooperation areas).

1. The old way of getting projects out

A number of years ago I was in product development in HP. In our team was a guy called Martin. While all other members of the team had a small set of drawers and small storage cabinet, Martin had three, huge, multi-shelf storage cabinets, all lockable. Anyone new to the team would observe this, and eventually curiosity would get the better of them and they would ask Martin why he had such a mega--storage-setup. With gusto, he would unlock all three storage units and in a series of swift movements, would reveal their contents like a magician concluding his show.

The storage units contained servers, and disks, and memory, and cables, and software, and keyboards, and mice, and power units. Why was Martin so well equipped? Because if a new sub-project was created, or you needed a test system, then Martin was your man. He and his junior side-kick could put together anything your heart desired, provided the lab manager OK-ed it.

While this was wonderful for our team, it was sub-optimal for HP - thousands of dollars of kit sitting unused a lot of the time. But our lab manager was famous for getting projects out of time and to quality.

Forrester’s view of where project delays lie

The diagram below is a nice depiction from Forrester of where the delays in a typical IT project lie.

9. devops delays.png

 a. "Waiting For" 

 You will see that there is a lot of “waiting for …” - which is where Martin and his side-kick came in.

 b. Manual Handoffs

 And there are a lot of manual handoffs between teams, which are, of course, slow and error prone.

 c. Optimized Siloes 

 And, because we measure dev and testing and operations as separate silos, there is no holistic view across all three. We are thus, "optimizing in the small". 

 d. Manual plumbing into the data center 

 Further, you’ll notice that operations has to manually “plumb the application” into the datacenter.  This is also slow and error prone (and exceedingly boring if you have to do it two times a week for each application). 

 e. Slow, subjective product feedback 

 When I moved from a development engineer to a product manager, I was responsible for gathering the feedback from our beta programs. I would get on the phone, call the beta customers and ask, “so, how’s it going?” The answer was typically, “yes, pretty good. Not sure about the green title bar, but pretty good”. And if an important customer didn’t like a feature, we would change it. Should a smaller customer be unhappy, we would “have a think about it”.

In other words, our data was very limited, it was subjective, and, because I had to manually call each customer, it was collected slowly.

2. Getting rid of project delays

If we want to get to “Continuous Delivery” where one or two versions of the application come off our application production line every week, we’ve got to get rid of these delays. How do we do this?

9. devops after.png


a. We automate everything

We automate everything. We automate the provisioning of our dev and test environment. We automate the provisioning of our system test, our limited rollout, and our production systems.

This is the same automation and “cloudification” that we talked about when we discussed the Service Provider services that Core IT must create for Fluid IT. (Here is the post on that subject)

b. We have a single model

It’s all very well being told, “you must automate”, but before you can automate, you have to build the automation model. And this is time-consuming. Sometimes, it’s so time-consuming that people feel that the modelling outweighs the benefits of the automation.

And so, we create one model - a model up front in the dev phase - and then we reuse that model to automate our testing, to deploy the application for system testing, to deploy for limited rollout and to deploy into production.

9.single model.png

That same model feeds the management models used for availability and performance, for automated compliance scanning, for unified security management, and for application-level data protection.

c. We integrate tool chains

In the “old days”, the hand offs between different stages in the application lifecycle were manual. We need to automate these handoffs to reduce delays and to cut out error. We do this thru integration of tool chains. This is easier said than done because it seems that every team has its own “tools of choice”. And so, our tool-chain integration must be able to work with all the different source control, provisioning, build systems and the like.

d. We have an holistic view

Adam Smith was a very smart guy. He was a Scot who lived nearly 300 years ago and he came up with two big ideas. The first was to introduce the concept of free-trade in his book, “The Wealth of Nations” (a book which, occording to uban myth, Margaret Thatcher kept a copy of in her handbag at all times), and the second was to do with the “Separation of Labour”.

9. adam smith.png

Separation of Labour is the idea that rather than one person creating a whole cart, we have one team that does the wheels, another the body and a third, the harness. It was a great idea, if you are manufacturing something carts, cars or dishwathers. But, when it comes to doing Continuous Deployment of innovative, fluid, creative, experimental apps at the rate of two releases per week, it limits the speed at which you can go from dev/test into operations.

And one of the best ways to get out of our Adam Smith-silos is to collect performance data across all of the steps in our application delivery-to-production process.

(Wikipedia gives a fascinating account of the emergence of division of labour as a concept and the opponents of it, who included, surprisingly to me, Carl Marx.) 

e. Use big data to quickly and accurately collect customer usage data

Big data allows us to take the “machine data” - the touch streams in the case of smartphones and tablets, for example - and from these gigabytes of data quickly and accurately figure out what our customers like, what they don’t like, which features they use, and which they don’t use. This allows us to make objective decisions as to how to improve our user experience for the next release of our products.

If you use such big data analysis, you are in esteemed company. Twitter, the gaming division of Sony, and Jabber all routinely use such techniques.

3. Summary

We have just scratched the surface of DevOps here. But if we want to have cooperation between our Fluid IT, releasing at the rate of two updates a week, and Core IT, looking after our data centres and our Systems of Record, we need to ensure we have DevOps processes, models, integrations, attitudes, goaling and tools to make this work.

Here is our main web page on DevOps if you'd like to learn more about this subject. 

4. Related Blog Posts on The Digitization of Everything

Below is a list of related blog posts on The Digitization of Everything and Core / Fluid IT:

1. The Digitization of Everything and A New Style of Business : digitally-based, software-powered products allow the business to do things very differently. We can release "minimum viable product", we can experiment with new products we can "continuously innovate".

2. Digital Disuption: From Transforming a Product to Disrupting an Industry : digitization starts with a digital product that replaces the analog one. Think CD or DVD or home thermostat. But, once products are digital, the business model can be disrupted - think Spotify, think "the connected home", think Uber, think AirBnB. This blog looks at this disruption for a number of industries including transportation, retail banking and the connected home. 

3.  Digitization of Everything and the role of Central IT : digital disruptions are "software powered". Which is great because IT creates software, doesn't it? But it's a very different style of software development to that that we used for our Systems of Record. 

4.  Capitalize on The Digitization of Everything with two different IT modes : IT can't be innovative, cool, experimental and reliable, careful and solid using the same people, the same behaviours, the same processes, the same supplier relationships. We need to split IT into two - Core IT and Fluid IT.

5.  The Guardian Function - making the Core / Fluid IT co-operation work : If the two parts of IT, the Fluid and the Core, don't cooperate with each other, we'll eventually become uncompetitive and inefficient across the whole organization We need to ensure that the two parts of IT work well together. This is part technology (as discussed in the next blog post) and partly about governance, finance and attitudes. This blog post talks about "The Guardian Function"; that function that ensures the cooperation works.  

6.  The Five Areas of Cooperation between Core and Fluid IT : I've broken the technical aspects of cooperation between Core and Fluid IT into five areas : i. Service Brokering, ii. Continuous Delivery, iii. Creating a best-in-class user experience, iv. Big Data and v. Protecting your assets. This blog post looks at these five areas in overview.

7.  Service Brokering for Core and Fluid IT cooperation : This post dives into what customers tell me is the most important of the five cooperation areas; Service Brokering. 

8. (This blog post) How to get to Continuous Delivery and thus, Continuous Innovation : This post looks at the second cooperation area; getting Continuous Delivery of new functionality. This entails a flow of new releases from Fluid across to Core IT. It is, of course, DevOps, but I've put a Core/Fluid IT spin on it. 

9. How to create an Engaging, Best-in-class  Digital User Experience : Digital products pretty much always mean either a mobile application and / or a smart device like a smart cooker, a smart thermostat, or a smart shopping trolley. We need to ensure that the user experience of that mobile application or smart device is best-in-class. How do we do this across our Fluid and Core IT teams?

My "" topic on the Digitzation of Everything - a couple of times a week, I post interesting articles on what's happening in the world of "the Digitization of Everything".

Screen Shot 2015-09-07 at 09.16.17 7 Sep 2015.png



Mike Shaw
Director Strategic Marketing

linkedin.gifMike Shaw

0 Kudos
About the Author


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. .

Jan 30-31, 2018
Expert Days - 2018
Visit this forum and get the schedules for online HPE Expert Days where you can talk to HPE product experts, R&D and support team members and get answ...
Read more
See posts for dates
HPE Webinars - 2018
Find out about this year's live broadcasts and on-demand webinars.
Read more
View all