DEVOPSdigest

DevOps is a powerful process that can catapult industry leaders into the next stratosphere of transformation success when combined with the right people, process, and technology. The converse is also true. Applying DevOps principles of agility, continuous integration and delivery without addressing broken processes, gaps in skillsets or technology – is a recipe for disaster.

This 3 part blog series will focus on the people and process challenges that impact DevOps implementations across 3 areas – Business, Technology Leadership, and Technology Execution based on my research for my latest book, iSpeak Cloud: Embracing Digital Transformation. This first blog will focus on the Business & Technology interaction.

Challenge 1: Assigning Right Seats at the Table

This last June, I was fortunate enough to be the keynote speaker at a CXO Forum in Seattle. One of the participants stated the best way to implement DevOps was to eliminate the Ops team from the planning and implementation phase. It was a relief that the others at the event did not share in that belief. Why? If planned and executed well, the DevOps leader will act as a Master Chef.

Master Chefs realize that although the magic happens in the kitchen without the right operations input and understanding of customer requirements they are doomed to fail.

For example, you can make the most exquisite chocolate cake in the world, but if your customer is allergic to gluten or chocolate; you will be wasting efforts. The same rings true if your operations team forgets to put in the order. In order for DevOps to truly work you need buy in from both your customers and operations team to succeed. It is important that when the process or initiative is created that the overarching governance committee reserve a seat at the table for key roles. Those roles should include Business Exec Sponsoring first Service Initiatives, Security & Audit Architect, Infrastructure Architects, Release Team, Support Staff and Financial Planning & Analysis.

Challenge 2: Gaining Executive Buy In

CEO's are personally driving Digital Transformation across key industries according to leading analyst firms such as Gartner. DevOps is at the forefront in helping to drive the agility needed for transformation if done properly with the right level of support. One of the biggest challenges these initiatives have had is communicating the right value to the executive level to achieve support.

The key to gaining Executive Buy In is working closely with Financial Planning Accounting and the Business to select Services and dependent workloads that support the top 5 company initiatives. Then ensure that from the beginning the costs and budget for technology is baked into the initial ask to executive leadership as part of the larger initiative. Some CIO's interviewed did not even call the initiative DevOps but Digital Transformation. They implemented a DevOps process as part of the bigger initiative.

The justification – similar to a Chef at a restaurant – is not all consumers have the time to learn how the sausage is made in the kitchen. They only really care that it fits their needs in terms of costs, agility, and compliance.

Challenge 3: Collecting Clear Requirements

If there are too many cooks in the kitchen – the soup will get spoiled. The same rings true for IT. Today there is a very large gap in communication on what the actual requirements are and what it will take to deploy them.

The most costly mistake is not having a clear understanding on the requirements. I observed during one large service mapping exercise that all of the leaders inputting the process had been with the company ranging from 10-30 years. There were no millennials from the floor included. The Sr. Business Leader allowed me to pull the top 10 performers. I asked them to correct the documented process while the rest of the leaders were at lunch. The wall looked as though someone splattered with bright pink sticky notes because the perception of what leaders thought employees were doing had drastically changed from what they were actually doing to process customers.

Innovation never happens in a vacuum. It is important to purposely include the next generation worker in the decision making input process to ensure that both vision and reality are aligned. It also provides a clear picture of requirements. As part of the seat at the table it is important that the DevOps Leaders (Business & Technology) conduct a field trip to observe (not speak or instruct) how the users of the service are actually using it.

Challenge 4: Automating to Enhance Agility

Perception is not always reality. No one realizes that more than the operations team within a large IT department. In iSpeak Cloud: Crossing the Cloud Chasm, the Cloud Chasm is defined as the difference between where the Business believes they need to be in regards to technology and IT's ability to deliver it.

Often times, the biggest perpetrator of Shadow IT is not the business but IT Developers trying to help the business by avoiding the gauntlet of operational requests. This is because many of the processes implemented around traditional IT Service Management were created pre-cloud and in some cases pre-virtualization era. As a result, valuable resources are loaded down reviewing changes in lieu of focusing on next generation enhancements, agility, or compliance.

Free up valuable resources by automating repetitive tasks such as Change and Incident management for routine changes such as patching, self healing, and security remediation. As part of automating these processes put in a single page form to enable the business requestors to complete the needed forms and have visibility into their changes.

Challenge 5: Clearly Communicating Changes Based on Impact

DevOps initiatives can be killed faster than they are started if there is a major outage or impact to the business.

For example, in one initiative the Developer's pre-released a new price list a month prior that was intended to enhance sales during the slow season. To their defense they did not realize that the dependent quoting tool would be affected or some of the undocumented down stream affects to the overall ordering system. As a result, their last quarter was significantly off and DevOps became a dirty word within the company.

Another example: an icon update (changed colors) caused widespread panic because employees thought it was a virus. They ended up receiving 10,000 calls into the help desk and costs estimated hundreds of thousands in lost productivity for those employees.

The key lesson to these mistakes is that there are certain changes business executives need to approve such as updating price list or any user facing applications. Those changes need to be clearly communicated and articulated. However, there are other changes such as system hardening data encryption, etc. that happen internally that will create too much noise and distraction. DevOps Services should be categorized based on user impact with a custom communication and update process that correlates.

Read Part 2 of the series, covering the Top 5 Technology Leadership Challenges.