Skip to main content

This post is from the XebiaLabs blog and has not been updated since the original publish date.

Last Updated Jul 29, 2015 — DevOps Expert

What’s more important – Process or Tooling?


We recently had the fortune of conducting a webinar – “How one of the 15th safest banks in the world out-competes the tech disruptors” -- with our customer Rabobank, a leading financial services company.Sander Ettema, Manager, Linux Infrastructure Services at Rabobank and Andrew Phillips, our VP of Products, discussed how Rabobank transformed its software delivery by implementing Agile development, Continuous Integration and Continuous Delivery. Listen to the entire webinar here: "Continuous Delivery and DevOps at Rabobank" At the end we fielded questions from the audience. Here's what we learned... 

Q: To succeed in Agile Development, Continuous Integration and Continuous Delivery, what is more important -- process/culture or tooling?

[caption id="attachment_9116" align="alignright" width="220"]AndrewPhillips (1) Andrew Phillips[/caption] [caption id="attachment_10353" align="alignnone" width="221"]sander Sander Ettema[/caption]  Sander: Rabobank has leveraged Continuous Delivery for DevOps -- a process that is transparent, whereby infrastructure is fixed and thus developing/building/testing code can be repeatable -- so that Rabobank can create, try and test quickly new applications to meet the banking customer’s demand for more online banking capabilities. If the process is always the same – fixed – you can focus your attention on the code. Everything is built in the code, and there are virtually no manual processes. Via this dynamic, you can deploy the code in one environment, and you can try it in others. By having repeatable infrastructure, we achieve repeatable application development and deployment. The code can be transported quickly through the pipeline from development to production – a nice flow. In this process we gain knowledge. It gives us transparency into where the code works, doesn’t work, performs or doesn’t perform how we expect. We have vision into the code and we use this vision to learn – not blame. Because we have this feedback early on in the code development and build processes, we can quickly learn and go back and re-create without feeling like we need to blame anyone for creating a code that doesn’t perform as expected. We can afford to learn because we have repeatable infrastructure and much is automated to move things from code to build to production -- quickly.Andrew: Before, when manual processes ruled the day, going from code dev to build to production would take much longer. Thus when something might go wrong it might be discovered after much time had transpired, and thus re-creating the code or developing fixes would involve more pressure, more cost. When you have a flow in which you have time to learn – time to make mistakes and correct them – the pressure of the “we’ve got to find someone to blame and fire someone” dynamic no longer exists. With Agile Development, Continuous Integration and Continuous Delivery, you can afford to develop code, build it, test it and learn in the process and be all the better as a result.  

More from the Blog

View more
Feb 22, 2021

Reckoning DevOps’ role in the enterprise value stream

If you’re a software or digital solutions company, you may use DevOps ...
Read More
Feb 10, 2021

Customer spotlight: Schneider avoiding bumps in the road with DevOps adoption

Everyone wants to deliver software faster and more reliably. Companies ...
Read More
Jan 06, 2021

How testing automation can build a culture of QA while accelerating continuous delivery

An organization’s level of automated test coverage is quickly emerging ...
Read More
Jul 30, 2020

Part 2: Is Technology Slowing Down Your Digital Transformation?

In part one of this post, we shared insights from Andreas Prins’ webin ...
Read More
Contact Us