Bottom-up anstattTop-down

Wie man eine einheitliche Architektur bei vielfältigen

Anwendungen lebt

Markus Rehrs@spontifixus

Dr. Stephan Volmer@stvzeg

Eigentlich nichts NeuesAufgabe

Einführung einer einheitlichen Architektur für vielfältige Line-of-Business Anwendungen:

• Datengetriebene Anwendungen

• Datenbank ist die zentrale Komponente

• Hohe Test- und Integrationsaufwände

• Development und Operations sind organisatorisch getrennte Einheiten

• Hoher Anteil von externen Mitarbeitern

• Heterogener Technologiestack

• Entwickler erfinden das Rad immer wieder aufs Neue

IMG_1080.jpg by Tom Pagehttp://www.flickr.com/photos/tompagenet/6851860996/

Die vermeintliche LogikReuse

Don't forget to recycle! by James Wanghttp://www.flickr.com/photos/10037058@N08/3696670712/

“If we were to write all the code of a software, we would write a certain amount of code.”

“If we could reuse some code from somewhere else that was written before, we could write less code.”

“The more code we can reuse, the less code we write.”

“The less code we write, the sooner we will be done.”

“Get done faster!”

Reuse Die Realität sieht anders aus…

“There is the time it takes to specify what the software should do.”

Abandoned Boat by William Warbyhttp://www.flickr.com/photos/wwarby/4859138371/

“There is the time it takes to write the code.”

“Multiply that by the time it takes to understand what the software should do.”

“Multiply that by the time it takes to integrate with all other code, libraries, components, frameworks, databases, services, …”

Testing! Debugging! Deploying!Stabilizing!

Meetings!Workshops!

1970

1980

19902000

2010

Software Crisis

3GL

OOP

Libraries

OSS

Components

SOA

FrameworksPatterns

Reuse Aus der Krise in den Aufschwung?

Shiny gold bar reflecting coins by Bullion Vaulthttp://www.flickr.com/photos/bullionvault/3591732069/

Reuse Irrtümer, Fakten und Konsequenzen

“Writing code is the primary activity in getting a system done!

“All code takes the same amount to write!”

“If we just reused more code, everything would be better.“

“Code by itself is reusable anyway.”

“In order to be reused, code must be generic, flexible, and replaceable.”

“Code must be specifically designed for reuse!”

“Reusable code is well over-engineered!”

Reuse Kosten und Nutzen

Please pay this amount by miguelbhttp://www.flickr.com/photos/mig/8689212/

Kann Ihr Unternehmen sichwiederverwendbaren Quellcode

leisten?

“Developing reusable code costs three times as much as single use code”

The Mythical Man Month and Other Essays on Software Engineering, Frederick P. Brooks Jr.

“Development teams which write reusable code waste their organizations a lot of time and money.

Reuse Myth - Can You Afford Reusable Code?Allen Kelly

!

?

Rear view mirror by a.dombrowskihttp://www.flickr.com/photos/adombrowski/5285377223/

Reuse „Was tun?“ spricht Zeus

Should we not reuse?

• There are genuine situations were reuse is the right answer.

Look back, not forward!

• Don’t plan for reuse, but look for opportunities!

• Bottom-up instead of top-down!

• Simplicity before generality!

Reuse Schwarz oder Weiß?

chess set by Ekkehard Streithttp://www.flickr.com/photos/ekkionline/8846737835/

Jedes Projekt wähltArchitektur und

Technologie unabhängigvon der umgebenden IT-

Landschaft.

Reuse Schwarz oder Weiß?

Ein Framework-Projektverschlingt viele

Ressourcen ohnen einendirekten Mehrwert zu

liefern.

chess set by Ekkehard Streithttp://www.flickr.com/photos/ekkionline/8846737835/

Eine pragmatische Herangehensweise

KISS

DRY

APET

MAYA

Bottom-Up

GALAP

Wilhelmine Wulff / pixelio.de

Quellcode

� Eigene VisualStudio Solution� NuGet-Pakete zur Einbindung externer

Komponenten

NuGet-Pakete

� Klar umrissene Funktionalität� Bereitstellung externer Komponenten über

eigene Pakete

VisualStudio-Templates

� Project-Template für die Applikation� Item-Templates für die einzelnen

Komponenten

Artefacts Libraries und Templates

� API-Dokumentation� Nachschlagewerk

Doku

TFS

Blog

Wiki

� Backlog� Defects

� Release-Notes� Meeting-Protokolle

� Best-Practices� Anleitungen

Artefacts Dokumentation

Beispielapplikation

ProduktiveApplikationen

Code Snippets

Artefacts Beispiele und Best Practices

Process Ein Freies Elektron

Senior Developer

Team 1

Team 2

Team 3

Team 4

Process Entwicklung mit Rückenwind

Blueprint

Projekt 1

Projekt 2

Projekt 3

Projekt 4 Blueprint

Projekt 1

Projekt 2

Projekt 3

Projekt 4

Process Gemeinsam Stark

miniprojekt

SpaßprojektGROSSPROJEKT

P

PROJEKT Ykleinprojekt

RegelmäßigeMeetings

LebhafteKommunikation

GegenseitigeReviews

miniprojekt

SpaßprojektGROSSPROJEKT

P

PROJEKT Ykleinprojekt

RegelmäßigeMeetings

LebhafteKommunikation

GegenseitigeReviews

Process Semantische Versionierung

Major

• Breaking Changes

• WesentlicheVeränderungen

• Alte Versionenwerden weiterunterstützt

Minor

• Keine Breaking Changes

• Neue Features

Revision

• Keine Breaking Changes

• Bugfixes und kleinereFeatures

� �

Empowering Schulungen

Einstieg

Einführung

Beispiele

Praxis

Fragerunde

Begeisterung

Empowering Learning by Doing

Tools

Entwicklungsumgebung und Versionsverwaltung

Lokales NuGet-Repository

IDE Extensions von Drittanbietern und Eigenentwicklungen

Tools zur statischen Codeanalyse

Entwicklungsumgebung

Tools Weitere Resourcen

EffizienteInfrastruktur

IdentischeArbeitsplätze

Starter-Kit

Ein Basis-Check vor dem Start

Wille

ZeitGeld

Eignung geprüft

Ich hab das schon immerso gemacht!

Ich möchte lernen wie ich effektiver und effizenter arbeiten kann!

Wo ein Wille ist... ...ist auch ein Unwilliger

Ich möchte lernen wie ich effektiver und effizenter arbeiten kann!

Wo ein Wille ist...

Ihr hat michüberzeugt! Da bin ich dabei!

...ist auch ein Weg

ProjekteMenschenBlueprint

Projekte

Schlüsselfaktor Zusammenarbeit

“I readily absorb ideas from every source,

frequently starting where the last person left off.”

Library of Congress, Digital ID: cph.3c05139

Thomas Alva Edison

Das Vorgehen Am Anfang steht ein Inkubatorprojekt

Inkubator

Projekt B

Blueprint

Inkubator

Projekt B

Blueprint

Das Vorgehen Generalize as Late as Possible

Projekt B

Inkubator

Projekt B

Blueprint

Projekt Inkubator.Next

Aus Erfahrung gut!Conclusions

• Starte mit einem echten Projekt:Bottom-up anstatt Top-down funktioniert wirklich!

• Plane kein Framework:Es entsteht im Laufe der Zeit von selbst!

• Halte Dich an Prinzipien:Aber: Pragmatismus anstelle von Religion!

• Setze Ziele jenseits eines Projektes:Die Kollegen werden lernen über den Tellerrandzu schauen!

• Investiere in Ausbildung, nicht in Code:Das Know-How der Mitarbeiter ist bares Geld wert!

Langer Atem zahlt sich ausConclusions

Achtung:Erfolg nicht ausgeschlossen!

• Ein Framework ist nicht kostenlos:Ohne kontinuierliches Budget für das “freieElektron” läuft das Framework Gefahr ins Koma zufallen.

• Unmittelbarer Return on Invest:Die Ramp-Up-Zeit für neue Projekte reduziert sichvon fünf Monaten auf fünf Minuten!

• Projektkosten sind besser planbar:Die Entwickler können sich auf die Implementierung der fachlichen Anforderungenkonzentrieren.

Markus Rehrsmarkus.rehrs@zuehlke.comxing.to/mrehrstwitter @spontifixus

Dr. Stephan Volmerstephan.volmer@zuehlke.comxing.to/stvtwitter @stvzeg