Bottom-up anstatt
Top-down
Wie man eine einheitliche
Architektur bei vielfältigen
Anwendungen lebt

Markus Rehrs
@spontifi...
Eigentlich nichts Neues

Aufgabe

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

Reuse

“If we were to write all the code of a software,
we would write a certain amount of code.”...
Die Realität sieht anders aus…

Reuse

“There is the time it takes to specify what the software should do.”
“Multiply that...
Aus der Krise in den Aufschwung?

Reuse

Frameworks
Patterns

OSS

Libraries
2000

3GL

2010

1990
SOA

1980
1970
Software...
Reuse

Irrtümer, Fakten und Konsequenzen
“Writing code is the primary activity in getting a
system done!
“All code takes t...
Reuse

Kosten und Nutzen

Kann Ihr Unternehmen sich
wiederverwendbaren Quellcode
leisten?
“Developing reusable code costs ...
„Was tun?“ spricht Zeus

Reuse

?

Should we not reuse?

•

There are genuine situations were reuse is the
right answer.

...
Reuse

Schwarz oder Weiß?

Jedes Projekt wählt
Architektur und
Technologie unabhängig
von der umgebenden ITLandschaft.
che...
Reuse

Schwarz oder Weiß?

Ein Framework-Projekt
verschlingt viele
Ressourcen ohnen einen
direkten Mehrwert zu
liefern.
ch...
GALAP

Bottom-Up
APET

Wilhelmine Wulff / pixelio.de

MAYA

DRY

KISS

Eine pragmatische Herangehensweise
Libraries und Templates

Artefacts
Quellcode

Eigene VisualStudio Solution
NuGet-Pakete zur Einbindung externer
Komponente...
Dokumentation

Artefacts
API-Dokumentation
Nachschlagewerk

TFS

Release-Notes
Meeting-Protokolle

Wiki

Doku

Backlog
Def...
Artefacts

Beispiele und Best Practices

Beispielapplikation

Produktive
Applikationen

Code Snippets
Ein Freies Elektron

Process

Team 1

Team 4

Senior
Developer

Team 3

Team 2
Entwicklung mit Rückenwind

Process

Projekt 1

Projekt 4

Blueprint

Projekt 3

Projekt 2
Gemeinsam Stark

Process
Regelmäßige
Meetings

Lebhafte
Kommunikation

Gegenseitige
Reviews

GROSSPROJEKT

Spaßprojekt
min...
Semantische Versionierung

Process

Major

Minor

Revision

•

Breaking
Changes

•

Keine Breaking
Changes

•

Keine Break...
Schulungen

Empowering
Einstieg
Einführung

Beispiele
Praxis
Fragerunde
Begeisterung
Empowering

Learning by Doing
Tools

Entwicklungsumgebung

Entwicklungsumgebung und Versionsverwaltung

Lokales NuGet-Repository

IDE Extensions von Dri...
Tools

Weitere Resourcen

Effiziente
Infrastruktur
Identische
Arbeitsplätze
Starter-Kit
Ein Basis-Check vor dem Start

Zeit

Geld
Wille

Eignung geprüft
Wo ein Wille ist...

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

...ist auch ein Unwilliger

Ich h...
Wo ein Wille ist...

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

...ist auch ein Weg

Ihr hat mich...
Schlüsselfaktor Zusammenarbeit

Menschen

Projekte

Projekte
Blueprint
Thomas Alva Edison

“I readily absorb ideas
from every source,
frequently starting where
the last person left off.”

Libra...
Das Vorgehen

Am Anfang steht ein Inkubatorprojekt
Inkubator
Inkubator

Blueprint

Projekt B
Das Vorgehen

Generalize as Late as Possible
Projekt Inkubator.Next

Inkubator

Blueprint

Projekt B

Projekt B
Aus Erfahrung gut!

Conclusions
•

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

•

...
Langer Atem zahlt sich aus

Conclusions
•

Ein Framework ist nicht kostenlos:
Ohne kontinuierliches Budget für das “freie
...
Markus Rehrs
markus.rehrs@zuehlke.com
xing.to/mrehrs
twitter @spontifixus

Dr. Stephan Volmer
stephan.volmer@zuehlke.com
x...
Nächste SlideShare
Wird geladen in …5
×

Bottom-up anstatt Top-down: Wie man eine einheitliche Architektur bei vielfältigen Anwendungen lebt - Vortrag TeamConf 27.11.2013

584 Aufrufe

Veröffentlicht am

Ein bekanntes Szenario in IT-Abteilungen größerer Unternehmen ist die Entwicklung vieler fachlich unterschiedlicher Applikationen auf einer gemeinsamen technischen Basis. Im Lebenszyklus dieser Applikationen sind oft unterschiedliche Teams für Entwicklung und Wartung zuständig. Um dennoch eine effiziente Arbeit gewährleisten zu können, werden die Applikationen gerne auf ein Framework aufgesetzt, das vor Beginn der eigentlichen Applikationsentwicklung in einem eigenen Projekt erstellt wird. Solche Projekte sind teuer und zeitaufwändig. Sie erzeugen keinen direkten Mehrwert für das Geschäft des Unternehmens. Außerdem besteht die Gefahr, dass sie den tatsächlichen Anforderungen bei der Entwicklung der eigentlichen Applikationen nicht gerecht werden.

Ein anderer Ansatz ist es, aus der Entwicklung einer oder mehrerer Geschäftsapplikationen inkrementell-iterativ wiederverwendbare Artefakte in Form eines Architektur-Baukastens zu erzeugen. Der Vortrag zeigt, wie sich mit dieser Vorgehensweise die Ramp-Up-Zeit für neue Projekte von fünf Monaten auf fünf Minuten verkürzen lässt. Sie wissen nach dem Vortrag wie das geht!

Veröffentlicht in: Technologie
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
584
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
7
Aktionen
Geteilt
0
Downloads
4
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Bottom-up anstatt Top-down: Wie man eine einheitliche Architektur bei vielfältigen Anwendungen lebt - Vortrag TeamConf 27.11.2013

  1. 1. Bottom-up anstatt Top-down Wie man eine einheitliche Architektur bei vielfältigen Anwendungen lebt Markus Rehrs @spontifixus Dr. Stephan Volmer @stvzeg
  2. 2. Eigentlich nichts Neues Aufgabe Einführung einer einheitlichen Architektur für vielfältige Line-of-Business 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 • IMG_1080.jpg by Tom Page http://www.flickr.com/photos/tompagenet/6851860996/ Datengetriebene Anwendungen Entwickler erfinden das Rad immer wieder aufs Neue
  3. 3. Die vermeintliche Logik Reuse “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!” Don't forget to recycle! by James Wang http://www.flickr.com/photos/10037058@N08/3696670712/
  4. 4. Die Realität sieht anders aus… Reuse “There is the time it takes to specify what the software should do.” “Multiply that by the time it takes to understand what the software should do.” “There is the time it takes to write the code.” “Multiply that by the time it takes to integrate with all other code, libraries, components, frameworks, databases, services, …” Debugging! Deploying! Testing! Stabilizing! Workshops! Meetings! Abandoned Boat by William Warby http://www.flickr.com/photos/wwarby/4859138371/
  5. 5. Aus der Krise in den Aufschwung? Reuse Frameworks Patterns OSS Libraries 2000 3GL 2010 1990 SOA 1980 1970 Software Crisis OOP Components
  6. 6. 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!” Shiny gold bar reflecting coins by Bullion Vault http://www.flickr.com/photos/bullionvault/3591732069/
  7. 7. Reuse Kosten und Nutzen Kann Ihr Unternehmen sich wiederverwendbaren 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. Please pay this amount by miguelb http://www.flickr.com/photos/mig/8689212/ Reuse Myth - Can You Afford Reusable Code? Allen Kelly
  8. 8. „Was tun?“ spricht Zeus Reuse ? Should we not reuse? • There are genuine situations were reuse is the right answer. ! Look back, not forward! • • Bottom-up instead of top-down! • Rear view mirror by a.dombrowski http://www.flickr.com/photos/adombrowski/5285377223/ Don’t plan for reuse, but look for opportunities! Simplicity before generality!
  9. 9. Reuse Schwarz oder Weiß? Jedes Projekt wählt Architektur und Technologie unabhängig von der umgebenden ITLandschaft. chess set by Ekkehard Streit http://www.flickr.com/photos/ekkionline/8846737835/
  10. 10. Reuse Schwarz oder Weiß? Ein Framework-Projekt verschlingt viele Ressourcen ohnen einen direkten Mehrwert zu liefern. chess set by Ekkehard Streit http://www.flickr.com/photos/ekkionline/8846737835/
  11. 11. GALAP Bottom-Up APET Wilhelmine Wulff / pixelio.de MAYA DRY KISS Eine pragmatische Herangehensweise
  12. 12. Libraries und Templates Artefacts 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
  13. 13. Dokumentation Artefacts API-Dokumentation Nachschlagewerk TFS Release-Notes Meeting-Protokolle Wiki Doku Backlog Defects Blog Best-Practices Anleitungen
  14. 14. Artefacts Beispiele und Best Practices Beispielapplikation Produktive Applikationen Code Snippets
  15. 15. Ein Freies Elektron Process Team 1 Team 4 Senior Developer Team 3 Team 2
  16. 16. Entwicklung mit Rückenwind Process Projekt 1 Projekt 4 Blueprint Projekt 3 Projekt 2
  17. 17. Gemeinsam Stark Process Regelmäßige Meetings Lebhafte Kommunikation Gegenseitige Reviews GROSSPROJEKT Spaßprojekt miniprojekt P kleinprojekt PROJEKT Y
  18. 18. Semantische Versionierung Process Major Minor Revision • Breaking Changes • Keine Breaking Changes • Keine Breaking Changes • Wesentliche Veränderungen • Neue Features • • Alte Versionen werden weiter unterstützt Bugfixes und kleinere Features
  19. 19. Schulungen Empowering Einstieg Einführung Beispiele Praxis Fragerunde Begeisterung
  20. 20. Empowering Learning by Doing
  21. 21. Tools Entwicklungsumgebung Entwicklungsumgebung und Versionsverwaltung Lokales NuGet-Repository IDE Extensions von Drittanbietern und Eigenentwicklungen Tools zur statischen Codeanalyse
  22. 22. Tools Weitere Resourcen Effiziente Infrastruktur Identische Arbeitsplätze Starter-Kit
  23. 23. Ein Basis-Check vor dem Start Zeit Geld Wille Eignung geprüft
  24. 24. Wo ein Wille ist... Ich möchte lernen wie ich effektiver und effizenter arbeiten kann! ...ist auch ein Unwilliger Ich hab das schon immer so gemacht!
  25. 25. Wo ein Wille ist... Ich möchte lernen wie ich effektiver und effizenter arbeiten kann! ...ist auch ein Weg Ihr hat mich überzeugt! Da bin ich dabei!
  26. 26. Schlüsselfaktor Zusammenarbeit Menschen Projekte Projekte Blueprint
  27. 27. Thomas Alva Edison “I readily absorb ideas from every source, frequently starting where the last person left off.” Library of Congress, Digital ID: cph.3c05139
  28. 28. Das Vorgehen Am Anfang steht ein Inkubatorprojekt Inkubator Inkubator Blueprint Projekt B
  29. 29. Das Vorgehen Generalize as Late as Possible Projekt Inkubator.Next Inkubator Blueprint Projekt B Projekt B
  30. 30. 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 Tellerrand zu schauen! • Investiere in Ausbildung, nicht in Code: Das Know-How der Mitarbeiter ist bares Geld wert!
  31. 31. Langer Atem zahlt sich aus Conclusions • Ein Framework ist nicht kostenlos: Ohne kontinuierliches Budget für das “freie Elektron” läuft das Framework Gefahr ins Koma zu fallen. • Unmittelbarer Return on Invest: Die Ramp-Up-Zeit für neue Projekte reduziert sich von fünf Monaten auf fünf Minuten! • Projektkosten sind besser planbar: Die Entwickler können sich auf die Implementierung der fachlichen Anforderungen konzentrieren. Achtung: Erfolg nicht ausgeschlossen!
  32. 32. Markus Rehrs markus.rehrs@zuehlke.com xing.to/mrehrs twitter @spontifixus Dr. Stephan Volmer stephan.volmer@zuehlke.com xing.to/stv twitter @stvzeg

×