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

1. Bottom-up anstatt Top-down Wie man eine einheitliche Architektur bei vielfältigen Anwendungen lebt Markus Rehrs @spontifixus Dr. Stephan Volmer @stvzeg

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. 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. 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. Aus der Krise in den Aufschwung? Reuse Frameworks Patterns OSS Libraries 2000 3GL 2010 1990 SOA 1980 1970 Software Crisis OOP Components

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. 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. „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. 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. 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. GALAP Bottom-Up APET Wilhelmine Wulff / pixelio.de MAYA DRY KISS Eine pragmatische Herangehensweise

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. Dokumentation Artefacts API-Dokumentation Nachschlagewerk TFS Release-Notes Meeting-Protokolle Wiki Doku Backlog Defects Blog Best-Practices Anleitungen

14. Artefacts Beispiele und Best Practices Beispielapplikation Produktive Applikationen Code Snippets

15. Ein Freies Elektron Process Team 1 Team 4 Senior Developer Team 3 Team 2

16. Entwicklung mit Rückenwind Process Projekt 1 Projekt 4 Blueprint Projekt 3 Projekt 2

17. Gemeinsam Stark Process Regelmäßige Meetings Lebhafte Kommunikation Gegenseitige Reviews GROSSPROJEKT Spaßprojekt miniprojekt P kleinprojekt PROJEKT Y

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. Schulungen Empowering Einstieg Einführung Beispiele Praxis Fragerunde Begeisterung

20. Empowering Learning by Doing

21. Tools Entwicklungsumgebung Entwicklungsumgebung und Versionsverwaltung Lokales NuGet-Repository IDE Extensions von Drittanbietern und Eigenentwicklungen Tools zur statischen Codeanalyse

22. Tools Weitere Resourcen Effiziente Infrastruktur Identische Arbeitsplätze Starter-Kit

23. Ein Basis-Check vor dem Start Zeit Geld Wille Eignung geprüft

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. 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. Schlüsselfaktor Zusammenarbeit Menschen Projekte Projekte Blueprint

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. Das Vorgehen Am Anfang steht ein Inkubatorprojekt Inkubator Inkubator Blueprint Projekt B

29. Das Vorgehen Generalize as Late as Possible Projekt Inkubator.Next Inkubator Blueprint Projekt B Projekt B

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. 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. Markus Rehrs markus.rehrs@zuehlke.com xing.to/mrehrs twitter @spontifixus Dr. Stephan Volmer stephan.volmer@zuehlke.com xing.to/stv twitter @stvzeg

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

Estás leyendo una previsualización.

Eche un vistazo a continuación

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

Más Contenido Relacionado

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

Más reciente (20)