SlideShare ist ein Scribd-Unternehmen logo
1 von 107
Downloaden Sie, um offline zu lesen
ä
Die Architektur,
die man kann.
Ich bin heute hier um etwas über Softwarearchitektur zu reden. Beibringen kann ich vermutlich den wenigsten Leuten hier was, aber ich kann immerhin die Dinge
thematisieren, die bei Softwarearchitektur etwas komisch sind.
Wer hat alles einmal einen Commodore 64 besessen?
1997
Wir sind die Generation, die irgendwann in den 90ern angefangen hat, iT zu machen. Bei mir war das 1997.
ä
Und dort gab es einen klaren Ort für Architektur, der im Vorfeld stattfindet - bevor der tatsächliche Softwareentwurf stattfindet.
CTO
Lead Architect Lead Architect Head of QA
Senior Architect
Senior
Developer
NetSec

Consultant
Developer Developer
Performance
Consultant
CEO
Vice President
Product
Product 

Manager
Product Owner
Product
Designer
Die Systemarchitektur wurde meistens strategische gemacht, und gerne auf maximal hoher Ebene. Meist gibt es ein Board, das dafür verantwortlich ist.
ä
Und diese Art Diagramme kam da meist heraus. Je nach Vertrauen in die Kollegen konnte das mehrere Wände einnehmen.
ä
Thud-Factor:

How much noise does my
architecture make when I drop
the documentation on your
desk at the end of six weeks
Jerry Weinberg nennt das den Thud-Factor: Wenn ich keine Ahnung habe wie ich die Güte meiner Tätigkeit messen soll, dann substituiere ich die Messung mit etwas,
das ich beurteilen kann. Also dem Lärm, die die Dokumentation macht, wenn ich sie nach 6 Wochen auf den Tisch werfe.

Wer der hier anwesenden hat schon an 500-und-mehr-Seiten-Dokumenten lang implementieren dürfen?
ä
Lieber mehr Details 

als wichtiges übersehen.
Es gab einen guten Grund damals, solche Planungsmonster zu fabrizieren - wir haben, sofern es irgend möglich war, lieber mehr analysiert und mehr Details
berücksichtigt als wir es heute tun würden - schon aus Angst, wichtige Dinge zu übersehen.
Zeit
Wert
Erwarteter Wert
Geliefert
Und wenn ich nichts übersehen habe, dann liefere ich den erwarteten Wert, weil ich ja alles richtig geplant habe.
ä
Wer kennt alles dieses Diagramm? Genau, inzwischen dürfte es überall angekommen sein. „Künewin“ ausgesprochen, auch gerne Cynefin bzw. Cynefin in der direkten
Aussprache. Eigentlich kommt es aus Dave Snowden Forschung bei IBM, ist es heute ein typisches Knowledge-Management-Tool, das einem erlaubt, die eigene
Projektwelt zu verstehen.
ä
Typische größere Softwareprojekte, und auch die vollständige IT-Architektur eines Unternehmens, sind im Regelfall im Complex-Quadranten zu finden.
ä
s
Unbekannte Unbekannte :
wir können nicht wissen,
wonach wir fragen sollten.
Der Komplexe Quadrant ist der Bereich der Unknown Unknowns, sprich: der Dinge, von denen wir nicht wissen, dass wir sie nicht wissen. Und wenn wir nicht wissen
was uns fehlt, können wir auch nicht danach Fragen.
ä
Es ist egal, wie gut die
Architektur geplant wird.
Sie enthält nie die 

unbekannten Unbekannten.
Und da haben wir damals die erste Frustration erlebt. Völlig egal, wie viel Aufwand wir in Architektur gesteckt haben, es gab immer Dinge, die man im Zusammenspiel
übersehen hat.
ä
Der Bug im Netzwerktreiber.
Was der Nutzer eigentlich wollte.
Die „überraschende“ Verspätung
der zugesagten Schnittstelle.
Und wir kennen das alle aus der Praxis. Der Bug im Netzwerktreiber, der uns auf eine andere Device wechseln lässt. Das undokumentierte Verhalten der API, das uns ein
Proxy-Layer aufzwingt, um ein konsistentes Verhalten zu erzeugen. Die Überraschende Verspätung der zugesagten Schnittstelle, die zu einem Wechsel des SAAS-
Anbieters kurz vor Launch führt.
Zeit
Wert
Erwarteter Wert
Geliefert
Fehlend
Und wir allen kennen die Wirkung von unbekannten Unbekannten in der Praxis - nicht alle Dinge lassen sich so technisch realisieren wie wir es gerne hätten, und wir
müssen faule Kompromisse eingehen. Also liefern wir etwas weniger als ursprünglich erwartet. Zeitgleich zeigt uns der Erstaufschlag beim Kunden, welche Fragen wir
wirklich hätten stellen sollen - aber nicht wussten, dass wir danach fragen sollten.
CHAOS REPORT
KLASSISCH
29 %
57 %
14 %
Successful
Challenged
Failed
Quelle: Standish Group Chaos Report 2012
Die größte Studie zum Thema Softwareprojekte ist der Standish Group Chaos Report, den es seit über 20 Jahren gibt. Und der dokumentiert die traurige
Wahrheit, die uns Softwareleuten seit 20 Jahren Sorge macht und als „Softwarekrise“ quasi zu einem Dauerbrenner geworden ist. Nur 14% Prozent aller
Projekt sind in Time & Budget. 57 % laufen aus dem Budget und / oder der Zeitline, und 29 % werden nie fertiggestellt.
ä
Falsche Zeit …
Das V-Modell 97 ist nicht umsonst noch heute das empfohlene Vorgehen in der Bundesverwaltung, und dementsprechend kann das tatsächlich sehr lange dauern, bis zu
Jahren. Gerade letzte Woche sprach ich mit einer Freundin, die in einem grossen Unternehmen arbeitet und dort bei einem IT-Projekt auf Anforderungsseite dabei ist -
„Offiziell soll das schon immer 2017 fertig sein, aber jeder weiss, dass das vor 2019 nichts wird.“
CTO
Lead Architect Lead Architect Head of QA
Senior Architect
Senior
Developer
QA Engineer
Developer Developer Operations Guy
CEO
Vice President
Product
Product 

Manager
Product Owner
Product
Designer
Falscher Ort …
Und nicht nur auf der Zeitlinie ist das ein Problem, auch der Ort stimmt nicht. Das stellen nämlich die falschen Leute fest - nicht die mit Architektur beauftragten Planer,
sondern die operativ tätigen Leute.
Meanwhile, your competitors…
Innovation
Globalisierung
Digitale Transformation
Und das hat die Telekoms, die Siemens und die Rocket Internets dieser Welt damals nervös gemacht. 

Denn parallel passierte die Globalisierung, die digitale Transformation begann - Siemens versuchte damals noch um VOIP herumzukommen - und viele technische
Innovationen auf Basis des Internets.
ä
Nutze die Unternehmensarchitektur.
Nutze die Unternehmensprozesse.
Nimm alle Änderungen mit auf.
Liefere schnell & günstig.
Also gab es einen kräftigen Druck vom Markt, und die Firmen mussten schnell liefern. 

Man soll die Systemarchitektur wie geplant umsetzen, sich an die Vereinbarungen und Pläne halten, muss aber gleichzeitig nicht nur mit Überraschungen umgehen,
sondern auch schneller werden.
ä
„Dilbert-Faktor“
Offizielle
Vorgaben
RealitätDistanz
Ein Kunde von uns damals hat das ganze dann jeweils den Dilbert-Faktor genannt: 

Wie weit entfernt sich die Realität von den offiziellen Firmen-Anweisungen?
ä
Drei Seiten einer 

Organisation
Ich mag da das Modell von Stefan Kühl von passenderweise der Uni Bielefeld. Der ist dort Professor für Soziologie, und forscht an Themen wie
Organisationsentwicklung. Er schreibt auch Bücher dazu, zB „Wenn die Affen den Zoo regieren“, und dort führt er auch dieses Modell der Betrachtung von Unternehmen
an. Einige hier kennen vermutlich die Vorderbühne/Hinterbühne-Unterscheidung von Gerhard Wohland, dieses Modell ist verwandt.
Vorstands-

Vorsitzender
Teamleiter A Teamleiter B
Vorstand B
Mitarbeiter 1
Mitarbeiter 2
Mitarbeiter 3
Mitarbeiter 4
Vorstand A
Teamleiter C
Mitarbeiter 6
Mitarbeiter 7
Mitarbeiter 5 Mitarbeiter 8
Formale
Seite
Organigramm
Stellenbeschreibungen 

Offizielle Prozesse
Die formale Seite ist die, die wir bislang behandelt haben - das offizielle Organigramm, die Positionen, die Prozesse, die Abteilungen und die Verantwortungsübergänge
zwischen diesen. Diese Seite ist dokumentiert und gilt, wenn man sich nicht an sie hält muss man üblicherweise Rede & Antwort stehen. Faktisch muss man manchmal
aber drumherum arbeiten, damit es funktioniert.
Informale
Seite
Denkweisen 

Wahrnehmungsformen 

Handlungserwartungen
„Kultur“
Das ist dann die informale Seite der Organisation, die das beschreibt, was nicht dokumentiert ist, aber zur Arbeit in der Organisation gehört. Das sind die typischen
Denkweisen, die Wahrnehmungen von Themen, die Handlungserwartungen, die nicht explizit gemacht wurden. Viele kennen vermutlich das Fake-Organigram, in dem die
Freundin vom Chef, die Affäre, die persönliche Abneigung und Kinder an der gleichen Schule wirken.
Schauseite

Attraktive Darstellung nach aussen
Wertformulierungen
geschönt
Die Schauseite wiederum ist die Seite, mit der man sich nach draussen darstellt - im eigenen Interesse. Unsere Branche ist da quasi der Grossmeister, dass ist schlicht
der HR-Situation geschuldet. Die Showseite erzeugt immer lustige Dissonanzen, wenn Leute von innen mit Leuten von aussen über das Unternehmen diskutieren.
„Flache Hierarchien“ ist so ein Klassiker der Showseite.
Formale Seite Informale Seite
Professionelle
Architektur von
Enterprise Architects

UML & V-Modell

Die Fachabteilung
versucht Kundennutzen
unterzumogeln
Bei einem hohen Dilbert-Faktor begannen die Kollegen damals zweigleisig zu fahren - zum einen hält man sich an die offizielle Dokumentation, eskaliert
1-2 mal um offensichtlichen Unsinn aufzuzeigen und bei Auseinandersetzungen waffenfähiges Material in der Hand zu halten, und parallel im Hintergrund
und unter dem Radar nützliche Lösungen zu schaffen.
ä
Informale Welt
Excelgetriebene
Kernprozesse
Der nächste Schritt ist dann das explizite vollständige Abweichen von der Governance im Unternehmen. Man baut mit dem Tool, das man gerade kennt oder zur Hand
hat, eine Lösung, die von jeglichen Standards abweicht - mit der Ausrede, dass das ja nur temporär ist.
ä
„Temporäre 

Übergangslösungen“
1 Jahr geplant

>10 Jahre im Einsatz
3 Versuche „richtige
Architektur“
Eine der Lieblingslösungen in meiner Laufbahn ist eine Lösung, die mehr als 10 Jahre „temporär“ im Einsatz war - und dabei 2 Versuche überlebt hat, endlich durch eine
professionelle Lösung abgelöst zu werden.
U-Boot—
Projekte
Bishin zum vollständigen U-Boot-Projekt der Fachabteilung, bei dem alles - von Konzept, Architektur, Implementierung bis zum Hosting - unter dem Radar der
Technikstrategie des Unternehmens ablief.
Hmm, die wollen
die Methoden gar nicht,
die sie offiziell
haben.
Und wir hatten uns irgendwann daran gewöhnt, dass die Kunden zwar offiziell das eine wollten, inoffiziell aber was anderes.
Zeit
Wert
Erwarteter Wert
G
eliefert
Was sie tatsächlich wollten waren die kleinen u-Boot-Projekte, die zwar wenig Dokumentation Dokumentation hatten, dafür aber schnell lieferten - und so deutlich mehr
Wert generierten.
ä
Eine gute Idee erkennt man am
einfachsten daran, dass jemand
Schlaues sie schon vorher hatte.
Und wie immer gilt die goldene Regel: eine schlauere Idee lässt sich am einfachsten daran erkennen, dass jemand anderes sie schon vorher hatte :-)
Hey, das geht ja ziemlich 

vielen Leuten so …
2001
Dann hat es leider noch bis 2005 gedauert, bis wir endlich gemerkt haben, worum es unseren Kunden wirklich ging. Die wollten eigentlich agil, hohe Kooperation,
laufende Software, sie kennen das.
ä
Liefere funktionierende Software regelmäßig
innerhalb weniger Wochen oder Monate und
bevorzuge dabei die kürzere Zeitspanne.
Heiße Anforderungsänderungen selbst spät in der
Entwicklung willkommen. Agile Prozesse nutzen
Veränderungen zum Wettbewerbsvorteil
desKunden.
Da stand schnell Software liefern, und Änderungen willkommen heissen. Genau, das wollten die.
ä
„Die besten Architekturen, Anforderungen 

und Entwürfe entstehen durch 

selbstorganisierte Teams.“
Und auch zu Architektur hatten die was zu sagen. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams. Und wie gesagt, das
ganze stammt von 2001.
ä
:_
Design emerges. Architecture is a collaboration.
Build the simplest architecture that can possibly work
When in doubt, code, or model it out
They build it, they test it
There is no monopoly on innovation
SAFe
Heute, viele Jahre später, sieht das nicht grundlegend anders aus - nur etwas detaillierter. Sogar die dicken Kinder unter den agilen Methoden sind hier mit dabei.
CTO
Lead Architect Lead Architect
Senior Architect
Senior
Developer
Developer Developer
Da steht nicht
„Lead Architect“.
Auch nicht
„Architecture Board“
„Die besten Architekturen, Anforderungen 

und Entwürfe entstehen durch 

selbstorganisierte Teams.“
Und obwohl das so lange schon da steht, ist das oft nicht angekommen: Die besten Architekturen entstehen durch selbstorganisierte Teams.

Wenn man sich den Text ganz genau anschaut, dann wird man feststellen, dass da nicht „Lead Architect“ steht. Und noch mal genauer: da steht auch nicht Architecture
Board.
CTO
Lead
Architect
Lead Architect
Senior
Architect
Senior
Developer
Developer Developer
Nach Senior Developer
kommt Architekt.
Und das ist ein Problem in vielen funktionalen Organisationen. Dort gibt es schon im Rahmen des individuellen Karrierepfades hierarchische Funktionen, die eine
personenbezogene Architekturverantwortung haben. Wer von den Anwesenden hat einen Karrierepfad im Unternehmen, bei dem nach Senior Developer oder -
Consultant wahlweise Architektur oder disziplinarische Funktion folgt?
CTO
Lead
Architect
Lead Architect
Senior
Architect
Senior
Developer
Developer Developer
„Aber ich mache es doch 

mit dem Team!“
HIghest
Paid
Persons
Opinion
Bei uns lief das natürlich ganz ähnlich ab. Und weil wir agil arbeiten, haben die Kollegen natürlich Wert darauf gelegt, dass die Architektur vom ganzen Team kommt.
Trotzdem wurde auf sie gehört, obwohl sie selbst gar nicht so viel Wert darauf gelegt hätten. Wer kennt den Begriff „HIPPO“? Genau, die highest Paid Persons Opinion,
die auch dann - wie alle Hippos - ein anderes Gewicht hat, wenn der Hippo es gar nicht will.
CTO
Lead
Architect
Lead Architect
Senior
Architect
Senior
Developer
Developer Developer
Head of Frontend Development
Senior Manager BackEnd Development
Solution Architect Storage
Fazit für uns: das kann man schon so machen, aber es nicht nicht eben einfacher zu gemeinsamer Architektur zu kommen.
ä
Rollen statt
Positionen
Wir haben deshalb
teamverteilte Rollen
statt fester Positionen.
Wir sind deshalb zu teamgewählten, emergenten Rollen - wie es etwa Holacracy macht - gewechselt, die nach Situation und Bedarf angepasst werden. 

Aber natürlich kann auch eine gewählte Rolle so viel implizite Macht haben, dass sie einen gemeinsamen, emergenten Architekturprozess stört.
ä
Rollen statt
Positionen
Viele Folgeschmerzen
bei Karriere, Gehalt &
Weiterentwicklung
Und es gibt beliebig viele Folgeschmerzen, weil damit auch die meisten trivialen Wege zu Karriere, Gehalt und Weiterentwicklung verloren gehen, und man jetzt auf
einmal mit etwas schlauen um die Ecke kommen muss.
Informale
Seite
Denkweisen 

Wahrnehmungsformen 

Handlungserwartungen
„Kultur“
ä
Hero-Culture
Freiwillige Überstunden!
Retter des Projektes!
Das größte Commit(ment)!
Kompetenzträger Nr. 1!
aka „Engpass mit Ohren“
Informale Seite
zB wenn man eine Hero-Culture hat. Wir haben das lange Jahre gemacht, schliesslich kommen wir vom OpenSource. Und vom Standpunkt des Vorgesetzten aus klingt
das natürlich super. Diese Kollegen machen freiwillig Überstunden. Und nicht nur das - sie haben das Projekt schon mehrfach gerettet. Und natürlich kommen von Ihnen
deutlich mehr Commits als von den anderen. Denn sie haben am meisten Kompetenz. So viel, dass sie oft die Kollegen darum bitten, bestimmte Code-Stellen nicht
anzufassen, weil sie die einzigen sind, die das nötige Knowhow mitbringen.
ä
Hero-Culture
Wer macht die Architektur, 

wenn nur einer das nötige Wissen hat?
Matthäus-Effekt: Zu Knowhow 

kommt mehr Knowhow
Informale Seite
Im Resultat macht der Hero auch oft die Architektur. Er sitzt auf dem Wissen, lässt andere nicht daran teilhaben.

Tribal Leadership nennt das Level 2, konkret „I am great, you are not“
ä
Hero-Culture
Die Kompetenz der Kollegen fehlt
- in den Architekturentscheidungen
- bei der späteren Umsetzung
DDD weil eine Person
es (fast) kennt.
Informale Seite
Das resultiert in gleich zwei Dysfunktionen. Zum einen können die Kollegen Ihre Kompetenzen nicht einbringen, zum anderen fehlt ihnen die Umsetzungskompetenz.

Wir selbst haben es allen Ernstes fertiggebracht vor Jahren Domain Driven Design eingeführt, ohne dass sich auch nur ein anderer Kollege damit auskannte. Und die
Business-Seite, die eigentlich das Domainwissen mitbringen sollte, hat davon nie erfahren. Sie können sich vorstellen, wie gut das funktioniert hat.
ä
Software Architecture
by Blog Reading
1. Ich habe einen Blogartikel dazu gelesen
2. Es klingt interessant. Ich würde es gerne
mal probieren. Einarbeiten wäre mühsam.
3. Ich verargumentiere es bei nächster
Gelegenheit als optimale Architektur.
Für Manager gibt es im Cunningham-Wiki die Bezeichnung „Management by Inflight-Magazine“. Das Pendant unter den Softwarearchitekten ist die Architecture by Blog
Reading. Man liest einen Blog-Artikel, findet das Thema interessant, und würde es gerne mal in der Praxis probieren - ohne allerdings nennenswert Einarbeitungsaufwand
in das Thema zu stecken. 

Also wird es bei nächster Gelegenheit als Architekturvorschlag verargumentiert.
ä
DDD-Lite
DDD-Lite is a means of picking and choosing
a subset of the DDD tactical patterns, but
without giving full attention to discovering,
capturing, and enhancing the Ubiquitous
Language."
Das klingt auf den ersten Blick albern, aber taucht erstaunlich oft in der Praxis auf. Ein Beispiel ist DDD-lite, die Einführung der Tactical Patterns von DDD, ohne dass
gemeinsam mit den Nutzern eine Ubiquituous Language oder auch nur ein gemeinsames Domain Model etabliert wäre. 

Vielleicht liegt es an den vielen Kontakten in der PHP-Welt, aber ich wäre froh, wenn ich ab und zu auch mal ein CQRS und Event-Sourcing-Tupel sehen würde, von
dessen Events der User auch wüsste.
ä
MicroService-Envy
„MicroServices sind super!
Sie sind einfach! Ich verstehe es!
Neue Entwickler müssen weniger lernen!
Weniger Abhängigkeiten zu anderen!“
Im ThoughtWorks Technology Radar wird explizit vor MicroService-Envy gewarnt. Weil die eigene Softwarestruktur Probleme mit der Einarbeitung von neuen Personen
hat, weil man nicht in der Lage ist ein gutes Continuous Deployment hinzubekommen, weil man seine Abhängigkeiten nicht im Griff hat- deshalb möchte man
MicroServices einführen, denn sie versprechen, dass man diese Probleme gelöst bekommt. Dass diese Probleme andere Gründe in der Organisation haben, und oft gar
nichts mit der Architektur zu tun haben, das wird dabei gerne übersehen.
ä
Silver Bullet
Es gibt keine einzelne Entwicklung, weder als
Technik noch als Managementmethode, die
Produktivität, Verlässlichkeit oder
Einfachheit um eine Größenordnung
verbessert
Frederic P Brooks, 1986
Dieses Verhalten ist aber nicht eben neu - 1986 hat Frederic P Brooks ein Whitepaper über „Silver Bullets“ gemacht, mit dem passenden Titel „There are no silver
bullets“. Er sagt: 

Es gibt keine einzelne Entwicklung, weder als Technik noch als Management, die Produktivität, Verlässlichkeit oder Einfachheit um eine Größenordnung verbessert.
Trotzdem versuchen wir es immer wieder.
ä
Silver Bullets
- Functional Programming
- Artificial Intelligence
- NoSQL
- Node.JS
- React
- Domain Driven Design
- MicroServices
- Docker
Typische Silver Bullet der letzten Jahre waren Dinge wie Funktional Programming, NoSQL, Node.JS, React, Domain Driven Design, MicroServices und Docker.
ä
Silver Bullet
Known 

Unknown Planungsfehlschluss
/ Planning Fallacy
Wenn man sich so ein Silver Bullet anschaut, dann verstehen wir den Nutzen sehr gut, und können uns viele Szenarien ausmalen, in denen wir uns einen Benefit
vorstellen können. Was wir aber nicht sehen, und da sind wir wieder bei den unbekannten Unbekannten, sind die Probleme, die Folgekosten - sprich: die Accidental
Complexity, die wir uns mit dieser Architektur eingekauft haben. Das geht natürlich nicht nur uns so, sondern allen Menschen, beim Kahneman heisst das als kognitive
Verzerrung Planning Fallacy.
ä
Design emerges. Architecture is a collaboration.

(Wissen & Folgenabschätzung vergrössern)
Build the simplest architecture that can possibly work

(KISS & YAGNI)
When in doubt, code, or model it out

(Architectural Spikes)
Silver Bullets
vermeiden
Abhilfe für die Planning Fallacy bietet Kooperation. Um so mehr Kollegen beteiligt sind, um so eher erkenne ich zukünftige Obstacles, und um so mehr vergleichbares
Erfahrungswissen kann ich einbringen. 

Das gleiche Ziel verfolgt die Bitte um die einfachste Architektur die funktioniert - daher kommen auch Ansätze wie KISS oder YAGNI. 

Und natürlich Architectural Spikes, einfach mal auszuprobieren und damit das fehlende Wissen vervollständigen.
ä
Junior-Teams
machen Dunning Kruger
Und um so offensichtlicher diese Regeln für den erfahrenen Entwickler sind, um so schwieriger wird ist es für Junior-Teams, damit umzugehen. Und damit meine ich nicht
Teams aus Junior-Entwicklern - sondern Teams mit überschaubar viel Erfahrung aus selbst gewählten Architekturen. Gerne immer das gleiche Projekte oder noch nicht
so lange aus der Uni.
ä
Frontend-Guru
Backend-Architekt
Informale Seite
Und nicht nur da geht es auf der Informalen Seite schief. Das gleiche gilt für Kollegen mit deutlich unterschiedlichen Interessenschwerpunkten im agilen Team - zB
JavaScript-Hipster und Backend-Engineers. Während der eine grade das vor einem Monat neu eingeführte Framework durch ein neueres, besseres ersetzt, baut der
andere das Monitoring für den Mesos-Cluster um.
ä
Frontend-Tribe
Backend-Tribe
Informale Seite
Und weil die Frontend-Jungs nicht nur gemeinsame Kompetenzen und Themen haben, sondern auch gleiche Interessen, verstehen sie sich gut. 

Die Backend-Guys sehen das ähnlich. Sie sind unter sich, und froh darüber. Immerhin muss man sich nicht mit Hipstern abgeben, sondern implementieren gerade
SMACK
ä
Frontend-Tribe
Backend-TribeWe are
great.
You are
not.
Backend-

Stümper
Informale Seite
Und schwups hat man wieder ein Szenario aus Tribal Leadership. Weil man die eigenen Themen gut versteht und die eigenen Interessen wie Hintergründe kennt, verlässt
man sich im Frontend aufeinander. Im Gegensatz dazu machen die Jungs im Backend Dinge, die man nicht versteht, und die offensichtlich auch wichtige Dinge nicht
berücksichtigen.
ä
Frontend-Team!
Backend-Team!
2 Teams
Formale Seite
Und weil man lieber mit den kompetenten Leuten zusammenarbeit, schlägt man vor, dass man das Team trennt. Uns ist das auch oft beim Wachstum von Teams
passiert. 

Das kann auch implizit passieren. Wir hatten gerade letzte Woche den Fall, wo es eine längere Diskussion gab.
2 Teams
Frontend-Layer

jQuery, AngularJS 1, AngularJS2
Backend-Layer

jQuery, AngularJS 1, AngularJS2
REST/

JSON
Und, quasi unvermeidlich, hat man einige Zeit später so eine Architektur.
ä
„Organisationen, die Systeme entwerfen,
sind auf Entwürfe festgelegt, welche die
Kommunikationsstrukturen dieser
Organisationen abbilden.“ Conways Law
Dieses Phänomen kennen wir natürlich alle - es handelt sich um Conways Law. 

Organisationen, die Systeme entwerfen, können nur Systeme erzeugen, die ein Abbild Ihrer Kommunikationsstruktur sind.
äCTO
Lead Architect Lead Architect Head of QA
Senior
Architect
Senior
Developer QA Engineer
Developer Developer
Operations
Guy
CEO
Vice President
Product
Product 

Manager
Product
Owner
Product
Designer
Organisation Architektur
Conways Law
Aus der Kommunikation - oder, nach neueren Studien, aus der Organisationsstruktur selbst heraus ergibt sich also die Architektur.
Architecture
Board
Team 1 Team 2 Team 3
CTO
Enterprise Service Bus
Solution 1 Solution 2 Solution 3
Organisation
Architecture
Und das hat viele Varianten. zB das 2007 klassische SOA-Setup, das praktisch in der Mitte jeder Architektur-Tapete zu finden war.
Incredibly Slow Changes
Fast Changes Slow Changes Slow Changes
Organisation
Architecture
Fix it!
Architecture
Board
CTO
Und wenn man als Teil von Team 1 etwas ändern musste hatte alles 3 Geschwindigkeiten: 

Wenn ich es in Team 1 selbst machen konnte war es sehr schnell. Wenn ich dabei auf die Hilfe der anderen Teams angewiesen war ging es zwar langsamer, aber noch
ok. Und wenn ich Änderungen im ServiceBus selbst brauchte konnte es beliebig lang dauern, je nachdem, wie viele Meetingtermine im Architecture Board benötigt
werden.
Customer-Facing
Company
Company 2 Offshore-Company
Organisation
Architecture
Frontend-Layer
Backend-

Stack
Other 

Backend-

Stack
Eine andere Variante, die uns untergekommen ist: Hinter einem einzigen Portal stehen gleich 3 Firmen: eine ist Customer-Facing, eine ist als IT-Dienstleister vor Ort, und
die dritte gehört zwar zur Familie, wohnt aber in einem anderen Land. Im Resultat gibt es zwei konkurrierende Backend-Stocks - und natürlich Politik darüber.
ä
DevOps zitiert eine weitere Variante von Conways Law - funktional getrenntes Software-Development und Betrieb. Der eine Bereich muss zwar die Software des anderen
laufen lassen, hat aber ganz andere Ziele. Und sie verstehen sich nicht.
Der Lösungsansatz von DevOps ist deshalb eine Änderung der Arbeitsweise. An die Stelle von funktionaler Trennung tritt die direkte Zusammenarbeit.
Dev Ops
QA
DevOps
Prozesse
Werkzeuge
Leute
Ziele

Verständnis
Deshalb fordert DevOps, dass hier die Kommunikation in der Organisation geändert wird. Und man deshalb bei den funktionalen Themen Development, QA und Ops in
der Organisation zusammenarbeitet - in gemeinsamen Prozessen, mit gemeinsamen Werkzeugen, mit gemeinsamen Leuten, gemeinsamen Zielen - und, am Ende
resultierend - gemeinsamen Verständnis.
ä
Ich
kann also nur die
Architektur machen,
was meine
Organisation
Hmm, da fragt man sich natürlich, ob man faktisch überhaupt eine Wahl hatte - oder ob die Organisation zwangsläufig das ergibt, was die Organisation eben erlaubt.
ä
Inverse Conway
Maneuver
The 'Inverse Conway Maneuver' recommends
evolving your team and organizational
structure to promote your desired
architecture.
Die Jungs von Thoughworks haben deshalb das Inverse Conway Maneuver geschaffen - ich bewege meine Firma und mein Team dorthin, wo ich meine Architektur
haben möchte.
ä
Eine gute Idee erkennt man am
einfachsten daran, dass jemand
Schlaues sie schon vorher hatte.
Und wie immer gilt die goldene Regel: eine schlauere Idee lässt sich am einfachsten daran erkennen, dass jemand anderes sie schon vorher hatte :-)
Vice President
Product
Vice President
Development
Vice President
Quality
Vice President
Maintenance
Product
Developer
Software
Developer
Quality 

Assurance
Operator
Product Owner
Frontend
Developer
Tester
NetSec

Consultant
Product
Designer
Backend

Developer
Test
Infrastructure
Performance
Consultant
CEO
Um das mal am Beispiel zu zeigen. Wie schon berichtet ist die Herkunft vieler Unternehmen eine funktionale Organisation, zT auch in der Erweiterung zur Matrix-
Organisation.
One
Department
CTO
Senior Manager Senior Manager Product Owner Scrum Master
Manager Manager Developer Security Expert
Head of
Something
Doing actual
Work
Senior Developer QA Expert
CEO
Other
Department
Software Island
Wenn die Unternehmen einen IT-Schwerpunkt haben agile Methoden da meist schon Bewegung reingebracht - und in den IT-Departments gelten andere Regeln. Da gibt
es nicht nur Obst, Cola, informelle Kleidung und flexible Arbeitszeiten, sondern auch einen anderen Führungsstil.
Vice President
Product
Vice President
Development
Vice President
Quality
Vice President
Maintenance
Product
Developer
Software
Developer
Quality 

Assurance
Operator
Product Owner
Frontend
Developer
Tester
NetSec

Consultant
Product
Designer
Backend

Developer
Test
Infrastructure
Performance
Consultant
CEO
Selbstorganisiertes Team
You built it, you run it.
MicroServices
Microservices erlaben dank der DevOps-Methodenwelt dieses Thema weiter zu führen, denn das selbstorganisierte Team kann jetzt die komplette Strecke - von
Produktentwicklung bis zum Betrieb - selbst abbilden. Und wie man sieht steht es damit quasi quer zur funktionalen Organisation.
Infrastructure iOS Client
UserProfile

Web
Payment 

Service
System Engineer
Product
Developer
Product
Developer
Product
Developer
Security Guy Developer Developer Developer
Data Scientist System Engineer System Engineer System Engineer
CEO
MicroService-

Team
MicroService-

Team
Infrastructure-
Team
MicroService-

Team
Die funktionale Organisation wurde also in eine Themenbezogene gekippt, geschnitten nach Business-Domains.
Organisationsstruktur
nach Deployment

+ Innovation
statt Funktion
Und das hat einen ganz interessanten Effekt gebracht. Auf einmal ist nicht mehr die Spezialkompetenz die Schnittkante der Abteilungen, sondern das Deployment. Der
altmodische Admin-Task ist auf einmal massgeblich dafür, wie die Firma selbst geschnitten ist.
Damit ändert sich die Organisationsstruktur. Und es kommt etwas wie bei Spotify heraus. Ähnliche Modelle findet man auch bei Netflix, bei Valve und vielen anderen.

Hier gibt es immerhin noch einen Tribe Lead, der sich jeweils schüchtern an die linke obere Ecke gestellt hat.
MicroService-

Team
Infrastructure-
Team
In der deutschen Diskussion findet man oft das Pfirsichmodell von Unternehmen, dass von Gerhard Wohland definiert wurde und von Niels Pfläging - dem ich hier die
Grafik gestohlen habe - popularisiert wurde. Die kleinen Kreise am Rand sind die selbstorganisierten, autonomen Teams, die direkt am Markt lang arbeiten und sich
weiterentwickeln. Die Teams in der Mitte bieten diesen Teams Service, liefern zB Development- und andere gemeinsam genutzte Infrastruktur, die Core-Libraries etc.
Eine der Organisationsformen mit einem sehr guten Marketing-Department ist Holacracy - hier in einem Screenshot eines Berichtes auf Aljazeera. Diese Form wird also
wirklich ernst genommen. Holacracy - oder auf deutsch Holokratie - ist eine der Organisationsformen, die auf Basis von agiler Arbeit entstanden sind.
ä
Inverse Conway
Maneuver
Ok, dann machen wir 

das einfach mal?
Ok, und wie komme ich dahin?
How to Become a 

Microservice-Company 

in 5 Steps
1. Agile Methoden einführen & beherrschen
2. DevOps-Werkzeuge & -Kultur einführen
3. Agile Unternehmenskultur changemanagen
4. Unternehmen restrukturieren
5. Allen Code reengineeren
Der Nachteil an der Geschichte ist aber, dass man nur die formale Seite so frei definieren kann.
ä
VersionOne Report 2016
95% praktizieren agil
1%sind gescheitert
Schauen wir uns doch mal an, was typischerweise in den Unternehmen passiert. Eine wenigstens aktuelle Quelle ist der VersionOne Anual State of Agile Report. Die
Ergebnisse sind ein bisschen verfälscht, weil sie als Firma mit einem Tool für agile Unternehmen natürlich eher diese ansprechen.
ä
46 %
Unternehmensphilosophie oder -
kultur widerspricht agilen Kernwerten
41 %
Fehlende Erfahrung mit 

agilen Methoden
39 % Fehlende Managementunterstützung
38 %
Fehlende Unterstützung bei

der kulturellen Transition
Kernursachen für das Scheitern agiler Projekte
10th State of Agile Report aus 2016.
ä
83 % Tägliche Standups
82 % Priorisierter Backlog
59 % Teamschätzung
50 % Continuous Integration
27 % Continuous Deployment
Was machen die agilen 95%?
10th State of Agile Report aus 2016.
ä
Wie lange dauert
eine agile Transition?
?Wer befindet sich hier in einer digitalen Transition? 

Genau, wir machen das auch seit 2005, und haben mehr als 7 Jahre gebraucht, um die Teams wirklich brauchbar aufzustellen.
ä
1. Agile Methoden einführen & beherrschen
2. DevOps-Kultur & -Werkzeuge einführen
3. Agile Unternehmenskultur changemanagen
4. Unternehmen restrukturieren
5. Allen Code reengineeren
SO YOU MEAN TO TELL ME

YOU WANT TO DO 

ALL 5 STEPS 

BUT YOU CAN’T DO 

THE 1ST?
Und wir brauchen Jahre für den ersten Schritte, scheitern oft - und wollen mal alles schnell machen, weil unsere Wunscharchitektur das braucht?
ä
Autonome Teams mit 

dokumentierten Prozessen.
Selbstorganisierte Teams 

mit Architekturverantwortlichem.
MicroServices nach einem
vorgegebenen Techset
„Business Domains“, die 

das Business nicht kennt
Und was, wenn ich es 

einfach trotzdem mache?
Agile MicroService-Teams

die unnötige Features implementieren
Und was passiert, wenn ich es einfach trotzdem mache? 

Weil ich in einem Blogpost gelesen habe, dass MicroServices so etwas wie ein Silver Bullet sind?
ä
Okay, ich muss
also agil, DevOps und
die passenden Kultur
haben?
Hmm, da fragt man sich natürlich, ob man faktisch überhaupt eine Wahl hatte - oder ob die Organisation zwangsläufig das ergibt, was die Organisation eben erlaubt.
Warum nicht schon 1980?!
Aber noch etwas anderes ist bei DevOps passiert. Hätte man denn nicht schon deutlich vorher auf DevOps kommen können? Warum ist Flickr da erst 2009 drauf
gekommen?
Schauen wir doch mal direkt in den Talk von 2009 hinein, der DevOps in die Popularität gespült hat.
Und da ist was spanendes enthalten: sie reden vor allem über Technologie.
Hey, das ist ja
Architektur.
Diese Punkte sind Architektur. Das sind Technologiestacks, die dort eingeführt wurden. Und DevOps ist enstanden, weil jetzt diese Technologie zur Verfügung stand.
ä
Development Q.A. Operations
Continous Integration
Infrastructure as Code
Shared Version Control
Die vorher schwierige Kooperation mit den nachträglich angesetzten Qualitätsverantwortlichen wurde durch eine gemeinsame kontinuierliche Integration zu kooperativer
Arbeit. Regressionstests sind automatisch in die CI gefallen, und auf einmal brauchte sich die Q.A. nicht mehr um Wiederkehrerfehler kümmern, und man konnte die
eigenen Tests in Code giessen und damit einen guten Stapel Donkey-Work abgeben. 

Mit Infrastructure as Code gab es eine gemeinsame Basis für Konfiguration, und weil es alles im gemeinsamen Versionsmanagement war, konnten auch die anderen
unmittelbar damit arbeiten. Die Änderungen an Infrastruktur sind keine Frage von Produktions-Changes mehr, sondern ein Commit, der bei einer bestimmten Version
einfach mit übernommen wird. Automatisiert getestet, versteht sich.
„DevOps is just short for
DevProductSupportNetSecBizOps.
Und da hört es nicht auf. Die DevOps-Community sagt nicht umsonst: 

DevOps ist just short for DevProductSupportNetSecBizOps.
ä
Business
Analytics
Product
Development
Development Operations
Shared Metrics
Feature Toggles
Dabei spielen insbesondere zwei Dinge eine Rolle: gemeinsame Metriken über alles und Feature Toggles. Die Metriken werden im Regelfall hochtransparent für alle
sichtbar gemacht. Resultat ist ein gemeinsames Bild von der Gesamtsituation des eigenen Produktes, und es erlaubt einem gezielt an diesem zu verbessern. Mit guten
Metriken und Feature Toggles, also der Fähigkeit verschiedene Produktvarianten im Vergleich durchzumessen, kann auch der Business experimentieren - in Kooperation
mit Development, QA, Operations und Business Analytics.
Gemeinsam - von Business
Development bis Operations
Bei uns ist das meist ein ELK-Stack, der alle möglichen Daten auf Vorrat sammelt und es einfach macht, schnell und testweise kleine Experimente durchzuführen.
UndCTO
Lead Architect Lead Architect Head of QA
Senior
Architect
Senior
Developer QA Engineer
Developer Developer
Operations
Guy
CEO
Vice President
Product
Product 

Manager
Product
Owner
Product
Designer
Organisation Architektur
Architektur ist ein Enabler
für Organisationsentwicklung.
Und damit hat sich genau die andere Richtung gezeigt. Ich kann meine Organisation ändern, indem ich per Architektur neue Optionen und greifbaren Benefit bereitstelle -
zB durch schnellere Iterationen in Continuous Deployment, durch die Möglichkeit zur experimentellen Produktentwicklung per Feature Toggles, durch eine gemeinsame
Datengetriebene Geschäftssicht über schlaue Metriken.
Und
Die Organisation bestimmt die Architektur
bestimmt die Organisation
CTO
Lead Architect Lead Architect Head of QA
Senior
Architect
Senior
Developer
QA Engineer
Developer Developer
Operations
Guy
CEO
Vice President
Product
Product 

Manager
Product
Owner
Product
Designer
Organisation Architektur
Und damit habe ich eine Rückkopplung: Wenn ich die Organisation ändere wirkt das auch auf die Architektur, wenn ich die Architektur ändere wirkt das auf die
Organisation.
Organisations-
Entwicklung Architektur
Konvergenz von Architektur
und Organisationsentwicklung
Im Resultat haben wir eine teilweise Konvergenz von Architektur und Organisationsentwicklung. Und auch davon hat Frederic Brooks natürlich schon geredet, und im
Rahmen von MicroServices ist es akut geworden. Es gibt einen schönen (= kurzen) Artikel von Eberhard Wolff von innoQ dazu auf Heise: http://www.heise.de/developer/
artikel/Microservices-Architektur-oder-Organisation-2671835.html
ä
Also schnell MicroServices und die benötigte
Organisationsstruktur parallel einführen?
… eher nicht.
1. Agile Methoden einführen & beherrschen
2. DevOps-Kultur & -Werkzeuge einführen
3. Agile Unternehmenskultur changemanagen
4. Unternehmen restrukturieren
5. Allen Code reengineeren
Das heisst aber nicht, dass ich eben beides gleichzeitig machen muss damit es funktioniert. 

Das kann nicht klappen, denn die Voraussetzungen für eine Architektur _und_ eine Organisation _und_ eine Kultur sind sportlich.
ä
Die Unternehmen mit dem 

größten Leidensdruck 

haben auch den 

weitesten Weg.
1. Agile Methoden einführen & beherrschen
2. DevOps-Kultur & -Werkzeuge einführen
3. Agile Unternehmenskultur changemanagen
4. Unternehmen restrukturieren
5. Allen Code reengineeren
Und da steckt noch eine Gemeinheit dahinter - denn genau die Unternehmen, bei denen weder die Architektur, noch die Organisationsform, noch die Kultur stimmt
haben den größten Leidensdruck. Da macht die Neugründung oder der Kauf, wie er in einigen Fällen auch hier in Deutschland zu beobachten war, natürlich erheblich
Sinn - vorausgesetzt, dass man sich selbst davor schützt, die gekaufte Kultur zu assimilieren - und damit wieder da ist, wo man vorher schon war.
ä
Evolution
Wenn meine Strategie weder Neugründung, noch Kauf oder mittelfristige Insolvenz ist habe ich eine Evolution vor mir, bei der ich jeden Schritt mitgehen muss, um den
nächsten jenseits vom Cargo Cult zu erreichen. 

Und wie geht Evolution? Man probiert so lange Spezies durch, bis sich emergent etwas ergibt, was in meiner Umgebung am besten funktioniert. 

(Das Bild ist super, und ich habe viele Orte gefunden, an denen es genutzt wird - aber nicht den Ursprünglichen Ort.
Prozesse
Werkzeuge
Leute
Ziele

Verständnis
Organisations-
Entwicklung
Architektur
Agil
Und netterweise gibt es ein Methodenset, dass solche Dinge emergent entstehen lässt - die agilen Methoden. Ich würde also, frei nach DevOps, erwarten dass der
spannende Ort dieser Evolution die gemeinsame Arbeit der agilen Teams, der Organisationsentwicklung und der Architektur ist.
ä
Die Architektur, die man kann:
… ist eine gemeinsame Evolution von
• Architektur
• Organisationsentwicklung
• Team + Firmenkultur
Organisations-
Entwicklung
Architektur
Agil
Also, die Architektur, die man kann ist also heute die gemeinsame Evolution von Architektur, Organisationsentwicklung und der Team und Firmenkultur
ä
Autonome Teams mit 

dokumentierten Prozessen.
Selbstorganisierte Teams 

mit Architekturverantwortlichem.
MicroServices nach einem
vorgegebenen Techset
„Business Domains“, die 

das Business nicht kennt
Agile MicroService-Teams

die unnötige Features implementieren
Wenn ich das nicht gemeinsam mache lande ich in einer Dilbert-Welt, in der die formalen Strukturen und die informalen Strukturen kontinuierlich zu Dysfunktionen führen.
How to Become a 

Microservice-Company 

in 1 Step
1. Technologie auf 

MicroServices umstellen
1. Spotify-Modell einführen
Aber eins ist zumindest sicher - die Zeiten, in denen wir grosse Architekturen unabhängig von Teams und Organisation gemacht haben, sind vorbei.
ä
„Jetzt MicroServices?!
Wir haben doch nicht

mal Agil hinbekommen. 

Geschweige denn DevOps.“
Kritik & Fragen: @johannhartmann
hartmann@mayflower.de


Slides mit Tonspur:
http://slideshare.net/johannhartmann
Vielen Dank für Ihr Durchhaltevermögen.

Die Idee zu diesem Talk kam übrigens von dem Satz rechts oben, den ein befreundeter Entwickler in einem grösseren Unternehmen zu mir sagte :-)
ä
Die Architektur, die man kann:
Wenn ich kein DevOps kann, 

kann ich keine MicroServices.
Wenn ich eine klassische Hierarchie in der Technik
habe, bekomme ich keine autonomen Teams.
Wenn ich weder Daten noch Product Development mit
im Team habe, kann ich keinen grossen Businessvalue
mit MicroServices erzeugen.
Wenn ich agil nicht kann, 

kann ich keine MicroServices.
Also, die Architektur, die man kann:

Weitere ähnliche Inhalte

Was ist angesagt?

Einfangen eines technisch kaputten projektes
Einfangen eines technisch kaputten projektesEinfangen eines technisch kaputten projektes
Einfangen eines technisch kaputten projektesJohann-Peter Hartmann
 
Von Kutschern, Managern und Systemadministratoren
Von Kutschern, Managern und SystemadministratorenVon Kutschern, Managern und Systemadministratoren
Von Kutschern, Managern und SystemadministratorenJohann-Peter Hartmann
 
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit Notizen
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit NotizenAgility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit Notizen
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit NotizenGerrit Beine
 
Warum die it nicht um new work herumkommt
Warum die it nicht um new work herumkommtWarum die it nicht um new work herumkommt
Warum die it nicht um new work herumkommtJohann-Peter Hartmann
 
Lügen, schlimme Lügen und IT-Verträge
Lügen, schlimme Lügen und IT-VerträgeLügen, schlimme Lügen und IT-Verträge
Lügen, schlimme Lügen und IT-VerträgeJohann-Peter Hartmann
 
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...Mayflower GmbH
 
Arbeitswelt2020PechaKucha
Arbeitswelt2020PechaKuchaArbeitswelt2020PechaKucha
Arbeitswelt2020PechaKuchaElsy Zollikofer
 
Anforderungen haben immer Schuld
Anforderungen haben immer SchuldAnforderungen haben immer Schuld
Anforderungen haben immer SchuldFrank Düsterbeck
 
2013 OS E-Commerce Magento OXID Shopware
2013 OS E-Commerce Magento OXID Shopware2013 OS E-Commerce Magento OXID Shopware
2013 OS E-Commerce Magento OXID ShopwareBjörn Schotte
 

Was ist angesagt? (18)

Einfangen eines technisch kaputten projektes
Einfangen eines technisch kaputten projektesEinfangen eines technisch kaputten projektes
Einfangen eines technisch kaputten projektes
 
Von Kutschern, Managern und Systemadministratoren
Von Kutschern, Managern und SystemadministratorenVon Kutschern, Managern und Systemadministratoren
Von Kutschern, Managern und Systemadministratoren
 
Leadership in der IT
Leadership in der ITLeadership in der IT
Leadership in der IT
 
Reparier Deine Unternehmenskultur!
Reparier Deine Unternehmenskultur!Reparier Deine Unternehmenskultur!
Reparier Deine Unternehmenskultur!
 
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit Notizen
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit NotizenAgility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit Notizen
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit Notizen
 
Warum die it nicht um new work herumkommt
Warum die it nicht um new work herumkommtWarum die it nicht um new work herumkommt
Warum die it nicht um new work herumkommt
 
Lügen, schlimme Lügen und IT-Verträge
Lügen, schlimme Lügen und IT-VerträgeLügen, schlimme Lügen und IT-Verträge
Lügen, schlimme Lügen und IT-Verträge
 
Agile Führung - echt jetzt?
Agile Führung - echt jetzt?Agile Führung - echt jetzt?
Agile Führung - echt jetzt?
 
Vom Entwickler zur Führungskraft
Vom Entwickler zur FührungskraftVom Entwickler zur Führungskraft
Vom Entwickler zur Führungskraft
 
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
 
Rewrites überleben
Rewrites überlebenRewrites überleben
Rewrites überleben
 
Arbeitswelt2020 pecha kucha
Arbeitswelt2020 pecha kuchaArbeitswelt2020 pecha kucha
Arbeitswelt2020 pecha kucha
 
Arbeitswelt2020PechaKucha
Arbeitswelt2020PechaKuchaArbeitswelt2020PechaKucha
Arbeitswelt2020PechaKucha
 
Portfolio Kanban
Portfolio KanbanPortfolio Kanban
Portfolio Kanban
 
Wetware Bugs and Refactoring
Wetware Bugs and RefactoringWetware Bugs and Refactoring
Wetware Bugs and Refactoring
 
Anforderungen haben immer Schuld
Anforderungen haben immer SchuldAnforderungen haben immer Schuld
Anforderungen haben immer Schuld
 
Surviving Complexity
Surviving ComplexitySurviving Complexity
Surviving Complexity
 
2013 OS E-Commerce Magento OXID Shopware
2013 OS E-Commerce Magento OXID Shopware2013 OS E-Commerce Magento OXID Shopware
2013 OS E-Commerce Magento OXID Shopware
 

Andere mochten auch

JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?
JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?
JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?Johann-Peter Hartmann
 
How not to screw the operating system of your startup
How not to screw the operating system of your startupHow not to screw the operating system of your startup
How not to screw the operating system of your startupJohann-Peter Hartmann
 
Javascript Security
Javascript SecurityJavascript Security
Javascript Securityjgrahamc
 
Java script security for java developers
Java script security for java developersJava script security for java developers
Java script security for java developersJohann-Peter Hartmann
 

Andere mochten auch (7)

JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?
JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?
JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?
 
JavaScript Security
JavaScript SecurityJavaScript Security
JavaScript Security
 
How not to screw the operating system of your startup
How not to screw the operating system of your startupHow not to screw the operating system of your startup
How not to screw the operating system of your startup
 
DevOps jenseits der Tools
DevOps jenseits der ToolsDevOps jenseits der Tools
DevOps jenseits der Tools
 
DevOps beyond the Tools
DevOps beyond the ToolsDevOps beyond the Tools
DevOps beyond the Tools
 
Javascript Security
Javascript SecurityJavascript Security
Javascript Security
 
Java script security for java developers
Java script security for java developersJava script security for java developers
Java script security for java developers
 

Ähnlich wie Die Architektur, die man kann

Datenanalysen in der Softwareentwicklung mit Software Analytics
Datenanalysen in der Softwareentwicklung mit Software AnalyticsDatenanalysen in der Softwareentwicklung mit Software Analytics
Datenanalysen in der Softwareentwicklung mit Software AnalyticsMarkus Harrer
 
Webinar: Erfolgsfaktoren und Akzeptanzmaßnahmen bei der Einführung von ShareP...
Webinar: Erfolgsfaktoren und Akzeptanzmaßnahmen bei der Einführung von ShareP...Webinar: Erfolgsfaktoren und Akzeptanzmaßnahmen bei der Einführung von ShareP...
Webinar: Erfolgsfaktoren und Akzeptanzmaßnahmen bei der Einführung von ShareP...netmedianer GmbH
 
Das Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-Umgebung
Das Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-UmgebungDas Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-Umgebung
Das Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-UmgebungOPITZ CONSULTING Deutschland
 
Digitaler Wandel - jetzt machen, aber wie?! - Competence Book Teil 2
Digitaler Wandel - jetzt machen, aber wie?! - Competence Book Teil 2Digitaler Wandel - jetzt machen, aber wie?! - Competence Book Teil 2
Digitaler Wandel - jetzt machen, aber wie?! - Competence Book Teil 2Competence Books
 
2009 - Basta!: Agiles requirements engineering
2009 - Basta!: Agiles requirements engineering2009 - Basta!: Agiles requirements engineering
2009 - Basta!: Agiles requirements engineeringDaniel Fisher
 
Software Analytics - Datenanalysen in der Softwareentwicklung (BigDataMeetup)
Software Analytics - Datenanalysen in der Softwareentwicklung (BigDataMeetup)Software Analytics - Datenanalysen in der Softwareentwicklung (BigDataMeetup)
Software Analytics - Datenanalysen in der Softwareentwicklung (BigDataMeetup)Markus Harrer
 
E-Commerce Organisationsstrukturen
E-Commerce OrganisationsstrukturenE-Commerce Organisationsstrukturen
E-Commerce OrganisationsstrukturenBjörn Schotte
 
re:publica 2015 - E-Mail-Wahnsinn: Zeit für eine neue Art zu arbeiten #IBMDes...
re:publica 2015 - E-Mail-Wahnsinn: Zeit für eine neue Art zu arbeiten #IBMDes...re:publica 2015 - E-Mail-Wahnsinn: Zeit für eine neue Art zu arbeiten #IBMDes...
re:publica 2015 - E-Mail-Wahnsinn: Zeit für eine neue Art zu arbeiten #IBMDes...Stefan Pfeiffer
 
Communote im Einsatz – Die häufigsten Anwendungsfälle im Unternehmen
Communote im Einsatz – Die häufigsten Anwendungsfälle im UnternehmenCommunote im Einsatz – Die häufigsten Anwendungsfälle im Unternehmen
Communote im Einsatz – Die häufigsten Anwendungsfälle im UnternehmenCommunote GmbH
 
DNUG 36 2012_Konferenzbroschuere
DNUG 36 2012_KonferenzbroschuereDNUG 36 2012_Konferenzbroschuere
DNUG 36 2012_KonferenzbroschuereFriedel Jonker
 
E-Commerce vs Architektur CodeTalks.Commerce_2018
E-Commerce vs Architektur CodeTalks.Commerce_2018E-Commerce vs Architektur CodeTalks.Commerce_2018
E-Commerce vs Architektur CodeTalks.Commerce_2018Johann-Peter Hartmann
 
Digital Workplace - mehr als eine Cloud Plattform für Office Anwendungen
Digital Workplace - mehr als eine Cloud Plattform für Office AnwendungenDigital Workplace - mehr als eine Cloud Plattform für Office Anwendungen
Digital Workplace - mehr als eine Cloud Plattform für Office AnwendungenThomas Maeder
 
EventStorming für Domain-Driven Design
EventStorming für Domain-Driven DesignEventStorming für Domain-Driven Design
EventStorming für Domain-Driven DesignNicole Rauch
 
Design Thinking - Was niemand über Design Thinking sagt!
Design Thinking - Was niemand über Design Thinking sagt!Design Thinking - Was niemand über Design Thinking sagt!
Design Thinking - Was niemand über Design Thinking sagt!Lukas Fischer
 
eparo – Online-Konzeption (Vortrag ADC Young Masters 2012 – Rolf Schulte Stra...
eparo – Online-Konzeption (Vortrag ADC Young Masters 2012 – Rolf Schulte Stra...eparo – Online-Konzeption (Vortrag ADC Young Masters 2012 – Rolf Schulte Stra...
eparo – Online-Konzeption (Vortrag ADC Young Masters 2012 – Rolf Schulte Stra...eparo GmbH
 
Digitaler Wandel - jetzt machen, aber wie?! - Competence Book Teil 1
Digitaler Wandel - jetzt machen, aber wie?! - Competence Book Teil 1Digitaler Wandel - jetzt machen, aber wie?! - Competence Book Teil 1
Digitaler Wandel - jetzt machen, aber wie?! - Competence Book Teil 1Competence Books
 
Brave New Work - Neue Arbeitswelten: Ausblicke & Auswege
Brave New Work - Neue Arbeitswelten: Ausblicke & AuswegeBrave New Work - Neue Arbeitswelten: Ausblicke & Auswege
Brave New Work - Neue Arbeitswelten: Ausblicke & AuswegeDirkLoop
 
Rückblick Big Data Minds 2013
Rückblick Big Data Minds 2013Rückblick Big Data Minds 2013
Rückblick Big Data Minds 2013Maria Willamowius
 
Vortrag Objektspektrum Information Days 20. April 2016
Vortrag Objektspektrum Information Days 20. April 2016Vortrag Objektspektrum Information Days 20. April 2016
Vortrag Objektspektrum Information Days 20. April 2016gezeitenraum gbr
 

Ähnlich wie Die Architektur, die man kann (20)

Datenanalysen in der Softwareentwicklung mit Software Analytics
Datenanalysen in der Softwareentwicklung mit Software AnalyticsDatenanalysen in der Softwareentwicklung mit Software Analytics
Datenanalysen in der Softwareentwicklung mit Software Analytics
 
Webinar: Erfolgsfaktoren und Akzeptanzmaßnahmen bei der Einführung von ShareP...
Webinar: Erfolgsfaktoren und Akzeptanzmaßnahmen bei der Einführung von ShareP...Webinar: Erfolgsfaktoren und Akzeptanzmaßnahmen bei der Einführung von ShareP...
Webinar: Erfolgsfaktoren und Akzeptanzmaßnahmen bei der Einführung von ShareP...
 
Rewrites überleben
Rewrites überlebenRewrites überleben
Rewrites überleben
 
Das Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-Umgebung
Das Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-UmgebungDas Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-Umgebung
Das Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-Umgebung
 
Digitaler Wandel - jetzt machen, aber wie?! - Competence Book Teil 2
Digitaler Wandel - jetzt machen, aber wie?! - Competence Book Teil 2Digitaler Wandel - jetzt machen, aber wie?! - Competence Book Teil 2
Digitaler Wandel - jetzt machen, aber wie?! - Competence Book Teil 2
 
2009 - Basta!: Agiles requirements engineering
2009 - Basta!: Agiles requirements engineering2009 - Basta!: Agiles requirements engineering
2009 - Basta!: Agiles requirements engineering
 
Software Analytics - Datenanalysen in der Softwareentwicklung (BigDataMeetup)
Software Analytics - Datenanalysen in der Softwareentwicklung (BigDataMeetup)Software Analytics - Datenanalysen in der Softwareentwicklung (BigDataMeetup)
Software Analytics - Datenanalysen in der Softwareentwicklung (BigDataMeetup)
 
E-Commerce Organisationsstrukturen
E-Commerce OrganisationsstrukturenE-Commerce Organisationsstrukturen
E-Commerce Organisationsstrukturen
 
re:publica 2015 - E-Mail-Wahnsinn: Zeit für eine neue Art zu arbeiten #IBMDes...
re:publica 2015 - E-Mail-Wahnsinn: Zeit für eine neue Art zu arbeiten #IBMDes...re:publica 2015 - E-Mail-Wahnsinn: Zeit für eine neue Art zu arbeiten #IBMDes...
re:publica 2015 - E-Mail-Wahnsinn: Zeit für eine neue Art zu arbeiten #IBMDes...
 
Communote im Einsatz – Die häufigsten Anwendungsfälle im Unternehmen
Communote im Einsatz – Die häufigsten Anwendungsfälle im UnternehmenCommunote im Einsatz – Die häufigsten Anwendungsfälle im Unternehmen
Communote im Einsatz – Die häufigsten Anwendungsfälle im Unternehmen
 
DNUG 36 2012_Konferenzbroschuere
DNUG 36 2012_KonferenzbroschuereDNUG 36 2012_Konferenzbroschuere
DNUG 36 2012_Konferenzbroschuere
 
E-Commerce vs Architektur CodeTalks.Commerce_2018
E-Commerce vs Architektur CodeTalks.Commerce_2018E-Commerce vs Architektur CodeTalks.Commerce_2018
E-Commerce vs Architektur CodeTalks.Commerce_2018
 
Digital Workplace - mehr als eine Cloud Plattform für Office Anwendungen
Digital Workplace - mehr als eine Cloud Plattform für Office AnwendungenDigital Workplace - mehr als eine Cloud Plattform für Office Anwendungen
Digital Workplace - mehr als eine Cloud Plattform für Office Anwendungen
 
EventStorming für Domain-Driven Design
EventStorming für Domain-Driven DesignEventStorming für Domain-Driven Design
EventStorming für Domain-Driven Design
 
Design Thinking - Was niemand über Design Thinking sagt!
Design Thinking - Was niemand über Design Thinking sagt!Design Thinking - Was niemand über Design Thinking sagt!
Design Thinking - Was niemand über Design Thinking sagt!
 
eparo – Online-Konzeption (Vortrag ADC Young Masters 2012 – Rolf Schulte Stra...
eparo – Online-Konzeption (Vortrag ADC Young Masters 2012 – Rolf Schulte Stra...eparo – Online-Konzeption (Vortrag ADC Young Masters 2012 – Rolf Schulte Stra...
eparo – Online-Konzeption (Vortrag ADC Young Masters 2012 – Rolf Schulte Stra...
 
Digitaler Wandel - jetzt machen, aber wie?! - Competence Book Teil 1
Digitaler Wandel - jetzt machen, aber wie?! - Competence Book Teil 1Digitaler Wandel - jetzt machen, aber wie?! - Competence Book Teil 1
Digitaler Wandel - jetzt machen, aber wie?! - Competence Book Teil 1
 
Brave New Work - Neue Arbeitswelten: Ausblicke & Auswege
Brave New Work - Neue Arbeitswelten: Ausblicke & AuswegeBrave New Work - Neue Arbeitswelten: Ausblicke & Auswege
Brave New Work - Neue Arbeitswelten: Ausblicke & Auswege
 
Rückblick Big Data Minds 2013
Rückblick Big Data Minds 2013Rückblick Big Data Minds 2013
Rückblick Big Data Minds 2013
 
Vortrag Objektspektrum Information Days 20. April 2016
Vortrag Objektspektrum Information Days 20. April 2016Vortrag Objektspektrum Information Days 20. April 2016
Vortrag Objektspektrum Information Days 20. April 2016
 

Die Architektur, die man kann

  • 1. ä Die Architektur, die man kann. Ich bin heute hier um etwas über Softwarearchitektur zu reden. Beibringen kann ich vermutlich den wenigsten Leuten hier was, aber ich kann immerhin die Dinge thematisieren, die bei Softwarearchitektur etwas komisch sind.
  • 2. Wer hat alles einmal einen Commodore 64 besessen?
  • 3. 1997 Wir sind die Generation, die irgendwann in den 90ern angefangen hat, iT zu machen. Bei mir war das 1997.
  • 4. ä Und dort gab es einen klaren Ort für Architektur, der im Vorfeld stattfindet - bevor der tatsächliche Softwareentwurf stattfindet.
  • 5. CTO Lead Architect Lead Architect Head of QA Senior Architect Senior Developer NetSec
 Consultant Developer Developer Performance Consultant CEO Vice President Product Product 
 Manager Product Owner Product Designer Die Systemarchitektur wurde meistens strategische gemacht, und gerne auf maximal hoher Ebene. Meist gibt es ein Board, das dafür verantwortlich ist.
  • 6. ä Und diese Art Diagramme kam da meist heraus. Je nach Vertrauen in die Kollegen konnte das mehrere Wände einnehmen.
  • 7. ä Thud-Factor:
 How much noise does my architecture make when I drop the documentation on your desk at the end of six weeks Jerry Weinberg nennt das den Thud-Factor: Wenn ich keine Ahnung habe wie ich die Güte meiner Tätigkeit messen soll, dann substituiere ich die Messung mit etwas, das ich beurteilen kann. Also dem Lärm, die die Dokumentation macht, wenn ich sie nach 6 Wochen auf den Tisch werfe. Wer der hier anwesenden hat schon an 500-und-mehr-Seiten-Dokumenten lang implementieren dürfen?
  • 8. ä Lieber mehr Details 
 als wichtiges übersehen. Es gab einen guten Grund damals, solche Planungsmonster zu fabrizieren - wir haben, sofern es irgend möglich war, lieber mehr analysiert und mehr Details berücksichtigt als wir es heute tun würden - schon aus Angst, wichtige Dinge zu übersehen.
  • 9. Zeit Wert Erwarteter Wert Geliefert Und wenn ich nichts übersehen habe, dann liefere ich den erwarteten Wert, weil ich ja alles richtig geplant habe.
  • 10. ä Wer kennt alles dieses Diagramm? Genau, inzwischen dürfte es überall angekommen sein. „Künewin“ ausgesprochen, auch gerne Cynefin bzw. Cynefin in der direkten Aussprache. Eigentlich kommt es aus Dave Snowden Forschung bei IBM, ist es heute ein typisches Knowledge-Management-Tool, das einem erlaubt, die eigene Projektwelt zu verstehen.
  • 11. ä Typische größere Softwareprojekte, und auch die vollständige IT-Architektur eines Unternehmens, sind im Regelfall im Complex-Quadranten zu finden.
  • 12. ä s Unbekannte Unbekannte : wir können nicht wissen, wonach wir fragen sollten. Der Komplexe Quadrant ist der Bereich der Unknown Unknowns, sprich: der Dinge, von denen wir nicht wissen, dass wir sie nicht wissen. Und wenn wir nicht wissen was uns fehlt, können wir auch nicht danach Fragen.
  • 13. ä Es ist egal, wie gut die Architektur geplant wird. Sie enthält nie die 
 unbekannten Unbekannten. Und da haben wir damals die erste Frustration erlebt. Völlig egal, wie viel Aufwand wir in Architektur gesteckt haben, es gab immer Dinge, die man im Zusammenspiel übersehen hat.
  • 14. ä Der Bug im Netzwerktreiber. Was der Nutzer eigentlich wollte. Die „überraschende“ Verspätung der zugesagten Schnittstelle. Und wir kennen das alle aus der Praxis. Der Bug im Netzwerktreiber, der uns auf eine andere Device wechseln lässt. Das undokumentierte Verhalten der API, das uns ein Proxy-Layer aufzwingt, um ein konsistentes Verhalten zu erzeugen. Die Überraschende Verspätung der zugesagten Schnittstelle, die zu einem Wechsel des SAAS- Anbieters kurz vor Launch führt.
  • 15. Zeit Wert Erwarteter Wert Geliefert Fehlend Und wir allen kennen die Wirkung von unbekannten Unbekannten in der Praxis - nicht alle Dinge lassen sich so technisch realisieren wie wir es gerne hätten, und wir müssen faule Kompromisse eingehen. Also liefern wir etwas weniger als ursprünglich erwartet. Zeitgleich zeigt uns der Erstaufschlag beim Kunden, welche Fragen wir wirklich hätten stellen sollen - aber nicht wussten, dass wir danach fragen sollten.
  • 16. CHAOS REPORT KLASSISCH 29 % 57 % 14 % Successful Challenged Failed Quelle: Standish Group Chaos Report 2012 Die größte Studie zum Thema Softwareprojekte ist der Standish Group Chaos Report, den es seit über 20 Jahren gibt. Und der dokumentiert die traurige Wahrheit, die uns Softwareleuten seit 20 Jahren Sorge macht und als „Softwarekrise“ quasi zu einem Dauerbrenner geworden ist. Nur 14% Prozent aller Projekt sind in Time & Budget. 57 % laufen aus dem Budget und / oder der Zeitline, und 29 % werden nie fertiggestellt.
  • 17. ä Falsche Zeit … Das V-Modell 97 ist nicht umsonst noch heute das empfohlene Vorgehen in der Bundesverwaltung, und dementsprechend kann das tatsächlich sehr lange dauern, bis zu Jahren. Gerade letzte Woche sprach ich mit einer Freundin, die in einem grossen Unternehmen arbeitet und dort bei einem IT-Projekt auf Anforderungsseite dabei ist - „Offiziell soll das schon immer 2017 fertig sein, aber jeder weiss, dass das vor 2019 nichts wird.“
  • 18. CTO Lead Architect Lead Architect Head of QA Senior Architect Senior Developer QA Engineer Developer Developer Operations Guy CEO Vice President Product Product 
 Manager Product Owner Product Designer Falscher Ort … Und nicht nur auf der Zeitlinie ist das ein Problem, auch der Ort stimmt nicht. Das stellen nämlich die falschen Leute fest - nicht die mit Architektur beauftragten Planer, sondern die operativ tätigen Leute.
  • 19. Meanwhile, your competitors… Innovation Globalisierung Digitale Transformation Und das hat die Telekoms, die Siemens und die Rocket Internets dieser Welt damals nervös gemacht. Denn parallel passierte die Globalisierung, die digitale Transformation begann - Siemens versuchte damals noch um VOIP herumzukommen - und viele technische Innovationen auf Basis des Internets.
  • 20. ä Nutze die Unternehmensarchitektur. Nutze die Unternehmensprozesse. Nimm alle Änderungen mit auf. Liefere schnell & günstig. Also gab es einen kräftigen Druck vom Markt, und die Firmen mussten schnell liefern. 
 Man soll die Systemarchitektur wie geplant umsetzen, sich an die Vereinbarungen und Pläne halten, muss aber gleichzeitig nicht nur mit Überraschungen umgehen, sondern auch schneller werden.
  • 21. ä „Dilbert-Faktor“ Offizielle Vorgaben RealitätDistanz Ein Kunde von uns damals hat das ganze dann jeweils den Dilbert-Faktor genannt: Wie weit entfernt sich die Realität von den offiziellen Firmen-Anweisungen?
  • 22. ä Drei Seiten einer 
 Organisation Ich mag da das Modell von Stefan Kühl von passenderweise der Uni Bielefeld. Der ist dort Professor für Soziologie, und forscht an Themen wie Organisationsentwicklung. Er schreibt auch Bücher dazu, zB „Wenn die Affen den Zoo regieren“, und dort führt er auch dieses Modell der Betrachtung von Unternehmen an. Einige hier kennen vermutlich die Vorderbühne/Hinterbühne-Unterscheidung von Gerhard Wohland, dieses Modell ist verwandt.
  • 23. Vorstands-
 Vorsitzender Teamleiter A Teamleiter B Vorstand B Mitarbeiter 1 Mitarbeiter 2 Mitarbeiter 3 Mitarbeiter 4 Vorstand A Teamleiter C Mitarbeiter 6 Mitarbeiter 7 Mitarbeiter 5 Mitarbeiter 8 Formale Seite Organigramm Stellenbeschreibungen 
 Offizielle Prozesse Die formale Seite ist die, die wir bislang behandelt haben - das offizielle Organigramm, die Positionen, die Prozesse, die Abteilungen und die Verantwortungsübergänge zwischen diesen. Diese Seite ist dokumentiert und gilt, wenn man sich nicht an sie hält muss man üblicherweise Rede & Antwort stehen. Faktisch muss man manchmal aber drumherum arbeiten, damit es funktioniert.
  • 24. Informale Seite Denkweisen 
 Wahrnehmungsformen 
 Handlungserwartungen „Kultur“ Das ist dann die informale Seite der Organisation, die das beschreibt, was nicht dokumentiert ist, aber zur Arbeit in der Organisation gehört. Das sind die typischen Denkweisen, die Wahrnehmungen von Themen, die Handlungserwartungen, die nicht explizit gemacht wurden. Viele kennen vermutlich das Fake-Organigram, in dem die Freundin vom Chef, die Affäre, die persönliche Abneigung und Kinder an der gleichen Schule wirken.
  • 25. Schauseite
 Attraktive Darstellung nach aussen Wertformulierungen geschönt Die Schauseite wiederum ist die Seite, mit der man sich nach draussen darstellt - im eigenen Interesse. Unsere Branche ist da quasi der Grossmeister, dass ist schlicht der HR-Situation geschuldet. Die Showseite erzeugt immer lustige Dissonanzen, wenn Leute von innen mit Leuten von aussen über das Unternehmen diskutieren. „Flache Hierarchien“ ist so ein Klassiker der Showseite.
  • 26. Formale Seite Informale Seite Professionelle Architektur von Enterprise Architects
 UML & V-Modell
 Die Fachabteilung versucht Kundennutzen unterzumogeln Bei einem hohen Dilbert-Faktor begannen die Kollegen damals zweigleisig zu fahren - zum einen hält man sich an die offizielle Dokumentation, eskaliert 1-2 mal um offensichtlichen Unsinn aufzuzeigen und bei Auseinandersetzungen waffenfähiges Material in der Hand zu halten, und parallel im Hintergrund und unter dem Radar nützliche Lösungen zu schaffen.
  • 27. ä Informale Welt Excelgetriebene Kernprozesse Der nächste Schritt ist dann das explizite vollständige Abweichen von der Governance im Unternehmen. Man baut mit dem Tool, das man gerade kennt oder zur Hand hat, eine Lösung, die von jeglichen Standards abweicht - mit der Ausrede, dass das ja nur temporär ist.
  • 28. ä „Temporäre 
 Übergangslösungen“ 1 Jahr geplant
 >10 Jahre im Einsatz 3 Versuche „richtige Architektur“ Eine der Lieblingslösungen in meiner Laufbahn ist eine Lösung, die mehr als 10 Jahre „temporär“ im Einsatz war - und dabei 2 Versuche überlebt hat, endlich durch eine professionelle Lösung abgelöst zu werden.
  • 29. U-Boot— Projekte Bishin zum vollständigen U-Boot-Projekt der Fachabteilung, bei dem alles - von Konzept, Architektur, Implementierung bis zum Hosting - unter dem Radar der Technikstrategie des Unternehmens ablief.
  • 30. Hmm, die wollen die Methoden gar nicht, die sie offiziell haben. Und wir hatten uns irgendwann daran gewöhnt, dass die Kunden zwar offiziell das eine wollten, inoffiziell aber was anderes.
  • 31. Zeit Wert Erwarteter Wert G eliefert Was sie tatsächlich wollten waren die kleinen u-Boot-Projekte, die zwar wenig Dokumentation Dokumentation hatten, dafür aber schnell lieferten - und so deutlich mehr Wert generierten.
  • 32. ä Eine gute Idee erkennt man am einfachsten daran, dass jemand Schlaues sie schon vorher hatte. Und wie immer gilt die goldene Regel: eine schlauere Idee lässt sich am einfachsten daran erkennen, dass jemand anderes sie schon vorher hatte :-)
  • 33. Hey, das geht ja ziemlich 
 vielen Leuten so … 2001 Dann hat es leider noch bis 2005 gedauert, bis wir endlich gemerkt haben, worum es unseren Kunden wirklich ging. Die wollten eigentlich agil, hohe Kooperation, laufende Software, sie kennen das.
  • 34. ä Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne. Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil desKunden. Da stand schnell Software liefern, und Änderungen willkommen heissen. Genau, das wollten die.
  • 35. ä „Die besten Architekturen, Anforderungen 
 und Entwürfe entstehen durch 
 selbstorganisierte Teams.“ Und auch zu Architektur hatten die was zu sagen. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams. Und wie gesagt, das ganze stammt von 2001.
  • 36. ä :_ Design emerges. Architecture is a collaboration. Build the simplest architecture that can possibly work When in doubt, code, or model it out They build it, they test it There is no monopoly on innovation SAFe Heute, viele Jahre später, sieht das nicht grundlegend anders aus - nur etwas detaillierter. Sogar die dicken Kinder unter den agilen Methoden sind hier mit dabei.
  • 37. CTO Lead Architect Lead Architect Senior Architect Senior Developer Developer Developer Da steht nicht „Lead Architect“. Auch nicht „Architecture Board“ „Die besten Architekturen, Anforderungen 
 und Entwürfe entstehen durch 
 selbstorganisierte Teams.“ Und obwohl das so lange schon da steht, ist das oft nicht angekommen: Die besten Architekturen entstehen durch selbstorganisierte Teams. Wenn man sich den Text ganz genau anschaut, dann wird man feststellen, dass da nicht „Lead Architect“ steht. Und noch mal genauer: da steht auch nicht Architecture Board.
  • 38. CTO Lead Architect Lead Architect Senior Architect Senior Developer Developer Developer Nach Senior Developer kommt Architekt. Und das ist ein Problem in vielen funktionalen Organisationen. Dort gibt es schon im Rahmen des individuellen Karrierepfades hierarchische Funktionen, die eine personenbezogene Architekturverantwortung haben. Wer von den Anwesenden hat einen Karrierepfad im Unternehmen, bei dem nach Senior Developer oder - Consultant wahlweise Architektur oder disziplinarische Funktion folgt?
  • 39. CTO Lead Architect Lead Architect Senior Architect Senior Developer Developer Developer „Aber ich mache es doch 
 mit dem Team!“ HIghest Paid Persons Opinion Bei uns lief das natürlich ganz ähnlich ab. Und weil wir agil arbeiten, haben die Kollegen natürlich Wert darauf gelegt, dass die Architektur vom ganzen Team kommt. Trotzdem wurde auf sie gehört, obwohl sie selbst gar nicht so viel Wert darauf gelegt hätten. Wer kennt den Begriff „HIPPO“? Genau, die highest Paid Persons Opinion, die auch dann - wie alle Hippos - ein anderes Gewicht hat, wenn der Hippo es gar nicht will.
  • 40. CTO Lead Architect Lead Architect Senior Architect Senior Developer Developer Developer Head of Frontend Development Senior Manager BackEnd Development Solution Architect Storage Fazit für uns: das kann man schon so machen, aber es nicht nicht eben einfacher zu gemeinsamer Architektur zu kommen.
  • 41. ä Rollen statt Positionen Wir haben deshalb teamverteilte Rollen statt fester Positionen. Wir sind deshalb zu teamgewählten, emergenten Rollen - wie es etwa Holacracy macht - gewechselt, die nach Situation und Bedarf angepasst werden. Aber natürlich kann auch eine gewählte Rolle so viel implizite Macht haben, dass sie einen gemeinsamen, emergenten Architekturprozess stört.
  • 42. ä Rollen statt Positionen Viele Folgeschmerzen bei Karriere, Gehalt & Weiterentwicklung Und es gibt beliebig viele Folgeschmerzen, weil damit auch die meisten trivialen Wege zu Karriere, Gehalt und Weiterentwicklung verloren gehen, und man jetzt auf einmal mit etwas schlauen um die Ecke kommen muss.
  • 44. ä Hero-Culture Freiwillige Überstunden! Retter des Projektes! Das größte Commit(ment)! Kompetenzträger Nr. 1! aka „Engpass mit Ohren“ Informale Seite zB wenn man eine Hero-Culture hat. Wir haben das lange Jahre gemacht, schliesslich kommen wir vom OpenSource. Und vom Standpunkt des Vorgesetzten aus klingt das natürlich super. Diese Kollegen machen freiwillig Überstunden. Und nicht nur das - sie haben das Projekt schon mehrfach gerettet. Und natürlich kommen von Ihnen deutlich mehr Commits als von den anderen. Denn sie haben am meisten Kompetenz. So viel, dass sie oft die Kollegen darum bitten, bestimmte Code-Stellen nicht anzufassen, weil sie die einzigen sind, die das nötige Knowhow mitbringen.
  • 45. ä Hero-Culture Wer macht die Architektur, 
 wenn nur einer das nötige Wissen hat? Matthäus-Effekt: Zu Knowhow 
 kommt mehr Knowhow Informale Seite Im Resultat macht der Hero auch oft die Architektur. Er sitzt auf dem Wissen, lässt andere nicht daran teilhaben. Tribal Leadership nennt das Level 2, konkret „I am great, you are not“
  • 46. ä Hero-Culture Die Kompetenz der Kollegen fehlt - in den Architekturentscheidungen - bei der späteren Umsetzung DDD weil eine Person es (fast) kennt. Informale Seite Das resultiert in gleich zwei Dysfunktionen. Zum einen können die Kollegen Ihre Kompetenzen nicht einbringen, zum anderen fehlt ihnen die Umsetzungskompetenz. Wir selbst haben es allen Ernstes fertiggebracht vor Jahren Domain Driven Design eingeführt, ohne dass sich auch nur ein anderer Kollege damit auskannte. Und die Business-Seite, die eigentlich das Domainwissen mitbringen sollte, hat davon nie erfahren. Sie können sich vorstellen, wie gut das funktioniert hat.
  • 47. ä Software Architecture by Blog Reading 1. Ich habe einen Blogartikel dazu gelesen 2. Es klingt interessant. Ich würde es gerne mal probieren. Einarbeiten wäre mühsam. 3. Ich verargumentiere es bei nächster Gelegenheit als optimale Architektur. Für Manager gibt es im Cunningham-Wiki die Bezeichnung „Management by Inflight-Magazine“. Das Pendant unter den Softwarearchitekten ist die Architecture by Blog Reading. Man liest einen Blog-Artikel, findet das Thema interessant, und würde es gerne mal in der Praxis probieren - ohne allerdings nennenswert Einarbeitungsaufwand in das Thema zu stecken. Also wird es bei nächster Gelegenheit als Architekturvorschlag verargumentiert.
  • 48. ä DDD-Lite DDD-Lite is a means of picking and choosing a subset of the DDD tactical patterns, but without giving full attention to discovering, capturing, and enhancing the Ubiquitous Language." Das klingt auf den ersten Blick albern, aber taucht erstaunlich oft in der Praxis auf. Ein Beispiel ist DDD-lite, die Einführung der Tactical Patterns von DDD, ohne dass gemeinsam mit den Nutzern eine Ubiquituous Language oder auch nur ein gemeinsames Domain Model etabliert wäre. Vielleicht liegt es an den vielen Kontakten in der PHP-Welt, aber ich wäre froh, wenn ich ab und zu auch mal ein CQRS und Event-Sourcing-Tupel sehen würde, von dessen Events der User auch wüsste.
  • 49. ä MicroService-Envy „MicroServices sind super! Sie sind einfach! Ich verstehe es! Neue Entwickler müssen weniger lernen! Weniger Abhängigkeiten zu anderen!“ Im ThoughtWorks Technology Radar wird explizit vor MicroService-Envy gewarnt. Weil die eigene Softwarestruktur Probleme mit der Einarbeitung von neuen Personen hat, weil man nicht in der Lage ist ein gutes Continuous Deployment hinzubekommen, weil man seine Abhängigkeiten nicht im Griff hat- deshalb möchte man MicroServices einführen, denn sie versprechen, dass man diese Probleme gelöst bekommt. Dass diese Probleme andere Gründe in der Organisation haben, und oft gar nichts mit der Architektur zu tun haben, das wird dabei gerne übersehen.
  • 50. ä Silver Bullet Es gibt keine einzelne Entwicklung, weder als Technik noch als Managementmethode, die Produktivität, Verlässlichkeit oder Einfachheit um eine Größenordnung verbessert Frederic P Brooks, 1986 Dieses Verhalten ist aber nicht eben neu - 1986 hat Frederic P Brooks ein Whitepaper über „Silver Bullets“ gemacht, mit dem passenden Titel „There are no silver bullets“. Er sagt: Es gibt keine einzelne Entwicklung, weder als Technik noch als Management, die Produktivität, Verlässlichkeit oder Einfachheit um eine Größenordnung verbessert. Trotzdem versuchen wir es immer wieder.
  • 51. ä Silver Bullets - Functional Programming - Artificial Intelligence - NoSQL - Node.JS - React - Domain Driven Design - MicroServices - Docker Typische Silver Bullet der letzten Jahre waren Dinge wie Funktional Programming, NoSQL, Node.JS, React, Domain Driven Design, MicroServices und Docker.
  • 52. ä Silver Bullet Known 
 Unknown Planungsfehlschluss / Planning Fallacy Wenn man sich so ein Silver Bullet anschaut, dann verstehen wir den Nutzen sehr gut, und können uns viele Szenarien ausmalen, in denen wir uns einen Benefit vorstellen können. Was wir aber nicht sehen, und da sind wir wieder bei den unbekannten Unbekannten, sind die Probleme, die Folgekosten - sprich: die Accidental Complexity, die wir uns mit dieser Architektur eingekauft haben. Das geht natürlich nicht nur uns so, sondern allen Menschen, beim Kahneman heisst das als kognitive Verzerrung Planning Fallacy.
  • 53. ä Design emerges. Architecture is a collaboration.
 (Wissen & Folgenabschätzung vergrössern) Build the simplest architecture that can possibly work
 (KISS & YAGNI) When in doubt, code, or model it out
 (Architectural Spikes) Silver Bullets vermeiden Abhilfe für die Planning Fallacy bietet Kooperation. Um so mehr Kollegen beteiligt sind, um so eher erkenne ich zukünftige Obstacles, und um so mehr vergleichbares Erfahrungswissen kann ich einbringen. Das gleiche Ziel verfolgt die Bitte um die einfachste Architektur die funktioniert - daher kommen auch Ansätze wie KISS oder YAGNI. 
 Und natürlich Architectural Spikes, einfach mal auszuprobieren und damit das fehlende Wissen vervollständigen.
  • 54. ä Junior-Teams machen Dunning Kruger Und um so offensichtlicher diese Regeln für den erfahrenen Entwickler sind, um so schwieriger wird ist es für Junior-Teams, damit umzugehen. Und damit meine ich nicht Teams aus Junior-Entwicklern - sondern Teams mit überschaubar viel Erfahrung aus selbst gewählten Architekturen. Gerne immer das gleiche Projekte oder noch nicht so lange aus der Uni.
  • 55. ä Frontend-Guru Backend-Architekt Informale Seite Und nicht nur da geht es auf der Informalen Seite schief. Das gleiche gilt für Kollegen mit deutlich unterschiedlichen Interessenschwerpunkten im agilen Team - zB JavaScript-Hipster und Backend-Engineers. Während der eine grade das vor einem Monat neu eingeführte Framework durch ein neueres, besseres ersetzt, baut der andere das Monitoring für den Mesos-Cluster um.
  • 56. ä Frontend-Tribe Backend-Tribe Informale Seite Und weil die Frontend-Jungs nicht nur gemeinsame Kompetenzen und Themen haben, sondern auch gleiche Interessen, verstehen sie sich gut. Die Backend-Guys sehen das ähnlich. Sie sind unter sich, und froh darüber. Immerhin muss man sich nicht mit Hipstern abgeben, sondern implementieren gerade SMACK
  • 57. ä Frontend-Tribe Backend-TribeWe are great. You are not. Backend-
 Stümper Informale Seite Und schwups hat man wieder ein Szenario aus Tribal Leadership. Weil man die eigenen Themen gut versteht und die eigenen Interessen wie Hintergründe kennt, verlässt man sich im Frontend aufeinander. Im Gegensatz dazu machen die Jungs im Backend Dinge, die man nicht versteht, und die offensichtlich auch wichtige Dinge nicht berücksichtigen.
  • 58. ä Frontend-Team! Backend-Team! 2 Teams Formale Seite Und weil man lieber mit den kompetenten Leuten zusammenarbeit, schlägt man vor, dass man das Team trennt. Uns ist das auch oft beim Wachstum von Teams passiert. 
 Das kann auch implizit passieren. Wir hatten gerade letzte Woche den Fall, wo es eine längere Diskussion gab.
  • 59. 2 Teams Frontend-Layer
 jQuery, AngularJS 1, AngularJS2 Backend-Layer
 jQuery, AngularJS 1, AngularJS2 REST/
 JSON Und, quasi unvermeidlich, hat man einige Zeit später so eine Architektur.
  • 60. ä „Organisationen, die Systeme entwerfen, sind auf Entwürfe festgelegt, welche die Kommunikationsstrukturen dieser Organisationen abbilden.“ Conways Law Dieses Phänomen kennen wir natürlich alle - es handelt sich um Conways Law. Organisationen, die Systeme entwerfen, können nur Systeme erzeugen, die ein Abbild Ihrer Kommunikationsstruktur sind.
  • 61. äCTO Lead Architect Lead Architect Head of QA Senior Architect Senior Developer QA Engineer Developer Developer Operations Guy CEO Vice President Product Product 
 Manager Product Owner Product Designer Organisation Architektur Conways Law Aus der Kommunikation - oder, nach neueren Studien, aus der Organisationsstruktur selbst heraus ergibt sich also die Architektur.
  • 62. Architecture Board Team 1 Team 2 Team 3 CTO Enterprise Service Bus Solution 1 Solution 2 Solution 3 Organisation Architecture Und das hat viele Varianten. zB das 2007 klassische SOA-Setup, das praktisch in der Mitte jeder Architektur-Tapete zu finden war.
  • 63. Incredibly Slow Changes Fast Changes Slow Changes Slow Changes Organisation Architecture Fix it! Architecture Board CTO Und wenn man als Teil von Team 1 etwas ändern musste hatte alles 3 Geschwindigkeiten: Wenn ich es in Team 1 selbst machen konnte war es sehr schnell. Wenn ich dabei auf die Hilfe der anderen Teams angewiesen war ging es zwar langsamer, aber noch ok. Und wenn ich Änderungen im ServiceBus selbst brauchte konnte es beliebig lang dauern, je nachdem, wie viele Meetingtermine im Architecture Board benötigt werden.
  • 64. Customer-Facing Company Company 2 Offshore-Company Organisation Architecture Frontend-Layer Backend-
 Stack Other 
 Backend-
 Stack Eine andere Variante, die uns untergekommen ist: Hinter einem einzigen Portal stehen gleich 3 Firmen: eine ist Customer-Facing, eine ist als IT-Dienstleister vor Ort, und die dritte gehört zwar zur Familie, wohnt aber in einem anderen Land. Im Resultat gibt es zwei konkurrierende Backend-Stocks - und natürlich Politik darüber.
  • 65. ä DevOps zitiert eine weitere Variante von Conways Law - funktional getrenntes Software-Development und Betrieb. Der eine Bereich muss zwar die Software des anderen laufen lassen, hat aber ganz andere Ziele. Und sie verstehen sich nicht.
  • 66. Der Lösungsansatz von DevOps ist deshalb eine Änderung der Arbeitsweise. An die Stelle von funktionaler Trennung tritt die direkte Zusammenarbeit.
  • 67. Dev Ops QA DevOps Prozesse Werkzeuge Leute Ziele
 Verständnis Deshalb fordert DevOps, dass hier die Kommunikation in der Organisation geändert wird. Und man deshalb bei den funktionalen Themen Development, QA und Ops in der Organisation zusammenarbeitet - in gemeinsamen Prozessen, mit gemeinsamen Werkzeugen, mit gemeinsamen Leuten, gemeinsamen Zielen - und, am Ende resultierend - gemeinsamen Verständnis.
  • 68. ä Ich kann also nur die Architektur machen, was meine Organisation Hmm, da fragt man sich natürlich, ob man faktisch überhaupt eine Wahl hatte - oder ob die Organisation zwangsläufig das ergibt, was die Organisation eben erlaubt.
  • 69. ä Inverse Conway Maneuver The 'Inverse Conway Maneuver' recommends evolving your team and organizational structure to promote your desired architecture. Die Jungs von Thoughworks haben deshalb das Inverse Conway Maneuver geschaffen - ich bewege meine Firma und mein Team dorthin, wo ich meine Architektur haben möchte.
  • 70. ä Eine gute Idee erkennt man am einfachsten daran, dass jemand Schlaues sie schon vorher hatte. Und wie immer gilt die goldene Regel: eine schlauere Idee lässt sich am einfachsten daran erkennen, dass jemand anderes sie schon vorher hatte :-)
  • 71. Vice President Product Vice President Development Vice President Quality Vice President Maintenance Product Developer Software Developer Quality 
 Assurance Operator Product Owner Frontend Developer Tester NetSec
 Consultant Product Designer Backend
 Developer Test Infrastructure Performance Consultant CEO Um das mal am Beispiel zu zeigen. Wie schon berichtet ist die Herkunft vieler Unternehmen eine funktionale Organisation, zT auch in der Erweiterung zur Matrix- Organisation.
  • 72. One Department CTO Senior Manager Senior Manager Product Owner Scrum Master Manager Manager Developer Security Expert Head of Something Doing actual Work Senior Developer QA Expert CEO Other Department Software Island Wenn die Unternehmen einen IT-Schwerpunkt haben agile Methoden da meist schon Bewegung reingebracht - und in den IT-Departments gelten andere Regeln. Da gibt es nicht nur Obst, Cola, informelle Kleidung und flexible Arbeitszeiten, sondern auch einen anderen Führungsstil.
  • 73. Vice President Product Vice President Development Vice President Quality Vice President Maintenance Product Developer Software Developer Quality 
 Assurance Operator Product Owner Frontend Developer Tester NetSec
 Consultant Product Designer Backend
 Developer Test Infrastructure Performance Consultant CEO Selbstorganisiertes Team You built it, you run it. MicroServices Microservices erlaben dank der DevOps-Methodenwelt dieses Thema weiter zu führen, denn das selbstorganisierte Team kann jetzt die komplette Strecke - von Produktentwicklung bis zum Betrieb - selbst abbilden. Und wie man sieht steht es damit quasi quer zur funktionalen Organisation.
  • 74. Infrastructure iOS Client UserProfile
 Web Payment 
 Service System Engineer Product Developer Product Developer Product Developer Security Guy Developer Developer Developer Data Scientist System Engineer System Engineer System Engineer CEO MicroService-
 Team MicroService-
 Team Infrastructure- Team MicroService-
 Team Die funktionale Organisation wurde also in eine Themenbezogene gekippt, geschnitten nach Business-Domains.
  • 75. Organisationsstruktur nach Deployment
 + Innovation statt Funktion Und das hat einen ganz interessanten Effekt gebracht. Auf einmal ist nicht mehr die Spezialkompetenz die Schnittkante der Abteilungen, sondern das Deployment. Der altmodische Admin-Task ist auf einmal massgeblich dafür, wie die Firma selbst geschnitten ist.
  • 76. Damit ändert sich die Organisationsstruktur. Und es kommt etwas wie bei Spotify heraus. Ähnliche Modelle findet man auch bei Netflix, bei Valve und vielen anderen. Hier gibt es immerhin noch einen Tribe Lead, der sich jeweils schüchtern an die linke obere Ecke gestellt hat.
  • 77. MicroService-
 Team Infrastructure- Team In der deutschen Diskussion findet man oft das Pfirsichmodell von Unternehmen, dass von Gerhard Wohland definiert wurde und von Niels Pfläging - dem ich hier die Grafik gestohlen habe - popularisiert wurde. Die kleinen Kreise am Rand sind die selbstorganisierten, autonomen Teams, die direkt am Markt lang arbeiten und sich weiterentwickeln. Die Teams in der Mitte bieten diesen Teams Service, liefern zB Development- und andere gemeinsam genutzte Infrastruktur, die Core-Libraries etc.
  • 78. Eine der Organisationsformen mit einem sehr guten Marketing-Department ist Holacracy - hier in einem Screenshot eines Berichtes auf Aljazeera. Diese Form wird also wirklich ernst genommen. Holacracy - oder auf deutsch Holokratie - ist eine der Organisationsformen, die auf Basis von agiler Arbeit entstanden sind.
  • 79. ä Inverse Conway Maneuver Ok, dann machen wir 
 das einfach mal? Ok, und wie komme ich dahin?
  • 80. How to Become a 
 Microservice-Company 
 in 5 Steps 1. Agile Methoden einführen & beherrschen 2. DevOps-Werkzeuge & -Kultur einführen 3. Agile Unternehmenskultur changemanagen 4. Unternehmen restrukturieren 5. Allen Code reengineeren Der Nachteil an der Geschichte ist aber, dass man nur die formale Seite so frei definieren kann.
  • 81. ä VersionOne Report 2016 95% praktizieren agil 1%sind gescheitert Schauen wir uns doch mal an, was typischerweise in den Unternehmen passiert. Eine wenigstens aktuelle Quelle ist der VersionOne Anual State of Agile Report. Die Ergebnisse sind ein bisschen verfälscht, weil sie als Firma mit einem Tool für agile Unternehmen natürlich eher diese ansprechen.
  • 82. ä 46 % Unternehmensphilosophie oder - kultur widerspricht agilen Kernwerten 41 % Fehlende Erfahrung mit 
 agilen Methoden 39 % Fehlende Managementunterstützung 38 % Fehlende Unterstützung bei
 der kulturellen Transition Kernursachen für das Scheitern agiler Projekte 10th State of Agile Report aus 2016.
  • 83. ä 83 % Tägliche Standups 82 % Priorisierter Backlog 59 % Teamschätzung 50 % Continuous Integration 27 % Continuous Deployment Was machen die agilen 95%? 10th State of Agile Report aus 2016.
  • 84. ä Wie lange dauert eine agile Transition? ?Wer befindet sich hier in einer digitalen Transition? Genau, wir machen das auch seit 2005, und haben mehr als 7 Jahre gebraucht, um die Teams wirklich brauchbar aufzustellen.
  • 85. ä 1. Agile Methoden einführen & beherrschen 2. DevOps-Kultur & -Werkzeuge einführen 3. Agile Unternehmenskultur changemanagen 4. Unternehmen restrukturieren 5. Allen Code reengineeren SO YOU MEAN TO TELL ME
 YOU WANT TO DO 
 ALL 5 STEPS 
 BUT YOU CAN’T DO 
 THE 1ST? Und wir brauchen Jahre für den ersten Schritte, scheitern oft - und wollen mal alles schnell machen, weil unsere Wunscharchitektur das braucht?
  • 86. ä Autonome Teams mit 
 dokumentierten Prozessen. Selbstorganisierte Teams 
 mit Architekturverantwortlichem. MicroServices nach einem vorgegebenen Techset „Business Domains“, die 
 das Business nicht kennt Und was, wenn ich es 
 einfach trotzdem mache? Agile MicroService-Teams
 die unnötige Features implementieren Und was passiert, wenn ich es einfach trotzdem mache? Weil ich in einem Blogpost gelesen habe, dass MicroServices so etwas wie ein Silver Bullet sind?
  • 87. ä Okay, ich muss also agil, DevOps und die passenden Kultur haben? Hmm, da fragt man sich natürlich, ob man faktisch überhaupt eine Wahl hatte - oder ob die Organisation zwangsläufig das ergibt, was die Organisation eben erlaubt.
  • 88. Warum nicht schon 1980?! Aber noch etwas anderes ist bei DevOps passiert. Hätte man denn nicht schon deutlich vorher auf DevOps kommen können? Warum ist Flickr da erst 2009 drauf gekommen?
  • 89. Schauen wir doch mal direkt in den Talk von 2009 hinein, der DevOps in die Popularität gespült hat.
  • 90. Und da ist was spanendes enthalten: sie reden vor allem über Technologie.
  • 91. Hey, das ist ja Architektur. Diese Punkte sind Architektur. Das sind Technologiestacks, die dort eingeführt wurden. Und DevOps ist enstanden, weil jetzt diese Technologie zur Verfügung stand.
  • 92. ä Development Q.A. Operations Continous Integration Infrastructure as Code Shared Version Control Die vorher schwierige Kooperation mit den nachträglich angesetzten Qualitätsverantwortlichen wurde durch eine gemeinsame kontinuierliche Integration zu kooperativer Arbeit. Regressionstests sind automatisch in die CI gefallen, und auf einmal brauchte sich die Q.A. nicht mehr um Wiederkehrerfehler kümmern, und man konnte die eigenen Tests in Code giessen und damit einen guten Stapel Donkey-Work abgeben. Mit Infrastructure as Code gab es eine gemeinsame Basis für Konfiguration, und weil es alles im gemeinsamen Versionsmanagement war, konnten auch die anderen unmittelbar damit arbeiten. Die Änderungen an Infrastruktur sind keine Frage von Produktions-Changes mehr, sondern ein Commit, der bei einer bestimmten Version einfach mit übernommen wird. Automatisiert getestet, versteht sich.
  • 93. „DevOps is just short for DevProductSupportNetSecBizOps. Und da hört es nicht auf. Die DevOps-Community sagt nicht umsonst: DevOps ist just short for DevProductSupportNetSecBizOps.
  • 94. ä Business Analytics Product Development Development Operations Shared Metrics Feature Toggles Dabei spielen insbesondere zwei Dinge eine Rolle: gemeinsame Metriken über alles und Feature Toggles. Die Metriken werden im Regelfall hochtransparent für alle sichtbar gemacht. Resultat ist ein gemeinsames Bild von der Gesamtsituation des eigenen Produktes, und es erlaubt einem gezielt an diesem zu verbessern. Mit guten Metriken und Feature Toggles, also der Fähigkeit verschiedene Produktvarianten im Vergleich durchzumessen, kann auch der Business experimentieren - in Kooperation mit Development, QA, Operations und Business Analytics.
  • 95. Gemeinsam - von Business Development bis Operations Bei uns ist das meist ein ELK-Stack, der alle möglichen Daten auf Vorrat sammelt und es einfach macht, schnell und testweise kleine Experimente durchzuführen.
  • 96. UndCTO Lead Architect Lead Architect Head of QA Senior Architect Senior Developer QA Engineer Developer Developer Operations Guy CEO Vice President Product Product 
 Manager Product Owner Product Designer Organisation Architektur Architektur ist ein Enabler für Organisationsentwicklung. Und damit hat sich genau die andere Richtung gezeigt. Ich kann meine Organisation ändern, indem ich per Architektur neue Optionen und greifbaren Benefit bereitstelle - zB durch schnellere Iterationen in Continuous Deployment, durch die Möglichkeit zur experimentellen Produktentwicklung per Feature Toggles, durch eine gemeinsame Datengetriebene Geschäftssicht über schlaue Metriken.
  • 97. Und Die Organisation bestimmt die Architektur bestimmt die Organisation CTO Lead Architect Lead Architect Head of QA Senior Architect Senior Developer QA Engineer Developer Developer Operations Guy CEO Vice President Product Product 
 Manager Product Owner Product Designer Organisation Architektur Und damit habe ich eine Rückkopplung: Wenn ich die Organisation ändere wirkt das auch auf die Architektur, wenn ich die Architektur ändere wirkt das auf die Organisation.
  • 98. Organisations- Entwicklung Architektur Konvergenz von Architektur und Organisationsentwicklung Im Resultat haben wir eine teilweise Konvergenz von Architektur und Organisationsentwicklung. Und auch davon hat Frederic Brooks natürlich schon geredet, und im Rahmen von MicroServices ist es akut geworden. Es gibt einen schönen (= kurzen) Artikel von Eberhard Wolff von innoQ dazu auf Heise: http://www.heise.de/developer/ artikel/Microservices-Architektur-oder-Organisation-2671835.html
  • 99. ä Also schnell MicroServices und die benötigte Organisationsstruktur parallel einführen? … eher nicht. 1. Agile Methoden einführen & beherrschen 2. DevOps-Kultur & -Werkzeuge einführen 3. Agile Unternehmenskultur changemanagen 4. Unternehmen restrukturieren 5. Allen Code reengineeren Das heisst aber nicht, dass ich eben beides gleichzeitig machen muss damit es funktioniert. Das kann nicht klappen, denn die Voraussetzungen für eine Architektur _und_ eine Organisation _und_ eine Kultur sind sportlich.
  • 100. ä Die Unternehmen mit dem 
 größten Leidensdruck 
 haben auch den 
 weitesten Weg. 1. Agile Methoden einführen & beherrschen 2. DevOps-Kultur & -Werkzeuge einführen 3. Agile Unternehmenskultur changemanagen 4. Unternehmen restrukturieren 5. Allen Code reengineeren Und da steckt noch eine Gemeinheit dahinter - denn genau die Unternehmen, bei denen weder die Architektur, noch die Organisationsform, noch die Kultur stimmt haben den größten Leidensdruck. Da macht die Neugründung oder der Kauf, wie er in einigen Fällen auch hier in Deutschland zu beobachten war, natürlich erheblich Sinn - vorausgesetzt, dass man sich selbst davor schützt, die gekaufte Kultur zu assimilieren - und damit wieder da ist, wo man vorher schon war.
  • 101. ä Evolution Wenn meine Strategie weder Neugründung, noch Kauf oder mittelfristige Insolvenz ist habe ich eine Evolution vor mir, bei der ich jeden Schritt mitgehen muss, um den nächsten jenseits vom Cargo Cult zu erreichen. Und wie geht Evolution? Man probiert so lange Spezies durch, bis sich emergent etwas ergibt, was in meiner Umgebung am besten funktioniert. (Das Bild ist super, und ich habe viele Orte gefunden, an denen es genutzt wird - aber nicht den Ursprünglichen Ort.
  • 102. Prozesse Werkzeuge Leute Ziele
 Verständnis Organisations- Entwicklung Architektur Agil Und netterweise gibt es ein Methodenset, dass solche Dinge emergent entstehen lässt - die agilen Methoden. Ich würde also, frei nach DevOps, erwarten dass der spannende Ort dieser Evolution die gemeinsame Arbeit der agilen Teams, der Organisationsentwicklung und der Architektur ist.
  • 103. ä Die Architektur, die man kann: … ist eine gemeinsame Evolution von • Architektur • Organisationsentwicklung • Team + Firmenkultur Organisations- Entwicklung Architektur Agil Also, die Architektur, die man kann ist also heute die gemeinsame Evolution von Architektur, Organisationsentwicklung und der Team und Firmenkultur
  • 104. ä Autonome Teams mit 
 dokumentierten Prozessen. Selbstorganisierte Teams 
 mit Architekturverantwortlichem. MicroServices nach einem vorgegebenen Techset „Business Domains“, die 
 das Business nicht kennt Agile MicroService-Teams
 die unnötige Features implementieren Wenn ich das nicht gemeinsam mache lande ich in einer Dilbert-Welt, in der die formalen Strukturen und die informalen Strukturen kontinuierlich zu Dysfunktionen führen.
  • 105. How to Become a 
 Microservice-Company 
 in 1 Step 1. Technologie auf 
 MicroServices umstellen 1. Spotify-Modell einführen Aber eins ist zumindest sicher - die Zeiten, in denen wir grosse Architekturen unabhängig von Teams und Organisation gemacht haben, sind vorbei.
  • 106. ä „Jetzt MicroServices?! Wir haben doch nicht
 mal Agil hinbekommen. 
 Geschweige denn DevOps.“ Kritik & Fragen: @johannhartmann hartmann@mayflower.de 
 Slides mit Tonspur: http://slideshare.net/johannhartmann Vielen Dank für Ihr Durchhaltevermögen. Die Idee zu diesem Talk kam übrigens von dem Satz rechts oben, den ein befreundeter Entwickler in einem grösseren Unternehmen zu mir sagte :-)
  • 107. ä Die Architektur, die man kann: Wenn ich kein DevOps kann, 
 kann ich keine MicroServices. Wenn ich eine klassische Hierarchie in der Technik habe, bekomme ich keine autonomen Teams. Wenn ich weder Daten noch Product Development mit im Team habe, kann ich keinen grossen Businessvalue mit MicroServices erzeugen. Wenn ich agil nicht kann, 
 kann ich keine MicroServices. Also, die Architektur, die man kann: