What is DevOps?
The relationship between the users of a system and the operations people are normally confrontational – anyway, never friendly. The user however, sees the developer earlier in the life cycle, not when systems fail. This makes for a slightly better relationship. And in any requirements study with the users, while the development side is generally involved, the operations side is generally not. This makes for the developers designing systems without the required thought being given to operational complexities. And, the relationship between them is also fairly confrontational. The confrontational relationship between the developers and the operations people arises mainly from conflicting interests (“change for new features” of the development people vs. “don’t change for stability” of the operations people).
Traditional Methodologies
Some of the incremental development methodologies like Agile brought the users and developers even closer. A similar thing did not happen with the operations people. Service management practices like ITIL allowed for the reduction of the conflict to certain extent but not fully. However, the relationship between the developer and the operations people still remained confrontational.
Incremental Development Methodologies (like Agile) and service management practices like ITIL
The aim of incremental develop-and-deploy methodologies like DevOps is to bring in the operations people also into the collaborative group and make sure that operations inputs are built into the design right at the beginning. The availability of techniques like virtualisation and infrastructure like the cloud and new configuration management tools help in this collaboration and integration.
DevOps Methodologies
These incremental, collaborative methodologies are highly beneficial for large organisations which need to push out lots of code each day (like retail organisations). The DevOps approach spans the full delivery life-cycle and allows for higher release frequencies. These releases have had design inputs from the user, the developer and the operations person. This means reaching the user with features faster; better control on new releases and so lower failure rates and faster recovery in case of failures; and much faster bug fixes. This promises better returns to the organisation in terms of speed of delivery, quality of delivery and cost of delivery.
The DevOps Architecture
We have attempted to create an Enterprise Architecture that will capture the DevOps methodologies in a holistic manner. This architecture can form the basis to guide organisations through a well defined set of practices from business needs to system implementation. Such an architecture can help organisations, through its standardisation of processes, to reduce IT process complexities, reduce IT risks, create openness in IT and speed up IT decision making. In short, the value of IT is increased.
The PM Power DevOps architecture is loosely based on the TOGAF framework. This will allow the use of this architecture for development either with open source or proprietary standards. (We have mapped the TOGAF elements to the elements of our architecture)
PM Power DevOps Architecture
In later blog posts we will be elaborating on some of the elements of the architecture.
Trackbacks/Pingbacks