Trailblazers provide greater development agility
Recent CIO Magazine research commissioned by Atos uncovers four characteristics or best practices shared by IT organizations that fall into a trailblazers category. This blog series goes into each of the four traits of trailblazers described in the findings:
- They embrace the cloud and are cloud secure
- They use service management best practices
- They automate IT services
- They provide greater development agility
Everything points to DevOps
The first three characteristics of IT trailblazers — secure hybrid cloud, service management and automation — lead directly to the need for the fourth characteristic: agile development or DevOps. IT leaders are nearly 6 times more likely to have DevOps residing in business units with supportive management and governance.
The problem with some of the non-trailblazers’ development models and frameworks? They’re based on monolithic approaches to how we build, deploy and manage applications, infrastructure and other supporting components.
Manual, people-intensive models
In some instances, in order to deploy a piece of code, the entire development lifecycle from develop to release is still very manual and people-intensive. There are many checkpoints, many approvers and lots of change control boards to get through. The technology frameworks that support these development models have also been based on this very manual process.
Up until about 5 years ago there wasn’t a significant, verging on maniacal, focus on service management or keeping CMDBs up to date. Related to the CMDB, there wasn’t even a drive to have an all-encompassing CMDB to keep track of all the applications, infrastructure and security. It was more for inventory than a true view of what the enterprise and its supporting services really looked like.
The legacy frameworks and processes lacked key information for decision making. So, the developers had to figure out, by tribal knowledge, what applications were connected to what. And if this change is made, what would it impact? That’s why they needed the checkpoints and approvers. A lot of times, it came down to these giant change activity boards (CABs) getting on a call Friday afternoon to review every change coming into production to see its impact.
That’s still a problem with some of the current dev models and frameworks, but a lot of organizations have begun to make huge strides forward in this area.
Getting to DevOps
One perspective says the appropriate development model is one that can evolve to leverage a microservices architecture based on individual discrete components. Development moves through the process using a preapproved set of changes/workflows that are typically acceptable. Technology automates the process with policy engines that look at the risk of the change based on the known state of the environment and the CMDB information.
So now, developers can go and register a change they’d like to make. There are policies and rules in place for how they’re going to make that change. And an engine can look at the CMDB and validate that the proposed change:
- Doesn’t put production at risk
- Is aligned with standard policies on how changes are made
- Presents no issues with other applications that are dependent on those services going forward
If you automate that model, it’ll facilitate your deployments and deliver on the vision of a DevOps-centric world: better quality of code, fewer issues, fewer production outages and quicker time to value.