During my career, I have seen many new innovations in both the software and hardware industries. I remember being amazed when I first saw a printer lid open automatically when the paper ran out. I also remember wondering, what will they think of next? Just like DevOps, these trends have their followers and detractors; however, as a lifelong operations man, I have always been skeptical of new trends. I am willing to learn and to embrace, but I’m cautious because it is always operations duty to clean up the mess and appease rightly indignant users and customers. In most cases, it isn’t the trend that caused the problem, it’s the misuse and desire for change. In addition, each new trend has its own teething problems. After just looking online for some DevOps definitions, I quickly found five each one differing significantly from the other. Some mention ‘agile’ and some don’t. Some mention ‘lean’ and some don’t. Operations has always wanted to get into the development life cycle but development does not want operations getting in the way. Personally, I see a lot of good in DevOps but experience tells me to be cautious. My worry is that if you’re not careful, the good can become the bad. DevOps is about bringing services and apps to the business in a robust and timely manner while harnessing the development contribution. The issues, or pitfalls, I’m seeing include:
- Territorial battle lines
- Cutting corners
- Operations not geared towards DevOps
Territorial battle lines have existed since IT was called Data Processing, especially the thorny problem that often comes when you hand over a new service from development to live production. Modern IT is no place for gambling. When you bring words such as ‘lean’ and ‘agile’ into the IT lexicon, you also bring a set of expectations that encourage cutting corners, resulting in loose services and applications. DevOps should be expected to reduce critical testing and documentation. I find the documentation often comes with many applications to be totally useless, resulting in wasting large amounts of time. It also leaves me wondering: if I’m having trouble installing an application, how does the average untrained user get on? Good documentation enhances IT’s reputation. This is an easy corner to cut, but the ramifications can be significant. So, quite simply, do not use DevOps to cut corners.
Another potential pitfall is that operations is often not geared towards a DevOps approach and needs significant restructuring to succeed. This can be best achieved by redefining those critical IT action processes (e.g. problem, change, incident, configuration, release and service desk, event, release and request management) as these are some of the traditional key touch points for development and operations. Doing this will help operations become more geared towards DevOps. If the contact points between operations and development are abrasive, DevOps will not work. One way to address this is to create set of questions that need to be answered for each operational process or function before a service or an application can progress through DevOps. Doing so will identify who is responsible for what, making the process much smoother.
In short, DevOps is here to stay so if you are adopting DevOps, make sure you don’t let territorial battle lines become an issue, and don’t use DevOps as an excuse to cut corners. Help to make sure operations is prepared and clearly define responsibilities and ownership for the operations and development teams.