The evolution of DevOps

By Marc Dallas 

DevOps practices have evolved in recent years in many organizations seeking to respond more effectively to their business challenges.
While DevOps previously focused primarily on IT services, it now extends across the entire enterprise, impacting processes and data flows and driving deep organizational changes.

DevOps, above all a management of change

Organizations that have embraced DevOps either to the full or even partially can already testify that this approach carries a significant ROI.
Many others have explored and come close to DevOps but have not yet taken the final step.
The main reason for latency is that a DevOps transition goes beyond the adoption of new tooling and into people and process, and most importantly it requires a careful management of change.
Indeed, DevOps is not just about choosing the right automation solution. It requires an accompanied transition, wherein lies the role and responsibility of the solution vendor. In a DevOps project, levels of maturity and understanding differ between organizations. A DevOps solution provider therefore has a duty to advise and support in the management of change and should add value to the project beyond a simple automation. Company specifics must be taken into account, and in particular, the scope and diversity of development cultures and technology platforms contained in the application portfolio. Without this, a DevOps project has no chance of success.

The emergence of DevSecOps and BizOps

The emergence of these new terms is directly related to the “complicated” relationship between Development and Operations.
Over a decade ago, development teams had already adopted mainstream agile methods and were releasing smaller software increments faster and more frequently, while operations – upholding their corporate constraints around application availability and compliance – became an apparent bottleneck in the process. To keep software development cycles fluid and deliver updates to the end-user at the speed of the business, operations had to follow this same agile trend.

The DevOps movement held the key. By enhancing communication, in such a way as to recognize and respect the constraints of each different department, we have transitioned into a dialogue, exchange and a set of processes that meet the needs of each profession and integrate their respective constraints in order to collaborative effectively. This is the essence of what is meant by DevOps.
The appearance of these new and related terms DevSecOps and BizOps is simply evidence of the extension of this level of communication to all departments in a company, a progression in business change.

DevSecOps, for example, aims to enhance security by integrating it early in the application development process. We could add other departments into the chain.
Above all, this means that today companies are realizing that there is a need to have a wider software supply chain which, at each link in the chain, integrates the same principles exemplified by DevOps.

BizOps is a more generic term. It describes an extended chain between business and operations. There is a contraction that we could finally call “BizDevSecOps”.
BizOps involves strategic and operational management. Indeed we should extend the term further than Ops today, as far as users (BizUsers).
We are reminded of terms like as BtoB or BtoC, except for the fact that with DevSecOps and BizOps we embark on a change in internal organization, necessary for the company to thrive. We retain a level of granularity in tasks to allow focus on solving problems in a particular area. It’s about defining and executing all the required actions and automating them in a continuous delivery environment.
This is the idea behind Release Coordination, right the way from the business strategy to the provision of new releases to the end-user.

The challenges of Enterprise DevOps

The concept of Enterprise DevOps elevates DevOps into a business strategy, a process that adds value to the organization, not just IT.
The issues in terms of identification, validation of releases between different services, causes of bottlenecks, decision times, implementation or delivery durations, if they are examined at a DevOps scale, can be an area for experimentation. We will then be able to extend this inter-department cooperation across to the entire company, which will allow de facto to increase the overall Return on Investment.
And this is the challenge of Enterprise DevOps: that the entire company becomes aware of the added value brought by this change of collaboration between services.
All this microscopically managed work between Dev and Ops will then be implemented on a macroscopic scale across the entire enterprise chain (from the strategic decision to the end user).

The question of DevOps for Database

Although it is not new, the consideration of data in DevOps is gaining momentum.
In order to save time and reduce development effort, the concept of parameterizing data (whatever the data type, structure and the underlying data management technology) was introduced in order to modify program behaviour depending on specific data entered.
Parameter data therefore has an impact on the behavior of program execution. As such, these data actually belong to the field of development and operation of the application.

Generally, as the data volume remains low, typically very basic processes are used for the transfer of parameter data to production.
These elementary processes therefore do not usually cater for the rollback of data, or the identification of the version number of the installed system – capabilities that are considered low priority as the volume of data is relatively small.
Yet the critical nature of parameter data makes these processes in reality very important.
By underestimating their importance, we introduce a weak link in the quality chain, and run the risk of an incident in production that can cause huge financial losses, but also a loss of confidence in the deployment process.
It is therefore vital to not focus solely on the frequency and scale of deployment, but also on the criticality of the data that is being deployed.
Parameter or configuration/settings data must follow the same quality chain as the applications themselves, as is the promise of “DevOps for Database“.

Conclusion

• DevOps is not just about process automation, it involves a true management of change
• The terms DevSecOps and BizOps reveal that companies now contend the need to have an enterprise-wide software supply chain
• The added value of inter-department collaboration is realized across the wider enterprise
• Often critical data must follow the same quality chain as the applications

Marc Dallas

R&D Director

Software Engineering degree from the Integral International Institute, Marc started his career in 1994 as Analyst Programmer at Nestle Cereal Partners, and was appointed Product Manager at ADSM Software, prior to joining ARCAD Software in 1997.