{"id":28473,"date":"2018-10-15T11:33:44","date_gmt":"2018-10-15T09:33:44","guid":{"rendered":"http:\/\/arcadsoftware.com\/?p=28473"},"modified":"2026-03-13T12:15:40","modified_gmt":"2026-03-13T10:15:40","slug":"the-evolution-of-devops","status":"publish","type":"post","link":"https:\/\/www.arcadsoftware.com\/arcad\/news-events\/blog\/the-evolution-of-devops\/","title":{"rendered":"The evolution of DevOps"},"content":{"rendered":"

By Marc Dallas <\/h3>\n<\/div><\/div><\/div>

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

DevOps, above all a management of change<\/h2>\n

Organizations that have embraced DevOps either to the full or even partially can already testify that this approach carries a significant ROI.
\nMany others have explored and come close to DevOps but have not yet taken the final step.
\nThe 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<\/strong>.
\nIndeed, 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<\/strong> and support in the management of change and should add value<\/strong> 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.<\/p>\n

The emergence of DevSecOps and BizOps<\/h2>\n

The emergence of these new terms is directly related to the “complicated” relationship between Development and Operations.
\nOver a decade ago, development teams had already adopted mainstream agile<\/strong> methods and were releasing smaller software increments faster and more frequently, while operations \u2013 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.<\/p>\n

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.
\nThe 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.<\/p>\n

DevSecOps<\/strong>, for example, aims to enhance security by integrating it early in the application development process. We could add other departments into the chain.
\nAbove 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.<\/p>\n

BizOps<\/strong> is a more generic term. It describes an extended chain between business and operations. There is a contraction that we could finally call “BizDevSecOps”.
\nBizOps involves strategic and operational management. Indeed we should extend the term further than Ops today, as far as users (BizUsers).
\nWe 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<\/strong> them in a continuous delivery environment.
\nThis is the idea behind Release Coordination<\/strong>, right the way from the business strategy to the provision of new releases to the end-user.<\/p>\n<\/div><\/div><\/div>

DevOps adoption is growing faster than ever. Check out our infographic to discover the latest DevOps predictions, and how this agile corporate culture improves efficiency in all lines of business!<\/strong><\/p>\n<\/div>

Discover the Infographic<\/span><\/i><\/a><\/div><\/div><\/div><\/div><\/div>

The challenges of Enterprise DevOps<\/h2>\n

The concept of Enterprise DevOps<\/strong> elevates DevOps into a business strategy<\/strong>, a process that adds value to the organization, not just IT.
\nThe 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.
\nAnd this is the challenge of Enterprise DevOps: that the entire company becomes aware of the added value<\/strong> brought by this change of collaboration between services.
\nAll 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).<\/p>\n

The question of DevOps for Database<\/h2>\n

Although it is not new, the consideration of data in DevOps is gaining momentum.
\nIn 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.
\nParameter 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.<\/p>\n

Generally, as the data volume remains low, typically very basic processes are used for the transfer of parameter data to production.
\nThese elementary processes therefore do not usually cater for the rollback<\/strong> of data, or the identification of the version number of the installed system \u2013 capabilities that are considered low priority as the volume of data is relatively small.
\nYet the critical<\/strong> nature of parameter data makes these processes in reality very important.
\nBy 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.
\nIt 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.
\nParameter or configuration\/settings data must follow the same quality chain as the applications themselves, as is the promise of “DevOps for Database<\/strong>“.<\/p>\n

Conclusion<\/h3>\n