Niek Bartholomeus

Niek Bartholomeus

Niek Bartholomeus

Niek Bartholomeus is a DevOps and Continuous Delivery evangelist who has implemented a Continuous Delivery pipeline during his most recent mission at ReQtest, a small agile company. Before that he was a technical architect at a large financial institution where he was responsible for bringing together the dev and ops teams, on a cultural as well as a tooling level. He currently works as a DevOps consultant for BMC. He has a background as a software architect and developer and is fascinated by finding the big picture out of the smaller pieces.

Q: How did you get involved in DevOps?

A: I was part of a team that was responsible for the development tools and practices within a large investment bank. at one point we realised that the biggest bottleneck in delivering the software into production was the lack of understanding between the development teams and the operations teams. Until then my activities has remained mostly technical, but this issue really had to be solved on the human level, so a whole different approach was needed.

Q: What do you see as the biggest advantage of DevOps?

A: When the development and operations teams have the possibility to learn from each other, to appreciate each others work, they will start seeing the bigger picture of the work they are doing, which is delivering value to the end user. This insight alone will help them make decisions in their own area that are beneficial for the whole organisation, and not only for their team.

Q: What do you see as the biggest challenge in DevOps?

A: In many traditional enterprises there is still an old-school mindset that software development is not a strategic advantage and therefore cost-efficiency is considered more important than delivering business value. In these enterprises the teams in the IT department are typically structured by technology, effectively creating specialist silo-teams with little opportunity for mutual collaboration, in an attempt to increase efficiency. Unfortunately, these types of organisation structure simply don’t work in a domain like software development that is complex and creative. Instead, what is need is a better collaboration and alignment of the objectives between the teams, or, in other words, DevOps.

As this old-school mindset gets stronger as we go up in the hierarchy of the organigram, the easiest strategy on first sight to introduce DevOps seems to be a bottom-up approach where the people on the floor initiate the effort and then let it organically “infect” the rest of the organisation. However, as the old and new mindsets are so fundamentally different it may not be possible to make the switch by gradually evolving from one to the other. Instead we may need something more disruptive, where the pressure to change not only comes from the bottom, but also from the top, and from everywhere else.

In the end, my guess is that only external forces like increasing competition, shrinking market shares and eventually the struggle to survive can set the stage for building up the necessary pressure to change.

Buy the book

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s