The term DevOps originated in Belgium around the end of the last decade, as a result of the so-called DevOps days. These days were meant to bring together IT experts from both development and management operations. A DevOps team was initially defined as a multidisciplinary team that is fully responsible for the management and CD of a service. Think of Amazon and Google as companies that use these kinds of teams; they release dozens of changes every day.

This way of working is not yet standardized in big organizations—ITIL and PRINCE2 still reign, and the Information Technology (IT) department is desperately trying to deliver services with value. The way in which these services are provided is difficult to maintain in the current situation where IT is still often seen as a cost item. This is caused by the following:

• The way of organizing organizations as a collection of independent silo's
• A focus on creating process excess (too many rules set in stone)
• Not defining clear Key Performance Indicators (KPIs) for measuring performance.

The technologies in these silos are not compatible, whereas for a successful business-IT alignment, one coherent chain is needed.

In addition, we are now seeing that customers are increasingly asking for the fast delivery of a new functionality. This includes the quick resolution of incidents, short lines of communication, and excellent quality requirements in their IT organization. Using the old ways of organizing IT in an organization, processes, working methods, attitude, behavior, and the required performance and results are not being sufficiently realized. A famous quote attributed to Albert Einstein, that "the definition of insanity is doing the same thing over and over again and expecting a different result", seems to increasingly apply to IT. It is time, therefore, to fundamentally reconsider the setup of its organizations.

The following diagram illustrates the DevOps process: