Bottom-up anstatt Top-down: Wie man eine einheitliche Architektur bei vielfältigen Anwendungen lebt - Vortrag TeamConf 27.11.2013
•
1 recomendación•1,106 vistas
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!
Recomendados
Más contenido relacionado
Similar a Bottom-up anstatt Top-down: Wie man eine einheitliche Architektur bei vielfältigen Anwendungen lebt - Vortrag TeamConf 27.11.2013
Similar a Bottom-up anstatt Top-down: Wie man eine einheitliche Architektur bei vielfältigen Anwendungen lebt - Vortrag TeamConf 27.11.2013 (20)
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
- 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
- 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
- 21. Tools Entwicklungsumgebung Entwicklungsumgebung und Versionsverwaltung Lokales NuGet-Repository IDE Extensions von Drittanbietern und Eigenentwicklungen Tools zur statischen Codeanalyse
- 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!
- 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