Modern information technology solutions require modern processes. It’s a simple idea with a complex execution.
The new standards of agile software development, cloud-based infrastructure, and continuous delivery can be challenging when antiquated hurdles in process and communication remain in place. DevOps practices were created to answer these challenges.
By combining development and operations concerns into one focus, high-quality solutions can be delivered rapidly. Removing access barriers, sharing responsibility, adopting collaboration tools to improve communications, and uniting once-adversarial concerns into cohesive teams have all fostered the rapid adoption of DevOps.
A recent Dzone survey of tech professionals shows that nearly half of the Information Technology sector has adopted DevOps practices.
What happens when the practice is not addressing a specific area of concern?
Geocent is working with many customers that require a “DevSecOps” practice to address specific security concerns. Curiously, security is highlighted; however, as some of the driving quality principles behind effective development and operations should be not only security but also maintainability, reliability, accessibility, flexibility, and correctness.
Some customers need that level of emphasis in other places. These efforts have led to a new, more flexible way to look at the practice: DevXOps.
The “X” highlights a desired specific focus area within a given effort. But where does the trend stop? When should an organization look to ensure quality practices within Dev and Ops are being met instead of diverting resources to a focus area that may be deficient?
Some examples:
-
DevTestOps — We see this occur when correctness and configuration of delivered functionality is the highest priority.
-
DevConfigOps — This happens when maintainability and reliability are of the utmost importance.
-
DevCostOps — Similarly, when the cost is the greatest concern.
The list goes on and on. DevAutoOps, DevDataOps. This argument of inserting an “X” focus between Dev and Ops could be used indefinitely and thus possibly made redundant and, in worst-case scenarios, become irrelevant.
Too much focus on X? Where to draw the line:
But a better practice may be this: We need to ask ourselves the tough questions of why these concerns are not addressed within the current DevOps constructs.
When a specific focus is determined to be needed, a better solution may be a DevOps process augmentation to ensure a given focus is addressed. If a particular “X” factor is required, a small and dedicated team should be defined to address this concern and roll out their solution to the larger DevOps organization.
If you take this approach, a more robust DevOps practice would then be in place for use in the future. DevOps must follow a culture of continuous improvement to be successful. If DevXOps is to be adopted by an organization, the “X” should be leveraged in this spirit.
These are our thoughts, but we want to hear from you. Do you agree or disagree? Do you think the X is important to highlight or should it be instinctively built-in to a DevOps processes?
