Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Embrace business and IT change: Find the right path with DevOps

David Mainville CEO and cofounder, Navvia

Change is inevitable in business. You know how it goes: You're working away, head down, and then something comes along that requires you and your team to change course.

The pressure to change can come from many sources: competition, changes in the economy, societal transformation, and new technologies. IT is far from immune to the rapid pace of change, and some even argue that we are leading the way by enabling and underpinning dramatic changes in virtually every sector of the economy.

My own company, Navvia, recently faced change in a big way when we decided to completely exit the consulting world and focus exclusively on our software product. This decision created numerous challenges to our staff, our processes, and our management. Ultimately, we decided to pursue a DevOps approach to manage this digital transformation.

These are the stages of the process we went through before we got to a stable DevOps method that worked for our business.



Changes in our organization

We've been in business for 18 years, and for most of that time we were a boutique consulting company. So when we adopted a radical change to our business model, we no longer had consulting revenue to fund software development and support. We now completely relied on software sales and renewals.

That meant we needed to:

  • Have accurate forecasting and revamp our sales process accordingly.
  • Set up a formal product management process to capture and prioritize requirements and develop a realistic product roadmap.
  • Implement a formal development strategy. We settled on agile, mainly due to its iterative nature and close collaboration with the business.
  • Improve our operational processes around release and deployment. This prompted us to look at tools to automate testing and deployment.
  • Refine our monitoring capability. We needed to do this not only from the technical perspective of infrastructure and application events, but also, and more importantly, from the perspective of our clients: How were they using the software, what issues were they encountering, and what features were they looking for? This information, in turn, needed to feed product development and sales forecasting.

Here's how we did it.

[ Special Coverage: Focus on IT Service Management at Pink18 ]

Get a plan together

For starters, we knew we had to get everyone on board, working as a team. We turned to the great books by process experts such as Simon Sinek, Jim Collins, and Dr. John Kotter. I made sure our management team read and understood these books before we focused on how to engage the team. Here are the major concepts we put into practice.

Start with explaining why

Sinek’s book, Start with Why, is a great reference tool for getting a change process off the ground. Change evokes a lot of emotion. Some people are excited and motivated by it; others are skeptical, and for some it is downright scary and causes them to shut down.

Communication is the best way to address those fears, and you start by explaining why. But it's important to explain in terms that are relevant to the individual.

Get everyone on board

Another excellent reference is Collins' book Good to Great. You can explain why something is important, but that doesn't mean everyone will ultimately accept what you're saying. To be productive, you need everyone in the boat and in the right position. In our case we were able to reposition some people. For others, there was no longer a place.

Change is a process

Kotter's eight-step process for leading change, which he describes in his book Accelerate: Building Strategic Agility for a Faster-Moving World, focuses on the success factors in an organizational transformation. You can't just snap your fingers and make the change happen. Change is a process of continually communicating, building support, getting quick wins, and embedding change in the organization while measuring improvements and making corrections along the way.

Engage the team

The change needs to be owned by all of us. While senior management may ultimately be accountable for the success of a change, the change cannot be brought about without the team's support.

The best way to build support is through engagement. For everyone to own the change, you need the team's input at every phase of the process. So make the team part of the design, and give it responsibility for rolling out aspects of the change.

We regularly reminded folks of the ultimate destination, provided status updates about where we were, and solicited feedback. We did that both in casual, one-on-one meetings with staff and in team settings and all-hands meetings.

Put theory into practice

We had our general approach and our principles in place. But when it came to the specifics of our business, there were a lot of things we had to consider. In making the shift from a consulting company to a software company, where do you begin, and how do you ensure that you are focused on the right things and not heading down a rabbit hole?

We needed to look at the big picture, so we turned to a combination of value-stream and customer-journey mapping.

Because we started out in 1999 as a process consulting company, we had experience taking a process-centric approach to things. But with new people coming on board, we wanted to formalize this way of thinking through training and staff involvement. At a high level, here’s what we did next.

First, we identified our high-level value stream:

  • We develop the product; we were doing an adequate job, but could always improve.
  • We sell that product to clients; improving how we sell the product would fund additional enhancements.
  • We support what we sell.

Second, we looked at our metrics, at how the business was doing, and how leaders felt about specific business functions. Selling the product decomposed into the following:

  • Marketing the product
  • Making new sales
  • Obtaining customer renewals

We determined that our marketing was effective relevant to our budget and the size of our company. That is, we were getting leads.

Third, we decided to focus on new sales and renewals and started with the new sales process.

  • We mapped the sales process into its key activities and each activity into its subsequent steps.
  • We looked at historical data to see how long a sales opportunity remained in each activity.
  • We looked not only at why someone bought our product, but also at why a prospect didn't buy.

This work allowed us to get a handle on our customer-journey mapping goal. We were able to streamline the activities, build better forecasting models, and identify warning signs so we could prioritize spending our time with the clients most likely to purchase. 

A framework for success

While value-stream mapping did a great job helping to prioritize and improve, we were also looking for a model under which we could operate. For this we chose DevOps.

While DevOps is often seen as an IT framework, you can apply the concepts to any product or service.

It's a continuous approach to:

  • Steer direction based on business planning
  • Develop based on those requirements
  • Use a combination of process and technology to release and deploy new product continuously
  • Continuously monitor, not only for incidents and events, but also for customer feedback and continuous improvement

Here are some of the new processes and tools we rolled out to support the effort:

  • Steer: We built a product planning process, supported by collaboration technology, using input from customer support, clients, and the business to create our roadmap.
  • Dev and test: We embraced agile as our development methodology, with an emphasis on user stories and collaboration with the business. We supported the development process with collaboration tools and automated testing.
  • Deploy: Our release process remains an area for improvement, and once we pay off some technical debt (more on that later), we will be able to embrace containers as a way to streamline and automate deployment.
  • Operate: We improved operations by implementing new processes and tools for availability management, event management, and application monitoring. We also tweaked our incident management process and migrated to a new IT service management (ITSM) tool. We currently use metrics and feedback from these processes to steer future development.

Our next step will be to migrate our infrastructure from a traditional hosting company to one of the cloud service providers, which will give us a more scalable and global footprint. That will present a new set of challenges, especially around security, governance, risk, and compliance.

Paying off technical debt

In our case, resource constraints and the need to balance support with development kept us from moving to the latest technologies. Sure, we were on vendor-supported technology and always stayed up to date on patches and security fixes, but we weren't exploring next-gen technology.

This form of technical debt was getting in the way of some of the things we wanted to do from the perspective of both the product feature set and the infrastructure. And just as too much consumer debt can keep you from doing the things you want to do in your personal life, technical debt can become an anchor around your company's neck.

That’s why we are currently focused on paying it down. To do this we are migrating to a Microsoft-hosted version of Team Foundation Services, so we don't have to worry about maintaining the software.

We are also switching from Team Foundation Version Control to Git for version control. We have implemented a new front end using Bootstrap, we are moving from .NET Web Forms to Model View Controller (MVC), and we are looking at modern languages such as Angular. We are also launching a proof of concept using Microsoft Azure.

Finally, we are allocating significant development cycles to paying off our debt, including hiring new developers experienced in the latest technologies. In the long term this will accelerate development.

IT changes on the horizon

Several changes are coming that will affect us—and the ITSM community:

  • Cloud computing is going mainstream. In response, IT service managers will be taking on a role of governance, as opposed to direct management of the infrastructure. They will need to make sure that their cloud providers are living up to their commitments.
  • Security and privacy will play an increasingly larger role as we move to the cloud. May 2018 will bring the European Union's General Data Protection Regulation (GDPR) into effect. Are we ready? Or are we treating security and compliance as more of an afterthought?
  • DevOps is blurring the traditional lines between application development and infrastructure. As a result, infrastructure and operations are moving closer to app dev teams for increased agility.
  • Digital transformation is the new imperative, with an increasing number of organizations providing an enhanced online experience for their customers. Forrester calls this a "customer-obsessed operating model." LinkedIn lists 3,600 senior managers with "digital transformation" in their titles.

As you begin to cope with these changes, don't let technical debt, legacy applications, or the attrition of your senior IT staff hold you back. You can't move forward if you are spending all your time bailing water to keep the ship afloat.

We are in a time of rapid change, and it's only accelerating. But if you get your principles in place for managing the changes your business needs to make and keep your team well informed as you embark on the steps you agree to undertake, your move to DevOps and related technical and business processes will feel like a natural transition for your organization.



Keep learning

Read more articles about: Enterprise ITIT Ops