Bringing Operations On The DevOps Journey

Bringing Operations On The DevOps Journey

Over the last few years the take up of modern engineering approaches has continued to create opportunities for development crews and architecture with exciting new methods, tools and associated mindsets to get useful software out to their associated consumers. One noticeable thing in most of the organizations I have either worked or consulted with, is the lag of operations to be fully integrated in the devops mindset and culture. This recently got me thinking, why was this so? and how could we address it? At first I wanted to understand this dilemma and why it was becoming such a common occurrence, was it due to the complexity of the organizational structure? Was the tooling slowing down integration considerations? Was there a missing skillset? Or had the associated journeys not been fully thought through? Or something else?

For those organizations who have done Agile and Devops well, bringing the operations teams into the same organization as the first step, seems to be one of the primary reason for ensuring operations is not left behind. Before this change, most ops teams are organizationally distant from the engineering team. To be successful both operations, development and architecture need to be one team if organization devops crews are going to deliver the best services. This close coupling between the individuals who are writing the code and the individuals who are operating the service itself allows for an increase in velocity and getting relevant features and capabilities into production. Whilst this sounds like common sense, you'd be surprised how many organizations still separate these functions, self-managing teams are still seeing blockers, because backlogs and journeys are hindered, due the reliance on operational process, tools and people. Looking forward to hearing how successful others have been in bringing ops into the fold and earlier in the adoption lifecycle of modern engineering practices and the challenges faced when doing so.

Whilst working at Microsoft, the engineering teams had highlighted a new significant culture shift that happened in that: software engineer accountabilities transitioned from responsibility not only building and testing but ultimately the health of production. This accountability shift had two aspects, feature teams obsessed with understanding their customers to get a unique insight into the problems they faced. Secondly, the feature teams and individual engineers started to own what they were delivering into production. Giving engineers the power, control & authority over all of the parts of the software process. In conclusion the most successful teams bring in operations early, helping change not only the process in doing so, but more importantly the mindset that is needed in an organization that's wants to embrace DevOps in its entirety.

Juana Mangaoang

Immigration Consultant at Chiyoda International Corporation

8y

Thanks Wayne. as a developer AND end-user, i can testify that there is no substitute for including the ops experience in the dev process. imo, the lack thereof is one reason we have so much awful-to-use s/w on the market.

Like
Reply
Al Ola

23 Years -Senior Qualified Chartered Digital Marketer & IT. BA, DipM, ACIM, MIDM, Prince 2 Operating @ Board Level

8y

I cant ready your hand writing below ?

Like
Reply

To view or add a comment, sign in

More articles by Wayne Filin-Matthews, B.Sc, M.Sc., F.BCS.

Insights from the community

Others also viewed

Explore topics