Here are five top lessons that I learned from organizations about DevOps in the enterprise from my travels in Europe late last year.
I recently visited Europe for the Continuous Delivery (CoDe) conference in Copenhagen, DevOps Days Berlin, and DevOps Days Ghent. I presented a keynote in Copenhagen: “DevOps and Cloud: Tips & Techniques to Revolutionize Your SDLC” as well as a couple of short Ignite-style sessions: “Five Minutes for 10 DevOps Tools” in Berlin and Ghent.
However, I spent most of my time learning from other experts in the DevOps field, so I thought I would pass on the top lessons I learned for enterprises from these excellent conferences:
Enterprises are different
It is easy (and true) to say that ‘DevOps is DevOps,’ but every discussion with enterprise practitioners reinforced that they solve different problems in different ways compared to smaller organizations. For example, some comments included:
- “Our challenge is how to deal with people around the globe. We’ve done some co-location, but we can’t co-locate our Indian dev lab with our local [German] ops team.”
- “Our documentation has to be complete before we release, otherwise the FDA won’t let us certify products.”
- “Try dealing with DevOps in the middle of a reorg! It is incredibly hard to know which people to get on board.”
- “We can’t use Post-Its for Kanban. Facilities says they’re a fire risk – they burn too fast.”
From different definitions of ‘done’ (to include documentation and risk management) to different audit requirements (‘bring auditors into the scrum’), enterprise attendees at all three events articulated how they were taking different approaches from any of the attendees from smaller organizations. They all had the same core goals – ‘DevOps is DevOps’ – but were looking at different ways to achieve them.
Enterprises must treat ‘legacy’ with respect
Enterprise attendees were especially concerned by mainframe, AS/400, and COBOL environments with 20, 30 and even 40 years of accumulated baggage – a topic that came up time and again in the Open Spaces.
A key lesson from these discussions was that we need to start by giving legacy systems and people the respect they deserve. As on attendee noted, in many contexts ‘legacy’ is a very positive quality (e.g. ‘leaving a legacy for future generations’).
It is especially important to respect so-called ‘legacy’ people. Instead of blaming them, seek to include and learn from them. Ask questions, find compromise, learn what they do well, understand what works and why, include them in communications and rotate them through other teams.
If you only treat legacy as a problem, they will resist and push back; but if you treat it as a valuable part of a bigger picture, you will learn not only how to adapt legacy to the new ways of DevOps, but also how the organization can benefit from the very real value of legacy experience.
Enterprises must stop doing old things
However, when dealing with legacy environments there was also agreement that it is important to switch services off when their time is done. Otherwise you will end up with legacy in its most pejorative sense as system artifacts rot over time.
It is natural that systems sometimes fade into ‘maintenance mode.’ Maybe the business has shifted its focus; maybe there is conscious decision to prioritize other systems; maybe it happens accidentally as the business moves towards the next big thing.
However, it is critical to make intentional (and often difficult) decisions to switch off these systems once they are past their due date. Otherwise you will never free up the time, resource and budget to do new things in new ways – the lifeblood of innovation.
Enterprises must highlight their technical debt
Similarly, the topic of technical debt was mentioned repeatedly, and seemed especially pertinent to the attendees with large legacy environments. While technical debt is not unique to enterprises, they certainly do face more calcified technical debt than startups can even imagine.
There was no hard and faster solution from attendees, but discussion coalesced around the necessity of not hiding technical debt as just “an IT problem,” but rather highlighting especially to business leaders the real impact it has on business.
Suggestions included: discuss it outside just dev and ops; communicate the impact on the organization; expose the impact of rigid systems; seek agreement on a slower pace of delivery; and make sure technical debt means something in business terms, such as CapEx, OpEx and ROI, for example.
Enterprises cannot hire enough DevOps people
Staffing was a constant theme throughout the conferences – every job board at DevOps Days was full of open positions – but my key takeaways on this came from two presenters at CoDe Copenhagen.
Benjamin Wootton from Contino (@benjaminwootton) and at CoDeCPH spoke about how hard it is to attract the top engineers particularly to enterprise shops. One key problem that resonated with many enterprise-minded attendees is that there are simply not enough ‘T-shaped’ people to fill all the openings that DevOps is creating. Some businesses will miss out, most likely enterprises.
Paul Speers from Speerhead (@Paul_Speers) elaborated in his presentation:
- “The real unicorns in DevOps are the staff. DevOps people are magical, mystical, people. Even HR doesn’t know what they do!”
- “You cannot sprinkle magic dust to make your own DevOps people. But with mentorship & training you can get there.”
- “The organizations that are getting the best DevOps people are the ones that show they care about their engineers.”
- “Job boards are dead; email blasts are noise; community is everything in recruiting for DevOps.”
Bottom line – enterprises especially will need to train existing staff on the culture, technologies, and processes that make DevOps work.
Certainly many of these lessons can be applied to smaller organizations; indeed some of this is just ‘good hygiene’ for any IT environment. However, in the discussions I had, enterprise practitioners all identified these five areas as creating unique challenges for larger and older organizations. So I hope some of these ideas help you figure out your approach to enterprise DevOps.
Originally posted at http://blogs.ca.com/2015/01/08/five-lessons-europe-enterprise-devops/