Case Study: DevOps in der Praxis

Wie es einem Versicherungsanbieter gelang, seine Release-Kosten mit DevOps um 97 Prozent zu senken
0 Bewertungen
1
5
0
 
 
 
Bewerten
 
 
 
 
 
 
0 Kommentare  
120 Downloads  
DevOps soll Entwickler und Admins näher zusammenbringen. Aber funktioniert das auch in der Realität? Antworten auf diese Frage finden Sie in der vorliegenden Case Study, die die Einführung von DevOps bei einem großen Versicherungsanbieter beschreibt.

Inhalt:

DevOps hat zum Ziel, die Entwicklung von Software massiv zu beschleunigen und dabei auch noch die Qualität der ausgelieferten Anwendungen zu verbessern.

  • Aber funktioniert das in der Praxis wirklich?
  • Treten denn keine Probleme bei der Umstellung auf?
  • Wenn ja, welche?
  • Und lässt sich der Deployment-Zyklus mit DevOps tatsächlich in dem beworbenen erheblichen Umfang beschleunigen?

Welche Erfahrungen der international tätige Versicherer Hiscox mit der Einführung von DevOps in seinem Unternehmen gemacht hat, erfahren Sie in der vorliegenden Case Study.

Die präsentierten Ergebnisse sind beeindruckend. So ist es Hiscox gelungen, nicht mehr nur alle zehn Wochen ein neues Release einer wichtigen unternehmenskritischen Anwendung zu veröffentlichen. Sondern es sind jetzt 50 Releases pro Woche. Dadurch konnte das Unternehmen nicht nur die Time per Release um 89 Prozent senken, sondern auch die Zahl der benötigten Mitarbeiter um 75 Prozent.

Lesen Sie hier außerdem, wie es Hiscox durch die Einführung von DevOps gelang, die Release-Kosten pro Deployment um satte 97 Prozent zu reduzieren.

Originalauszug aus dem Dokument:

DevOps is about aligning goals, but IT at Hiscox wasn’t set up to achieve that. For example, we had development teams that threw code over the wall to the release team that deployed it, and then a separate team supported the code once it went to production. In scenarios like this, there is very little empathy between all those different teams. It’s a bit like a relay race and passing the baton — “I’ve done my job, now it’s your problem.” We are now moving to product-centric teams that have cradle-to-grave capabilities — development, support, the business, etc. This is really new and really exciting.

I talked a lot about cultural change in the beginning of our DevOps journey, talking to our teams and to executives about the challenges of micromanagement, lack of empathy and how to restructure our teams and the technologies that will help pull all this together.

While DevOps is commonly associated with increasing the pace of change, the principles and practices can also be applied when you’re trying to increase quality or revenue, or when you want to make sure you’re taking care of customers using a sunset product (one slated for end of life in three to four years).

Once the IT executives were on board, we started with a project called “Maximize IT.” We moved people into roles that were more aligned with the business unit — “product focused” is probably the right term, as I mentioned earlier.

Kommentar verfassen

LOGIN für heise Business Services

Sie haben noch keinen Account?
Hier registrieren und informieren.