DevOps, the X way?

Nov 19, 2014

Sogeti Labs

In 2009 and 2010 two movements were created, DevOps and the X life Cycle. While DevOps becomes more and more popular, X life cycle is still the matter of a small community. In my opinion, both will benefit from getting closer: DevOps with the theoretical base of X life cycle, and the latter from the enthusiasm about DevOps and existing tools.

The DevOps Promises

By focusing on communication, collaboration, and integration automation, DevOps aims to improve software release management by providing faster development and deployment cycles and improving quality and security of software applications inside their environments. Go faster and be ready to deal with changes.

DevOps tools

Configuration management and infrastructure automation are the main impactful set of tools that help DevOps integration automation. While configuration management allows version control and is the base for safe automated code deployments, infrastructure automation supports tests, simulations, prototyping, and continuous integration by allowing on-demand provisioning of infrastructure at reasonable costs.

Indeed, on the Dev side, most ALM (Application Lifecycle Management) models and tools place the configuration management process at the center, as a pivot process between the other processes of ALM such as Requirements, Design, Development, Tests, and Deployment. On the Ops side, increase the automation of code or package deployment and of API management; increase the automation of log management, and more generally, of monitoring and performance management; increase the automation of infrastructure provisioning, making the infrastructure more and more programmable and sustain its dynamic from a lifecycle point of view.

What is the life cycle that fits better? To answer this question, we should notice that DevOps “suffers” from a lack of conceptualization and formalism.

The X life cycle

• X Overview

“The X development method is a newly developed one, which provides a different perspective on the construction of technical systems. It relies on two founding ideas: a ubiquitous environment and a simulation of the behavior induced by the definition of the system itself. The main advantages targeted are a shortened development time, a better integration into the environment, a consideration of the whole lifecycle from the design until the end-of-life recovery, and a detection of design problems earlier.” M. Tahan, A. Touil, J. Vareille, P. Le Parc (LISYC – Complex Systems Computing Laboratory – Brest University)

X was thought of by a team working on design theory and industrial domain problems. It can be, I think, easily adapted for the IT domain, with some adjustments to deliver software products and services, from negotiation to deployment. Actually, in IT the main uncertainties are around people (as agents of the IT systems) and the complexity of links between components inside and outside the IT system (numerous and with unpredictable behaviors). The X life cycle can also be seen as one of the results of the tidal wave caused by an increased awareness about the concept of environment, brought on by the holistic approach of systemic thinking.

• X and Agility

Iteration on X to build your technical system incrementally

The X life cycle can be browsed by following an agile approach. In the figure below, I suggest the Scrum one as an example. One of the fundamental principles to apply agility on a life cycle is to retrieve, for each iteration, the topology of this life cycle. In the figure below, if you stick together the red parts of Sprint #1 or the ones from Sprint #N-e, you will still have an X.

Disruptive’X

What is disruptive with the adoption of X life cycle is the ubiquity of the environment and a “declared status of undefined things.” According to the figure below, the space of X can be viewed as a quadrant. The upper left one is the set of {Immaterial; Undefined} things1, the bottom-left one is the set of {Material; Undefined} things, the upper-right one is {Immaterial; Defined} things, and the last one the set of {Material; Defined} things. Note that the technical system you are building is progressively integrated into the environment and becomes a part of it (exclamation mark below);at the next iteration you will have to deal with it.

Before the “Defined” point at the center of the X, things have a degree of uncertainty (left side). This is always the case, whatever the life cycle, the approach, or the domain of the project, but there is a kind of taboo to explicitly talk about that, especially in the negotiation phases of a project. Of course it is taken into account as a risk, and measured with risk analysis, but not as a structural concept by itself, that affects the way we should work to make software products, for example. As a matter of fact, this concept of undefined things has a direct impact on the agile contract. Indeed, when I start my project (extreme left side) with an agile approach, I have to decide on a constant rhythm of progression, for example, the number of sprints and their duration with the Scrum approach. What happens then if, during integration, I have a problem that questions the sprint’s work breakdown system I sold? Should I consider, according to the agile approach, transferr               ing the increased workload to the following sprint or to make a specific sprint to deal with this problem? There is not a clear answer,but the main principle of X, which is to take into account from the beginning the impacts from and toward the environment, diminishes the risk of such a situation.

DevOps, The X Way!

A team’s interoperability by the DevOps approach becomes truly meaningful when it operates on a X life cycle. As shown in the figure below, each structured story of a sprint (in a Scrum approach) composed of the sequence of the sets {R_i, S_i}; {D_i, G_i}; {Def_i}; {I_i,B_i}; {Sof_i, Sys_i} of activities is operated by a team composed of both development and operations competencies.

Requirements (R_i) takes benefits from what really exists or not (Selection (S_i)). Design (D_i) is based on the measured capacity of the gathered components (G_i) from the existing systems and their environment. When things are defined (Def_i) the Agile contract should be able to be renegotiated to build (B_i) and integrate (I_i) at regular rhythm in a known and mastered environment. Then, the super-system (Infrastructure (Sys_i) and Software (Sof_i)) created can be operated with two “more independent” teams, until the next sprint.

In a conceptualization perspective, Def_i can be seen as focal points, as the convergence of team organization, tasks and activities, new artifacts and existing components in their dynamic. These points are central, between the vision of your project and its realization in time, between your representations and their implementations inside your environment. This is the best place to make decisions.

Conclusion

X life cycle can be seen as a conceptualization or formalization of the popular DevOps movement. They were born independently at the same time, which might be seen as a real need to take into account the environmental effect. DevOps is the result of the pragmatism of some, while X is the result of the systemic approach of others.

Many tools exist and can be easily adapted to the right side of the X. For the left side, it’s an open gate for innovation.

1 A thing here is any concept: contract, method, technic, tool, asset or agent, etc. that participate to the elaboration and construction of the super-system.

About the author

Sogeti Labs

SogetiLabs gathers distinguished technology leaders from around the Sogeti world. It is an initiative explaining not how IT works, but what IT means for business.

Comments