Zusammenspiel von Agilität, DevOps, Microservices und Cloud - Capgemini
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
01/2020 Schwerpunkt: Moderne Vorgehensmodelle – Was kommt nach Scrum und Kanban?
Sonderdruck für
Zusammenspiel von Agilität,
DevOps, Microservices und Cloud
Maximale Agilität mit Softwareentwicklung 4.0
Es gibt kaum ein Unternehmen, das nicht auf agile Methoden setzt. Trotzdem können sich die wenigsten in puncto
„Time-To-Market“ mit Online-Händlern wie OTTO [OTTOblog], Zalando und Netflix [NetflixBlog] messen. Zalando
spricht sogar von „Radical Agility“ [Bis15]. Solch radikale Ausprägungen verdeutlichen, dass die übliche „Standard-
Agilität“ oft nicht mehr ausreichend ist. Es bedarf der Softwareentwicklung 4.0, die sich durch das Zusammenspiel
von Agilität, DevOps, Cloud und Microservices auszeichnet. Der Beitrag zeigt, warum nur das perfekte Zusammen
spiel dieser vier Disziplinen die Voraussetzung schafft, in puncto Zeit, Reaktionsfähigkeit und Flexibilität zu den
agilsten Unternehmen zu zählen.
Viele Unternehmen befinden sich aktuell Das Standardprojekt ist agil, wenn man dem Zeitdruck geschuldet und damit „aus
in einem Transformationsprozess zu mehr 6 bis 12 Monate benötigt, um eine Idee der Not geboren“. Hinzu kommen auch
Agilität. Die Gründe sind vielfältig, wie im Rahmen eines Softwareentwicklungs- hier je nach Bedarf simple Updates, um
die häufigsten Ziele laut dem 13. jährli- projekts in Produktion zu bringen. Vor- Fehler zu beheben.
chen, internationalen Bericht zum Status aussetzung hierfür sind mindestens 3 bis 4 Das Ausnahmeprojekt ist agilissimo. Dies
von Agilität [SoAR13] zeigen: Releases der IT-Systeme pro Jahr, wobei betrifft höchstens 5 Prozent der Projekte.
kleine Änderungen oder Fehlerbehebun- Man findet sie nur in wenigen Unterneh-
■ eine beschleunigte Softwareausliefe- gen nicht gezählt werden. Eine schnellere men, insbesondere im Online-Handel. Die-
rung (74 Prozent der Befragten), Umsetzung ist kaum möglich, da Ideen se Ausnahmeprojekte schaffen es, Ideen in
■ das schnelle Reagieren auf sich ändern- auch noch beschlossen und in das Back- 1 bis 2 Wochen komplett umzusetzen.
de Prioritäten (62 Prozent), log für das nächste Release aufgenommen Nicht jedes Projekt muss agilissimo wer-
■ eine höhere Produktivität, beziehungs- werden müssen. In den meisten IT-Pro- den, wie auch Diskussionen um bimodale
weise geringere Projektkosten (51 Pro- jekten – schätzungsweise etwa 80 Pro- IT [GartnerBimodal] zeigen. Im Online-
zent), zent – ist das für unternehmenskritische Handel ist agilissimo erfolgsentscheidend,
■ eine bessere Abstimmung zwischen Softwarelösungen heute noch Standard. während für die Umsetzung von neuen
Fachbereich und IT (50 Prozent), Dies gilt, obwohl nahezu alle angeben, Gesetzen im öffentlichen Bereich meist
■ eine verbesserte Softwarequalität (43 agile Methoden wie Scrum oder Kanban genügend Vorlaufzeit besteht. Trotzdem
Prozent). einzusetzen. kennt der Autor niemanden, der nicht
Das Leuchtturmprojekt ist agiler und dennoch agiler werden möchte. Daher
Mit dem Ziel der beschleunigten Soft- hat meist einen hohen Time-to-Market- lohnt eine Analyse anhand der folgenden
wareauslieferung ist der Wunsch verbun- Druck. Sie machen circa 15 Prozent aller Punkte, was notwendig ist, um den nächs-
den, in sehr kurzer Zeit neue Ideen umzu- Projekte aus. Dort schafft man 10 bis 12 ten Schritt hinzu agilissimo zu machen.
setzen und sich einen Wettbewerbsvorteil Releases der Software pro Jahr und eine
zu verschaffen. Solche Ideen betreffen das Idee kann bestenfalls in 2 bis 3 Monaten Softwareentwicklung 4.0
Kerngeschäft und sind zumeist in unter- umgesetzt werden. Schneller geht dies
nehmenskritischen Kernsystemen umzu- nicht, da der Backlog für ein gestartetes Das Erfolgsrezept von Projekten bei
setzen. Release in der Regel fix ist. Dauern die OTTO, Zalando und Netflix, die sich
einzelnen Releases deutlich länger als ei- agilissimo nennen dürfen, ist, dass sie alle
Reifegrade Agilität nen Monat, ist circa ein Release pro Mo- sehr konsequent auf vier Bausteine und
nat möglich, indem an 2 bis 3 parallel deren Integration (untereinander) setzen
Anhand der genannten Aspekte zeigt sich, gearbeitet wird. Dieses Vorgehen ist meist (siehe Abbildung 2):
dass es zweckmäßig ist, den Reifegrad
von Projekten anhand der Umsetzungszeit
geschäftskritischer Ideen zu bestimmen
(siehe Abbildung 1). Das erste im Produk-
tivbetrieb eingesetzte Release eines neu
entwickelten und komplexen IT-Systems
dauert auch heute noch zwischen sechs
und 15 Monaten. Danach können Re-
lease-Zyklen und damit die Umsetzungs-
zeit neuer Ideen deutlich kürzer ausfallen.
Anhand der Umsetzungszeit lassen sich
drei Reifegrade von Softwareentwick-
lungsprojekten klassifizieren – agil, agiler
und agilissimo: Abb. 1: Die agile Reifegrad-Pyramide
10
www.objektspektrum.de
hat, kann nicht Tage oder Monate auf
Entscheidungen warten. Deshalb müs-
sen alle am Projekt beteiligten Berei-
che, und zwar Fachbereich, Entwick-
lung, Test und Betrieb, im Projektteam
mit Entscheidungskompetenz vertreten
sein: Beispielsweise trifft der Product
Owner die fachlichen Entscheidungen,
die Entwickler entscheiden über die
technische Umsetzung, die Tester ver-
antworten die Qualitätssicherung und
ein Betriebsexperte trifft Betriebsent-
scheidungen. Diese enge Zusammen-
arbeit der beteiligten Bereiche als EIN
Team nennt man auch BizDevOps.
■ Produktorientierung: Empfehlenswert
ist, dass Unternehmen sich von ei-
ner Projektorganisation hin zu einer
Produktorientierung transformieren.
Abb. 2: Softwareentwicklung 4.0 = Agilität + DevOps + Microservices + Cloud Dabei steht das Produkt stets im Mit-
telpunkt und das Team bleibt von der
■ agile Vorgehensmethoden, Prozesse sondern perfekt ineinandergreifen müs- Idee bis zum Produktivbetrieb dafür
und Organisationen, sen. Agilissimo kann darüber hinaus nur verantwortlich. Das schließt nicht aus,
■ DevOps mit vollständiger Automati- werden, wer in allen vier Disziplinen den dass das Produktteam von Teams mit
sierung und Auflösung der Mauer zwi- höchsten Reifegrad in der Umsetzung der Querschnittsfunktionen, zum Beispiel
schen Entwicklung und Betrieb, „Best Practices“ hat, die im Folgenden für den 24/7-Support, unterstützt wird.
■ Microservices und weitere leichtge- beschrieben werden (siehe Abbildung 4). ■ Management 3.0: Um agilissimo zu
wichtige Architekturen, sein, bedarf es nach Ansicht des Autors
■ Einsatz von flexiblen Cloud-Infra- Agilität hat den Reifegrad moderner Führungsmethoden, wie sie
strukturen. oft unter dem Schlagwort Management
agilissimo
3.0 propagiert werden. Dazu zählt das
Die Kombination dieser vier Bausteine Konsequentes agiles Vorgehen bedeu- Vertrauen in die Mitarbeiter, von de-
führt zur vierten Entwicklungsstufe der tet mehr als die Einführung von Scrum nen jeder einen Teil der Verantwortung
Projektvorgehensmethoden (siehe Abbil- oder Kanban. Zumindest sollten folgende übernimmt. Ein einzelner Architekt be-
dung 3): die Softwareentwicklung 4.0. Sie Empfehlungen umgesetzt werden: stimmt und verantwortet damit nicht
ist nach dem klassischen Wasserfall (1.0), mehr alle technischen Entscheidun-
schwergewichtigen Modellen wie RUP ■ Agile Vorgehensmethoden: An erster gen, sondern tritt als Coach des Teams
oder V-Modell XT (2.0) sowie den agi- Stelle steht, dass man agile Vorgehens- auf und entwickelt eine gemeinsame
len Vorgehensmethoden wie Scrum und methoden wie Scrum, Kanban oder Vision. Ein „Product Owner“ über-
Kanban gemäß des agilen Manifests von SAFe (Scaled Agile Framework) ein- zeugt beispielsweise in seiner Rolle
2001 (3.0) seit circa 2015 – zumindest setzt. als Business-Architekt das Team von
nach Ansicht des Autors – die Antwort ■ EIN Team mit Entscheidungskompe- einer Produktversion. Der erfahrene
auf die Frage „Was kommt nach Scrum tenz: Notwendig sind außerdem Or- Entwickler überzeugt als technischer
und Kanban?“. ganisationsänderungen, die zu kurzen Architekt sein Team wiederum von der
Softwareentwicklung 4.0 bedeutet, dass Entscheidungswegen führen. Wer nur optimalen technischen Architektur für
alle vier Bausteine nicht isoliert sind, zwei Wochen für die Ideenumsetzung das Produkt.
Als Beispiel lässt sich hier ein dem Autor
bekanntes Großprojekt aus dem Automo-
bilsektor heranziehen. Das Team besteht
dort aus mehreren hundert Mitgliedern
und mehrere Fachbereiche sind beteiligt.
Die Umsetzungsgeschwindigkeit von
Ideen wurde auch dort hinterfragt. Eine
Analyse machte deutlich, wo wie viel
Zeit verloren geht. Überraschenderweise
wurde am meisten Zeit dafür benötigt,
die Entscheidung zu treffen, dass die Idee
überhaupt umgesetzt wird. Der Grund
war, dass viele Stakeholder und Entschei-
dungsgremien zustimmen mussten. So
mussten beispielsweise Budgets gewährt
und Ideen zuungunsten anderer Vorschlä-
Abb. 3: Die vier Entwicklungsstufen der IT-Projektvorgehensmodelle ge priorisiert werden, die dann nicht um-
11
01/2020 Schwerpunkt: Moderne Vorgehensmodelle – Was kommt nach Scrum und Kanban?
auf die Elastizität,
um bedarfsgerecht
und exakt nach Ver-
brauch abrechnen zu
können (Stichwort
„Pay per Use“). Ryan
Shuttleworth hat die-
ses Elastizitätsprin-
zip in [Shu12-a] und
[Shu12-b] dargestellt.
Im Gegensatz dazu
existieren in vielen
unternehmenseigenen
Rechenzentren nicht
genügend freie Hard-
ware-Ressourcen, um
nur ansatzweise eine
Elastizität wie die
Abb. 4: Agilissimo Projekte setzen den höchsten Reifegrad in allen vier Disziplinen voraus! großen Cloud-Anbie-
ter liefern zu können.
gesetzt werden konnten. Der größte He- Farley [Hum10] definiert wurde. Die Un- Mit einer elastischen Cloud werden Über-
bel zur Umsetzungsbeschleunigung von terschiede zu „Continuous Integration“ lastsituationen und Ausfälle unmittelbar
Ideen war demnach EIN Team mit Ent- und „Continuous Deployment“ werden kompensiert und unzufriedene Kunden
scheidungskompetenz. in [freecodecampCP] aufschlussreich er- vermieden. Insgesamt lassen sich dank
läutert. Aus Sicht des Autors setzen fast dieser Elastizität sogar die Kosten senken
DevOps und agilissimo alle Projekte zumindest eine „Continuous und trotzdem die Kundenzufriedenheit
Integration“ um. Einige erzielen bereits erhöhen.
DevOps besitzt zwei wesentliche Merk- ein „Continuous Delivery“, während Der wesentliche Unterschied zwischen
male. Eines ist die Zusammenarbeit von „Continuous Deployment“ momentan privater und öffentlicher Cloud wird an
Entwicklung und Betrieb, für die organi- eher die Ausnahme ist. diesem Praxisbeispiel deutlich: Der Be-
satorische Veränderungen im Unterneh- DevOps und Agilität sind wie Yin und trieb für ein in mehreren Microservices
men unabdingbar sind. Dies ist in großen Yang, da die Umsetzung von DevOps neu entwickeltes, unternehmenskritisches
Unternehmen schwieriger umzusetzen immer mit einer agilen Vorgehenswei- System sollte in einer privaten Cloud
als das zweite Merkmal: die vollständige se einhergeht. Bei Capgemini sind da- betrieben werden. Bereits mehr als ein
Automatisierung. Sie bezieht sich auf die her die entsprechenden Kompetenzen in Jahr vor Inbetriebnahme sollte der Autor
Prozesse zum Bauen, Installieren, Testen einem „Center of Excellence für Agile eine Einschätzung geben, wie viele vir-
und Produktivsetzen der IT-Systeme. Für & DevOps“ konzentriert. Für häufig in tuelle Maschinen mit wie viel RAM und
mehrtägige Abnahmetests ist bei „agilis- Projekten eingesetzte Technologiestacks CPU-Kapazität denn eingekauft werden
simo“ keine Zeit mehr, wenn eine Idee in existieren außerdem vorkonfigurierte, au- müssten. Wie schwer belastbare Aussa-
zwei Wochen umgesetzt sein soll. Daher tomatisierte Werkzeugketten, mit denen gen für ein neues, noch in der Entwick-
dürfen keine Releases mehr existieren, DevOps-Experten in kürzester Zeit neue lung befindliches System zu machen sind,
vielmehr geht man kontinuierlich in Pro- Projekte mit einer automatisierten Build- weiß jeder Architekt, der bereits für ver-
duktion, gemäß des Prinzips des „Conti- Deploy-Test-Pipeline ausstatten können. gleichbare Systeme verantwortlich war.
nuous Deployment“ ([freecodecampCP], So lässt sich schnell der erste Schritt in Es ging um circa 200 VMs mit 16 bis 64
[Sha17]). Richtung „Continuous Deployment“ um- GB RAM je nach Microservice und ent-
Beim „Continuous Deployment“ geht ein setzen. sprechender CPU-Kapazität. Vom Prinzip
gecheckter Quellcode sofort in Produkti- Deswegen ist jedem Unternehmen zu „IT aus der Steckdose“ war diese Anfrage
on, sofern innerhalb der automatisierten empfehlen, die eingesetzte Technologie- weit entfernt.
Teststufen kein Fehler entdeckt wurde, der vielfalt zu steuern und nicht nach Belieben In Form von Konfigurationsdateien –
die Produktivsetzung verhindert. „Conti- der Entwickler zuzulassen. So profitiert Stichwort „Infrastructure as Code“ –
nuous Deployment“ setzt Vertrauen und man leichter von den Erfahrungen aus an- können virtuelle Maschinen so eindeutig
einen hohen Reifegrad der Testautomati- deren Projekten und erzielt einen deutlich definiert werden, dass man exakt dieselbe
sierung voraus, der nur durch eine kon- höheren Reifegrad. Infrastrukturkonfiguration auf den ver-
tinuierliche Verbesserung zu erreichen ist. schiedenen Umgebungen – von Entwick-
So genannte „Feature Toggles“ [Feature- Cloud und agilissimo lung über verschiedene Teststufen bis zur
Flags] stellen sicher, dass keine halbferti- Produktion – sicherstellen kann. Das er-
gen Features produktiv sichtbar werden. Microservices und voll automatisierte spart böse Überraschungen aufgrund un-
„Continuous Deployment“ ist eine Fä- Teststufen können durch ihren Ressour- terschiedlicher Konfigurationen und Res-
higkeit, von der die meisten Unternehmen cenbedarf schnell zum Kostentreiber wer- sourcen können dank „Infrastructure as
noch weit entfernt sind. Vorstufen auf der den. Eine Cloud-Infrastruktur, die ihren Code“ bedarfsgerecht und automatisiert
Reifegradskala für DevOps sind „Conti- Namen verdient, macht „IT wie aus der hochgefahren werden, etwa für Last- und
nuous Integration“ sowie „Continuous Steckdose“ verfügbar, indem sie flexibel, Performanztests. Damit liefern Cloud-Inf-
Delivery“, das zum ersten Mal im gleich- schnell und automatisiert Ressourcen be- rastrukturen einen wichtigen Baustein für
namigen Buch-Klassiker von Humble und reitstellt. Der Vergleich bezieht sich auch die notwendige Testautomatisierung von
12
www.objektspektrum.de
Literatur & Links
[12FACT17] The Twelve Factor App, siehe: https://12factor.net/
[Bis15] K. Bishogo, Radical Agility with Autonomous Teams and Microservices, Zalando Techblog, 2015, siehe:
https://jobs.zalando.com/tech/blog/video-radical-agility-with-autonomous-teams-and-microservices/
[ENT18] What is the Difference between Cloud-Ready and Cloud-Native?, siehe:
https://www.entando.com/page/en/what_is_the_difference_between_cloudready_and_cloudnative?contentId=BLG4585
[FeatureFlags] The Hub for Feature Flag Driven Development, siehe: https://featureflags.io/literature/
[freecodecampCP] https://medium.com/free-code-camp/how-to-set-up-continuous-deployment-in-your-home-project-the-easy-way-41b84a467eed
[GartnerBimodal] https://www.gartner.com/it-glossary/bimodal/
[Hum10] J. Humble, D. Farrley, Continuous Delivery, Addison-Wesley, 2010
[NetflixBlog] https://medium.com/netflix-techblog
[OTTOBlog] https://www.otto.de/jobs/technology/techblog/
[OTTO16] G. Steinacker, Why Microservices, Otto, 20.3.2016, siehe:
https://www.otto.de/jobs/technology/techblog/artikel/why-microservices_2016-03-20.php
[ScaledAgile] https://www.scaledagile.com/enterprise-solutions/enterprise-challenges/
[Sha17] M. Shahin, M. A. Babar, M. Zahedi, L. Zhu, Beyond Continuous Delivery: An Empirical Investigation of Continuous Deployment Challenges, in:
ACM/IEEE Int. Symposium on Empirical Software Engineering and Measurement (ESEM), 2017
[Shu12-a] R. Shuttleworth, The Lean Cloud for Startups with AWS: Introduction & AWS Overview, Amazon Web Services, 2012
[Shu12-b] Ryan Shuttleworth, Journey Through the AWS Cloud; Building Powerful Web Applications, Nov. 2012, siehe:
https://www.slideshare.net/AmazonWebServices/jouney-buildingpowerfulwebapplications
[SoAR13] 13th annual State of Agile Report, COLLABNET VERSIONONE, siehe: https://stateofagile.versionone.com/
[TH18] Janakirma MSV, 10 key attributes of cloud-native applications, The New Stack, 19.7.2018, siehe:
https://thenewstack.io/10-key-attributes-of-cloud-native-applications/
[Til19] St. Tilkov, E. Wolff, Microservices ersetzen den Monolithen - Ameisenprinzip, in: IX, April 2019
der Entwicklung bis in die Produktion. matisierung bis zur Produktivsetzung mit Trend zu leichtgewichtigen Architekturen,
Letztlich ermöglicht nur die Kombination weniger Risiken umsetzen lässt. die ein sehr agiles Vorgehen unterstüt-
aus elastischer Cloud und „Infrastruc- Testverfahren für einzelne isolierte Mi- zen. Andere Trends sind event-gesteuerte
ture as Code“ die für ein „Continuous croservices sind zudem weniger aufwen- Architekturen mit Streaming-Tools wie
Deployment“ notwendige Testautoma- dig als Regressionstests für komplexe Kafka oder leichtgewichtige Prozess- oder
tisierung und die damit erforderlichen Deployment-Modulithen. In Verbindung Fallsteuerungen durch Produkte wie Ca-
Ressourcen für automatisierte Last- und mit einer verlässlichen Abhängigkeits- munda, Activiti und Drools, die schwer-
Performance-Tests. analyse der Microservices untereinander gewichtige Produkte rund um einen
Der Betrieb in der Cloud stellt weiterhin können somit deutlich kleinere Testsuiten selbstständigen Prozess-Server ablösen.
Anforderungen an die Anwendungsent- zielgenau angestoßen und Laufzeiten und
wicklung, wobei gemäß der Definition Ressourcenverbrauch minimiert werden. Wechselwirkungen
in [ENT18] „cloud-native“ Anwendun- Der Autor ist seit 2015 überzeugt, dass der Disziplinen
gen entwickelt werden sollten. Die zehn Microservices für unternehmenskriti-
Schlüsseleigenschaften in [TH18] oder die sche IT-Systeme der Architekturstil der Unter der Annahme, dass „agilissimo“ als
zwölf Faktoren in [12FACT17] sind ein Zukunft sind. Das gilt insbesondere für Reifegrad und die Umsetzung einer Idee
guter Startpunkt hierfür. Eine Empfehlung größere Microservices, sogenannte „Self- innerhalb von zwei Wochen angestrebt
in [TH18] ist der Einsatz loser gekoppel- Contained Systems“ (SCS), wie sie bei- wird, lässt sich die Wechselwirkung der
ter Microservices, welche die nächste Vo- spielsweise in [OTTO16] und [Til19], vier Disziplinen agiles Vorgehen, DevOps,
raussetzung für „agilissimo“ sind. Seiten 42 ff. dargestellt werden. Trotz- Cloud und Microservices aufzeigen: Das
dem muss auch heute nicht jeder Bereich agile Vorgehen ermöglicht die kurzen Ent-
Microservices und agilissimo in solchen IT-Systemen mit Hunderten scheidungswege, während DevOps bezie-
oder sogar Tausenden von Bearbeiter- hungsweise BizDevOps alle Entschei-
Das Risiko, ein neues Release eines ver- jahren agilissimo sein. Deshalb bietet es dungsträger einbezieht.
gleichsweise kleinen Microservice pro- sich an, Teilsysteme mit hohem „Time- Da innerhalb von zwei Wochen von der
duktiv zu setzen, ist deutlich geringer als To-Market“-Druck mit Microservices zu Idee bis zur Produktion keine Zeit für
bei großen und komplexen Deployment- bauen, während für andere Teilsysteme aufwendige manuelle Tests bleibt, ist die
Monolithen oder -Modulithen. Voraus- gut strukturierte Modulithen die erste vollständige Automatisierung der „Build-
setzung dafür ist, lose gekoppelte und Wahl bleiben. Deploy-Test-Run-Pipeline“ in allen Um-
damit voneinander unabhängig installier- Entsprechend zeigt sich ein eindeutiger gebungen unabdingbar – und zwar von
bare Microservices zu entwickeln. Dann Trend, dass die größten existierenden IT- der Entwicklung über die verschiedenen
lösen Fehler keine Fehlerlawine über ab- Systeme nicht mehr als EIN Modulith, Teststufen bis zur Produktion. Diese
hängige Microservices aus. Microservices sondern in mehreren Modulithen und Mi- Automatisierung ist wiederum nur mit
sind daher ein Architekturstil, mit dem croservices gebaut werden. Insgesamt ste- Cloud-Eigenschaften wie „Infrastructure
sich schrittweise die vollständige Auto- hen Microservices stellvertretend für den as Code“ bis auf die Ebene der Hardware-
13
01/2020 Schwerpunkt: Moderne Vorgehensmodelle – Was kommt nach Scrum und Kanban?
Ressourcen zuverlässig möglich. Die Elas- um die Entwicklung von kleinen über- mit der Agilität ist. Jeder beschäftigt sich
tizität der Cloud ermöglicht zugleich ein schaubaren Apps oder in Cloud-Plattfor- damit, aber die wenigsten haben bereits
günstiges Kosten- und Nutzenverhältnis. men angebotenen Services geht. Diese sind einen sehr hohen Reifegrad erreicht. So
Zahlreiche Microservices wären wieder- meist von überschaubarer Komplexität. schaffen es vorerst nur die wenigsten,
um ohne einen hohen Automatisierungs- Vielmehr adressiert Softwareentwicklung „agilissimo“ zu sein und eine Idee inner-
grad und die beschriebenen DevOps- und 4.0 die Entwicklung sehr umfangreicher halb von zwei Wochen trotz umfangrei-
Cloud-Eigenschaften nicht zu akzeptab- unternehmenskritischer Systeme. Doch cher Change Requests in Produktion zu
len Kosten als Ersatz für große Deploy- auch dort lässt sich die Transformation zu bringen. ||
ment-Modulithen zu betreiben. Welches mehr Agilität schrittweise innerhalb der
Unternehmen möchte schon Hunderte vier Disziplinen vorantreiben, sodass die
von Microservices ständig manuell neu Risiken jederzeit beherrschbar bleiben. Der Autor
installieren und überwachen? Aus der Beobachtung zahlreicher Pro-
Und Microservices tragen schließlich jekte in vielen Unternehmen schließt der
dazu bei, die Risiken bei der Entwick- Autor, dass sich heute alle Unternehmen
lung hin zum „Continuous Deployment“ und öffentlichen Institutionen mehr oder
zu verringern. Durch den reduzierten weniger mit den vier Disziplinen der Soft-
Testaufwand bei jeder Produktivsetzung wareentwicklung 4.0 beschäftigen. Jedes
lässt sich immer mit genügend Sicherheit Projekt oder Produkt besitzt allerdings
testen. Der Kreis der vier Disziplinen der in jeder Disziplin einen unterschiedlichen
Softwareentwicklung 4.0 schließt sich, Reifegrad. Entsprechend gibt es kaum ein
weil unabhängige Microservices die beste Projekt, dass sich agilissimo nennen darf:
Voraussetzung zur Bildung kleiner agiler Während der eine bei der Cloud weiter Dr. Karl Prott
Teams sind, die möglichst unabhängig ist, punktet der andere mit einem höhe- (karl.prott@capgemini.com)
voneinander entscheiden, entwickeln, tes- ren Reifegrad bei DevOps. Konsequent verantwortet seit über 20 Jahren als
ten und produktiv setzen sollen. auf Microservices setzen eher diejenigen, IT-Architekt bei Capgemini die Umsetzung
die beim Thema Agilität weit fortgeschrit- unternehmenskritischer IT-Systeme. Seit
Softwareentwicklung 4.0: ten sind und in ihren Projekten bereits an einiger Zeit unterstützt er als Architekt
Mehr als die Summe ihrer Teile Grenzen der Architektur stoßen, um noch die zahlreichen Angebote und hat dabei die
agiler zu werden. Bausteine von Softwareentwicklung 4.0 fest
Dem aufmerksamen Leser wird klar sein, So kann man zusammenfassen, dass es im Blick.
dass es bei Softwareentwicklung 4.0 nicht mit Softwareentwicklung 4.0 ähnlich wie
14Sie können auch lesen
