BizDevOps beschreibt eine Organisationsform, in der die Personen, die eine Anwendung schreiben, betreiben, die fachlichen Anforderungen erstellen und das zugehörige Geschäftsmodell weiterentwickeln, in einem agilen Team zusammengefasst sind. Dabei hat das Team die Gesamtverantwortung für alle Bereiche, und es gibt innerhalb des Teams keine strikte Zuweisung der Verantwortlichkeiten.
Warum BizDevOps?
Eine Organisation in Richtung BizDevOps zu entwickeln, erscheint wie eine ziemlich radikale Änderung für die meisten Enterprise-Unternehmen. Warum macht es trotzdem Sinn?
Die klassische Trennung von Entwicklung und Betrieb
Die klassische Trennung von Entwicklung und Betrieb funktioniert durch starke Einschränkungen in der Technologie-, Produkt- und Frameworkwahl. Häufig wird genau ein bestimmter Application Server, eine Datenbank und ein unternehmenseigenes Framework zur Verwendung vorgegeben. Ziel ist es, Betrieb und Entwicklung durch Einschränkung zu vereinfachen.
Trend: Digitalisierung und Technologiediversifizierung
Tatsache ist, dass die Menge der zur Verfügung stehenden Technologien, Produkte und Frameworks in den letzten Jahren stark gestiegen ist, und dass dieser Trend der Diversifizierung anhalten wird. Tatsache ist auch, dass dieser Trend nicht ohne Grund da ist – mit der Digitalisierung gibt es eine Menge neuer Anforderungen, die bedient werden müssen, Vertriebskanäle, Kundenkommunikation, Kundentracking etc.
Wie wird mit diesem Trend aktuell in klassisch aufgestellten Unternehmen umgegangen?
DevOps ist definitiv noch nicht in den Unternehmen angekommen, der Trend der Digitalisierung aber schon. Die Folge ist, dass starke Einschränkungen aufgeweicht und neue Technologien eingeführt werden. Der Betrieb wird so stärker belastet. Außerdem sind häufig sogenannte Architekturteams dafür verantwortlich, die Verwendung der Technologie unternehmensweit zu vereinheitlichen – sei es in einem selbstgeschriebenen Framework oder durch andere Mittel. Dieses Team wird dadurch auch immer stärker belastet, da es immer mehr Fäden in der Hand halten muss. Insgesamt ist häufig zu beobachten, dass das Konfliktpotenzial mit Betrieb zunimmt, und dass die Qualität der zentralisierten Framework-Artefakte abnimmt.
Strategie der Einschränkung – Vermeidung von Innovation
Bleibt man bei der Strategie der Einschränkung und der Trennung von Entwicklung und Betrieb, so wird man immer nur eine sehr kleine Menge von Technologien und Produkten unterstützen können – es ist ja klar – ein zentraler Betrieb muss sich fokussieren. Innovation über die Technologie ist so unmöglich – statt die passende Technologie zur Lösung eines Problems zu verwenden, wird immer die gleiche, vorgegebene verwendet. Ebenfalls nicht zu unterschätzen ist der Effekt der Einschränkungsstrategie auf die Mitarbeiter. Viele Enterprise-Unternehmen haben Probleme, gute IT-Mitarbeiter zu halten, und häufig liegt das an Motivation und Entwicklungsmöglichkeiten. Das wird in der Zukunft immer problematischer, weil jetzt schon klar absehbar ist, dass immer mehr Innovation aus der IT heraus stattfindet.
Wieso nicht einfach Betrieb aufstocken?
Wenn man also nicht alle Trends verschlafen will, werden neue Technologien kommen. Was passiert, wenn man den Entwicklungsabteilungen eine relative Freiheit in der Technologiewahl gibt und dafür die Betriebsabteilung aufstockt, also eine Trennung von Betrieb und Entwicklung beibehält? Konflikte sind vorprogrammiert. Wer entscheidet denn nun, welche Technologie erlaubt ist und welche nicht? Entwicklung? Und Betrieb muss alles schlucken, auch wenn der Betrieb der Technologie sehr schwierig ist? Hier sind viele Meetings, Diskussionsrunden, Eskalationen und Verzögerungen zu erwarten, Know-How muss ja auch aufgebaut werden etc. Außerdem wird vielleicht auch manche Entscheidung auf Entwicklungsseite leichtfertig getroffen – schließlich muss der schwierige Betrieb ja von anderen gemacht werden.
You build it, you run it
Was passiert, wenn man DevOps-Teams hat, die gemeinschaftlich für den Projekterfolg verantwortlich sind? Die Risikoabschätzung liegt komplett im Team – die Einführung einer neuen Technologie wird nicht leichtfertig beschlossen, und jedem im Team ist klar, dass das Team die Aufgabe hat, die komplette Anwendung zum Fliegen zu bringen – inklusive Betrieb der neuen Technologie.
Voraussetzungen für DevOps
Infrastruktur – Self-Service muss auf Knopfdruck funktionieren – ob nun Docker oder virtuelle Maschinen. Versionskontrolle, Build, Deployment, Monitoring, Logging müssen standardisiert, automatisiert und komfortabel nutzbar sein. Dafür sollte ein eigenes Team zuständig sein, das im Bereich Betrieb / Architektur angesiedelt ist.
Es sollten nie mehrere DevOps – Teams zusammen für eine Anwendung verantwortlich sein – ein unternehmensweiter Monolith schließt sich also aus. Wenn zwei Teams an einer Anwendung arbeiten, kann eine Technologieentscheidung nicht eigenständig getroffen und verantwortet werden. Hier schließt sich der Kreis zu Self-Contained Systems bzw. Microservices.
Und warum nun auch noch Biz?
Was macht es jetzt für einen Sinn, die Fachabteilung noch in das DevOps-Team zu integrieren?
Die klassische Trennung der Fachabteilung von der IT
Die klassische Trennung der Fachabteilung von der IT geht davon aus, dass die Fachabteilung ihr Geschäft kennt, neue Geschäftsfelder kreativ erschließt und Business Value schafft, während die IT das unterstützende Organ ist, das die für die Geschäftsprozesse benötigten Systeme erstellt.
Innovation durch IT
In den letzten Jahren hat sich aber gezeigt, dass die IT immer mehr zum Innovationstreiber wird. Geschäftsprozesse basieren immer mehr zu 100% auf IT, und der technologische Fortschritt ermöglicht immer neue Geschäftsmodelle. In einem BizDevOps – Team besteht nun die Möglichkeit, die Innovationskraft der IT in die Fachabteilung zurückzuspielen und so gemeinsam die optimalsten Lösungen zu schaffen.
Flexibilität im Team
Ein Team, das gemeinsam Verantwortung für eine bestimmte Fachlichkeit trägt, erliegt weniger der Gefahr der gegenseitigen Schuldzuweisung, wie das bei einer Trennung von Betrieb, Entwicklung und Fachabteilung häufig passiert. Außerdem kann auch im Team flexibel reagiert werden – Entwickler machen Betrieb, die Fachabteilung übernimmt IT-Aufgaben, Entwickler können auch Fachabteilungsaufgaben übernehmen. Je nach Engpass. Dabei ist eine gewisse Fluktuation im Team gut, um frische Ideen aufnehmen zu können, eine gewisse Stabilität ist aber auch ungemein wichtig, damit Know-How nicht verloren geht.
No projects!
Softwareentwicklung findet fast immer in Projekten statt. Ein Projekt suggeriert, dass es ein Ende gibt, das ist jedoch nicht der Fall. Es gibt Bugfixes, Betrieb und Weiterentwicklung, und wenn irgendwann tatsächlich die Anwendung entfernt wird, so gibt es in fast allen Fällen eine neue Anwendung oder Software, die die Fachlichkeit übernimmt. Ein BizDevOps-Team ist für eine bestimmte Fachlichkeit verantwortlich, und das auf Dauer, auch wenn Anwendungen kommen und gehen.
Fazit
Es sollte jetzt klar sein, was mit BizDevOps gemeint ist – und wo die Vorteile liegen. Es gibt Enterprise-Unternehmen, die bereits auf dem Weg sind, siehe da zum Beispiel die ING aus den Niederlanden (http://gotocon.com/dl/goto-london-2015/slides/HenkKolk_INGsJourneyToAgile.pdf ).
Und für den, der sagt, dass das mit den Leuten im eigenen Unternehmen nicht möglich ist, habe ich das folgende Zitat aus einer Netflix-Präsentation:
"We hired them from you and got out of their way" @adrianco on engineers @ Netflix https://t.co/Hu8ZaSNErp #DOES15 pic.twitter.com/wOpNhvUE3n
— Matthew Skelton (@matthewpskelton) 22. Oktober 2015
War dieser Beitrag hilfreich?
Weitere Beiträge
von Tobias Flohre
16.2.2022 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Tobias Flohre
Senior Software Developer
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.