Wikipedia has a nice definition for it: It is “a practice that emphasizes the collaboration and communication of both software developers and other IT professionals while automating the process of software delivery and infrastructure changes. It aims at establishing a culture and environment where building, testing, and releasing software, can happen rapidly, frequently, and more reliably.” You need insights into applications, interfaces and technologies to foster a culture of collaboration between developers and operations people who have been increasingly separated in the past couple of years.
Former separation slows down the business success of today – the demand-supply-splitIt started 10 years ago with the demand-supply-split, where the role of the buyer and the supplier were established internally in two organizations. Sometimes with a contract obligation, sometimes more market oriented. This separation was accompanied by a strict reduction of usable technologies, products and frameworks to ease the communication. Even if both parties shared a common goal to support the company, the success focuses were different. The one (Dev) payed attention to writing the best code, the other (Ops) looked after performance and availability of certain servers.
You need to react in seconds to every influence – the birth of DevOpsThese days a closer cooperation of development and operations is necessary due to requirements for solutions that need to be developed within a very short time-to-market, evolving in an iterative approach with frequent releases. In the extreme the deployment of an eCommerce Website could happen every minute or hour and every day. To react to user behavior is crucial so as to not lose customers and money. This is where DevOps comes into the play – a very tight relationship of these two practices. A steady insight about availability and performance of the source code and the used hardware and software products is now necessary. Decisions about new technologies or frameworks are now taken by the team, taking risks and benefits into consideration. This flexibility and freedom can lead to innovative solutions. The DevOps team is responsible for making things happen and ensuring a successful deployment and operations.
Balancing performance improvement, bug reduction or a new requirement – the role of BizDevOpsHowever, this concept neglects that there is a profound business interest that drives for best business support and best processes to increase or secure revenue. In the past the Business was reduced to create functional and non-functional requirements, which are translated into source code by Development and operated on a standardized environment by operations. A throw over the fence culture with a lot of ping pong processes of who is right and who is wrong. But in the above defined environment where you have to react in seconds, minutes or days, streamlined processes and defined communication and approval cascades create too much overhead and detract the people from focusing on what really needs to be done.
The consequence is that Business should be tightly integrated into the DevOps team. Do we need this new feature or shall we move the button from left to right, do we need to change the way a user is searching? Can we provide a certain feature ad-hoc to win a new customer? How does the downtime of an application or server affect the company bottom-line? Why does the conversion rate go down?
Many of these requirements derive from of business analytics of user behavior with an application. Be it a Web Application or an out-of-the-shelf solution. So Business must be closely involved in these kind of real-time decision taking. BizDevOps describes this set-up.
Application Intelligence Platform as a central source
But you need to provide a common language for collaboration to really happen, an information base that serves the need of all three parties involved. With leanIX we provide such a platform that delivers structure and up-to-date information on discussions, plans and decisions.