DevOps and the bridge to Traditional IT

At the end of last year there was a lot of talk about which IT trends would be shaping 2016, when Internet of Things, Virtual Reality and Artificial Intelligence were among the front runners. With Q1 firmly behind us it is clear that some have already made their mark with Google’s AlphaGo AI defying a millennia of basic human instinct when it beat Lee Sedol, one of the world’s best Go players, just being one example.

With technology innovation moving faster than ever, it is easy to get distracted and forget about yesterday’s news. Take cloud as an example. Many organisations are still working out what it means for them to leverage “traditional” compute and storage servers in the cloud and a constant “noise” about the latest advances in cloud technologies is likely to confuse rather than help.

I’m not suggesting we stop embracing new technologies, rather the opposite, but most organisations are unable to move at the same speed as a Silicon Valley start-up so it is important to find the right pace for change while taking it one step at a time.

So what does this have to do with DevOps?

Gartner says that this is the year when DevOps will evolve from a niche to a mainstream strategy employed by 25 percent of Global 2000 organisations. A quick search on LinkedIn reveal 11,645 posts related to DevOps (this looking to be post 11,646) and Google Trends shows an exponential growth in the interest of DevOps.

This is great news, isn’t it? Yes it is, but DevOps is becoming “old news” with many vendors and professional services companies looking for the next big thing to “sell” at a time when organisations still need help to land their DevOps initiatives, or to get them started.

Changing the culture and embedding Agile and DevOps principles, particularly in large enterprises, takes time and only hard work will get you there, not the latest technologies. So blame unrealistic expectations, not DevOps, if results are not delivered quickly enough.

I like the simple, yet powerful, message behind ING’s successful “journey towards a more agile enterprise” presented by their Chief Architect, Henk Kolk. ING set out on their journey back in 2009, but it wasn’t until 2013 they achieved full reorganisation with 180 DevOps teams – their results didn’t come overnight.

A key point that Henk makes is that “nothing beats engineering talent”. A common misconception these days is that anyone can do IT, but this can be a very costly mistake. Take Healthcare.gov as an example, where a tiny team of Silicon Valley’s top engineering talent was brought in to rescue the project. The outcome? The original solution cost $200 million and would have required $70 million a year to maintain. The revamped version of the site cost $4 million to produce, with annual maintenance costs also $4 million. Talent over mediocrity.

So what about my traditional IT department?

Organisations often start to explore DevOps alongside existing IT initiatives, which is great from a learning perspective, but new challenges arise when a push for wider adoption is made. In my previous blog, Conquer your Systems of Record, I explained some of the challenges around agile and traditional IT systems so I won’t repeat it here, but it is inevitable that things get more complex when applications start to cut across several teams, environments and backend systems, all changing at different pace.

This shouldn’t discourage organisations from starting to adopt DevOps within their “traditional” IT departments, it simply needs to be done differently and with greater care. Don’t forget that systems and people grew up in a time when technology change was measured in years, not months or days.

So how do I make it work?

I guess that is the million dollar question, isn’t it? Unfortunately, there isn’t a single, or simple, answer to this question as all organisations are different. There are however a few things you may want to keep in mind before embarking on your journey.

Educate yourself

Sounds like I’m stating the obvious, but many organisations rely too much on external expertise when it comes to strategy, plans and implementation. Learning from other organisations and working with vendors and partners is important, but find the ones that want to build something with you, not do it for you. For a large enterprise, few outside the organisation fully understand the complexity of your legacy domain so don’t expect them to have all the answers. It is therefore critical that you build up your own knowledge and involve stakeholders across the business where proof of concepts and smaller projects allow you to “build your way” to a better understanding.

Acknowledge that there is no one-size-fits-all model

Where new tools and processes have enabled daily releases of mobile apps it simply doesn’t work when it comes to your legacy systems. Sounds familiar? Don’t fool yourself in believing that because it works in one area it will work everywhere. This doesn’t necessarily spell bad news as daily releases for a core banking system may not be what is needed anyway so work out what truly matters and focus your efforts there.

Gartner introduced their Bimodal IT model to address the different needs within an enterprise through two “modes” of IT delivery. While establishing a framework to tackle this is important, I find that Bimodal IT takes a too binary view of the world through its two modes. It has however helped raise the awareness of the many challenges large enterprises are faced with while helping to boost the interest in other “multimodal” approaches that take a more nuanced view of the world.

Value engineering talent

Going back to Hank’s point, make sure you build up and motivate your top engineering talent before you embark on your journey. Hiring top talent may help, but “combing” through your IT department can unearth some hidden gems that can be priceless when it comes to systems knowledge and raw engineering talent. Balance new with old and start building projects around motivated individuals, give them the environment and support they need, and trust them to get the job done.

Final words

I’ve said it before: the recipe for success is a focus on people and culture, not only technology. It is important to create an environment for continual experimentation and learning, not in an isolated part but across the enterprise. Start small and don’t get carried away by the latest trends, tools and frameworks, at least not until you’ve mastered the basics.