While promoting Digital Transformation, everybody thinks first on customer centricity and therefore on front-end interfaces that should better reply to customer needs anywhere, anyhow and at any time. Usually, a big focus is also given to Marketing departments which have to provide an appropriate solution to these new types of customers.
These points are right, of course, but delivering the best service is not only a question of marketing and on offering the best “app” to proceed to product ordering. It is also (and maybe first) a question of showing high flexibility in replying to market trends and to customer demand.
- If a new product needs to be launched, how much time is it needed between conception and delivery?
- If a client is requesting support, how much time till he gets a solution?
And how many people will get involved to solve his issue?
And then eyes move to IT, continuously challenged to deliver quicker, never fail, and this at (almost) no costs.
Gaining in Agile-IT (agility)
On the development side, big progresses have been executed by putting business closer to IT through new project management styles like Agile / SCRUM. This approach, preferring a step by step development to the very usual waterfall concept does help to better reply to business needs and therefore (hopefully) to customer expectations. Success of this method has been already demonstrated for a few years and should therefore be considered by many of us. It may be even extended to a larger scope as explains famous industry analyst Jason Bloomberg in his interesting article “scaling agile software development for digital transformation” on Forbes, promoting Dean Leffingwell’ SAFe framework.
But this is only one piece of the cake. Trying to better reply to requirements by showing flexibility in the development phase is a good step forward but guarantee that new releases will run smoothly once in production (although Agile has shown some positive effects on this side, still) neither that execution of tasks will be automated enough to gain in responsivity in front of the customer. In many companies, still Today, releases are executed 3 times a year, even while using Agile methodology to create them… How can we expect proactivity as such?
For these, IT department have to do their homework… And then came a new acronym:
What do we really mean by DevOps?
DevOps is a compression of two words: “development” and “operations” that expresses (to make it very short) the idea to put closer both usual IT universes that are “creative” developpers on one hand and “wise” administrators on the other hand. We’ll come back on this.
The concept is actually a bit broader and Daniel Green delivered a very good definition of DevOps on Techcrunch: “a set of practices, tools and policies that lead to improved quality and Automated Delivery (AD)“. It would enhance the idea that such approach is expected to increase trust and collaboration between different departments in order to quicker take in account feedback from customers (internal or external).
“Run” and “Change” working together
One of the key factor of this concept is of course to put IT people from the two “sides” speaking to each other. Very often, these are from two different departments, with even two different reporting lines. Challenge may be high and will require in any case a clear support from the CIO to break the ice and help these people to exchange on their own priorities and constraints.
Maybe it should even require a review of the organisation to setup teams involving developpers, administrators, and hotline people together.
Automating integration processes could help such collaboration by putting in the hands of the developpers themselves the identification of defects without involvment of maintenance teams. There are already very good tools in the market to support such automation like the famous Jenkins or Buildot. Nevertheless, although such tools are very good in identifying issues occuring, they execute their job only after implementation. That may imply the need to postpone the roll-out by first executing tests in a test area, reproducing 1 to 1 productive environment. Border effects of such way of working are easy to understand: reduction of speed and high costs (maintaining such a test environement will be quite expensive).
This goes a bit against the concept of continuous integration (if you want to have deeper view on this approach, I recommend a valuable article from Martin Fowler). Ideally, developpers should be able to submit their code to an automated process, able to reject the code before executing the roll-out. It looks like Zuul (created by OpenStack foundation as reference to the gate keeper in Ghostbusters) would fit to such idea.
On the other hand, there is a lot to do as well on the Ops side. Many processes could be automated there as well, particularly on the monitoring side. Here too, many tools have provided a more professional approach than “just” Powershell. Best practices tend to recommend usage of automated infrastructure provisioning tools like Chef (their claim to consider infrastructure as a code is quite innovative) and Puppet.
We already saw that Agile could be use in a more extended manner than just “in development projects”. This can actually also help Operations by combining it with the IT Service framework ITIL as described by Darren Goldsby & Shirley Lacy in their presentation “Digital transformation using Agile and ITIL”.
But all this will work only if the whole company share such a vision. It won’t work if tempation of Shadow IT raises up and let business doing their own stuff aside. As a consequence, a strong governance policy should be put on top, covered in most of the cases by a central IT unit in charge of overall monitoring of IT projects and processes even in a distributed organisation.
Where is the RoI?
When it comes to improving IT by itself, top management uses to not identify easily the business case, and therefore to allocate the right budget. This is always the paradigm that all CIOs have faced many times in their life: deliver quicker and better but don’t get budget to improve yourself!
On that case, Digital Transformation trend may help them to convince Business and CxOs by demonstrating the improvement of the delivery chain obtained by automating some “internal” IT processes. For this, it will be important to provide figures, attached to easy-to-understand indicators. The best of them is most probably “time to market”. In 2013 already, Computer Associates published a survey confirming that adoption of DevOps sped up new services and products to market by 20% for the people having replied to it. In any case, developping a set of KPIs to justify the investment will make sense. CA is suggesting an approach for this.
Offering some indicators connected to what the company use to have in place will support as well the acceptance of such investments. We already mentioned ITIL, but maybe CMMI would be even a better model to identify the maturity level of the company and use it to promote improvements to execute.
Maturity level on DevOps could be defined as such:
- Level 1. : companies that haven’t started doing DevOps. No operations automation or change control in place;
- Level 2. : project teams are using automation but not in a coordinated way. For example developers use change control, but administrators don’t, or use a completely different system;
- Level 3. : Dev and Ops are sharing the same processes and tools and hand-off issues are minimized. This could be considered the most basic level of DevOps integration;
- Level 4. : Same metrics are shared by Development and Operations and both are responsible for site availability and performance;
- Level 5. : processes are being continuously automated away by DevOps engineers so that any repetitive processes in their daily work are eliminated by increasingly sophisticated tooling. Developers work to a self service PaaS model.
Setting up an appropriate framework
All in all, there is a lot of to do for most of IT department to achieve this. This approach, although not that new, remains quite innovative for many companies. As usual, the first question that will come is actually: “where to start?”.
Most probably, this will reach the hands of company’s Enterprise Architects who will have to “fix the rules” and draw some first principles and publish a blueprint. The basis of such capability framework could be driven by these few elements:
- Industrialize IT services to get rid of tasks that could be automated through efficient software;
- Offer flexible platform to facilitate innovation;
- Support cross department communication to remove potential pitfalls before they even appear;
- Don’t forget the customer.
To go further, I suggest to have a view on IBM “DevOps Best Practices” serie of articles ->here<-