Transitioning to DevOps: The four priorities

Transitioning to DevOps: The four priorities
Kevin is a Global Solution Architect at NGINX where he specialises in application delivery, routing, monitoring, and load balancing. Kevin has passion for technology and art. He previously worked as a Site Reliability Engineer and Production Manager for and most recently as a Technical Solutions Architect and Product Specialist for NGINX.

Enterprises across the world today are becoming increasingly interested in leveraging DevOps to deliver applications and services at a fast pace. However, at most organisations, awareness of DevOps has remained confined to abstract principles rather than practical knowledge. There is a strong misunderstanding about the purpose of DevOps and, as a result, many companies are far less confident in implementing agile operations on the ground.

So, what do organisations need to look out for? And how can enterprises choose the right DevOps tools to suit their needs? Here are four priorities enterprises need to consider when transitioning to DevOps environments.

Setting the goals

What are we trying to achieve? Is it to modernise our applications? To transform our infrastructure to achieve agile development? Those are the questions organisations should be asking about any transition towards DevOps. 

For uncertain organisations, the first step when it comes to DevOps is to outline a clear set of goals, identifying where they really want to be from a technical perspective. It might sound simple but by setting out the goals and making that match with what the business as a whole is trying to do will help you realise your vision. Always have a roadmap because there’s always somewhere you’re trying to get to.

Choosing the right DevOps tools

Once a clear set of goals have been established for DevOps transformation, organisations must decide on which tools to adopt but with so many options to choose from, it’s important that companies are choosing the tools that best match their use cases.

Before purchasing a new tool or platform, it is vital to be proactive by meticulously testing each possible choice and you want to make sure that the tool you select reports on all the factors you care about – response time, memory usage, requests per second, and so on. The key lies in making sure that the tools will solve the problems for the goals that you have set out. Taking the time to ask those questions about the viability of new tools allows you to make a much more informed decision about the devices you adopt.

Fostering cross-functional communication

Perhaps the most challenging obstacle most organisations face when transitioning to DevOps is fostering communication between the business and technical sides. All too often companies adopt DevOps processes but not the non‑siloed organisational structure required for effective collaboration between functional teams.

In a lot of organisations, DevOps teams don’t necessarily have much control over what’s going on, yet they have the technical knowledge to make it happen. It’s like a balancing act – both teams on the business and technical side need to both be inputting and making decisions together if they want a smooth journey. 

It can be helpful to inspire discussion with the teams to make sure that the right decisions are being made. If a department or stakeholder wants to adopt a particular tool, then it’s important that the DevOps team have their say in whether it will improve the environment by adding value and not adding unnecessary complexity to the infrastructure. There are many tools out there to adopt, but as a group, teams can make educated decisions to accomplish the overall goal.

For most DevOps teams, internal or cross‑team communication is a challenge due to their enormous workload of production escalations, ticket backlog, and change management planning, but that doesn’t have to be an excuse for a backseat approach. Even though DevOps teams are typically busy, they should make themselves available for these kinds of discussions, being involved in the business as much as possible. Opening a dialogue between disparate teams is as much a cultural change as it is an operational one.

Measuring success in DevOps

Like any operational methodology, DevOps is about results, but many companies find it difficult to measure DevOps effectively. 

There are all kinds of factors we can measure but in general, there are three main examples of measurement: cost, modernisation, and performance. We can talk about economic results but what is it that we’re trying to achieve from a financial standpoint? Maybe it’s not related to money at all. Maybe it’s tracking a migration from using legacy applications or legacy infrastructure to more modern infrastructure.

The other possible measure of success is the performance of the application over time. For this, organisations should ask some basic questions beforehand, such as “Is the application performing better than it was last month, or better than it was last week? Also, what is the end‑user experience?”

Successfully achieving a goal relies on open communication and unity between the business and technical sides of a company. Collaboration is necessary to outline what results you’re looking for and the tools you plan to use to deliver them. In regular discussions with the business teams, the DevOps team can provide expert guidance throughout the transition.

Making DevOps work for your organisation is about starting with a clear end goal in mind. If you have a goal to work toward, you have a reference point to help you ask the right questions. Most of the time, DevOps is a lot about the culture and just being involved in the business as much as possible, every step of the way.

Interested in hearing industry leaders discuss subjects like this and sharing their use-cases? Attend the co-located 5G ExpoIoT Tech Expo, Blockchain Expo, AI & Big Data Expo, and Cyber Security & Cloud Expo World Series with upcoming events in Silicon Valley, London, and Amsterdam.

View Comments
Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *