- 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.