Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Architektur-Governance: Warum Software "Ordnung" braucht

Architektur-Governance: Warum Software "Ordnung" braucht

Praktische Softwarearchitektur sorgt für hochwertige Systeme - sowohl aus technischer wie aus betriebswirtschaftlicher Sicht.

Im Vortrag zeige ich anhand einiger Beispiele auf, was ohne eine praxisnahe Steuerung ("Governance") von Architekturaufgaben geschehen kann: Von Kostenexplosion bis hin zum User-Experience-Desaster oder zum Ausfall sicherheitskritischer Komponenten...

Anschliessend gebe ich Ihnen praktische Hinweise zu den qualitätsrelevanten Aufgaben von Softwarearchitekten - und wie Sie eine einfache, pragmatische und kosteneffektive Governance dafür aufsetzen können.

Dr. Gernot Starke

January 22, 2015
Tweet

More Decks by Dr. Gernot Starke

Other Decks in Programming

Transcript

  1. Dr.  Gernot  Starke   innoQ  Fellow     Softwarearchitekturen Entwurf,

    Entwicklung, Management Evolution & Modernisierung Training   Mentoring und Coaching Analyse und Optimierung von Entwicklungsprozessen   Reviews, Audits, Retrospektiven +49 177 – 728 2570 [email protected] www.arc42.de
  2. h>ps://www.flickr.com/photos/ntrinkhaus/11204815624   Governance  (von  frz.  gouverner,  „verwalten,  leiten“)    

       Regierungs-­‐  bzw.  Lenkungsform,     Steuerungs-­‐  und  Regelungssystem...    
  3. IST-­‐SituaZon  typischer  IT-­‐Systeme   •  steigende  Kosten  für   – Wartung/Änderung

      – Fehlerbehebung   •  sinkende...   – Zme2Market   – Zufriedenheit  
  4. Ursache  (o()   Unordnung...   h>ps://www.flickr.com/photos/himbeerdoni/8999624546   Sales Frontend Cash

    Management Client Personalization Client Data / Contract User Management National Catalogue Vouchers Rebate and Reduction Cards European Catalogue External Partners Sales Offices Price Management Data Warehouse Marketing & Sales Campaigns Travel Agents API & UI Pricing Engine Sales Backend Legend: Java PHP Python C/C++ Web Server Extensions Pricing Data Store Lisp- ish Cobol Security Extensions PL/ SQL
  5. Ursachen  von  Unordnung   •  pathologische  Heterogenität:   ähnliche  Probleme

     (beliebig)  unterschiedlich  gelöst   •  not-­‐invented-­‐here   (mangelnde  Wiederverwendung)     •  fehlende  Wertschätzung  für  Details   (Hauptsache,  es  läu(...)  
  6. Beispiel:  Lebensmi>el...   Machine Operational Support Sales Support Database Machine

    Sensors Message Queue Legend: COTS C# Data Storage & Reporting Machine Configuration Frontend Machine Configuration Backend 1 2 3 bei  Ausfall:  Schadenhöhe  >10  T€  
  7. Architektur-­‐ Governance  braucht  (1)...   •  Überblick  (top-­‐down)   • 

    Details  (bo>om-­‐up)   •  (wenige)  KPI‘s   •  (kleines)  Architekturteam   •  (wenige  querschni>liche)  Regeln   Qualitäts- ziele Ziel Erklärung ... ... Verteilungssicht Kontextabgrenzung fachlich technisch Bausteinsicht
  8. Bewährt,  Praxisnah,     Open-­‐Source   11. Risiken & techn.

    Schulden ARC42 Architektur-Dokumentation 1. Einführung und Ziele 2. Randbedingungen 3. Kontextabgrenzung 5. Bausteinsicht 6. Laufzeitsicht 7. Verteilungssicht 8. Konzepte 10. Qualitätsszenarien 9. Entwurfsentscheidungen Qualitäts- ziele Ziel Erklärung ... ... Verteilungssicht Kontextabgrenzung 4. Lösungsstrategie fachlich technisch 12. Glossar Bausteinsicht h>p://arc42.de  
  9. arc42    Anwender  (Auszug)   •  Deutsche  Post   • 

    Telekom  AG   •  Bosch   •  Deutsche  Bank   (+  DB-­‐Invest)   •  Lu(hansa   •  RWE   •  diverse  Behörden     (D,  A,  CH)   •  diverse  Versicherungen   •  T-­‐Systems,  ATOS,   CapGemini  
  10. Beispiel  für  „Überblick“   (konkret:  Know-­‐How  Inseln)   Apache  PdfBox

        ca.  70KLoC     Grafik:  So(ware-­‐DiagnosZcs  Studio,     h>p://www.so(warediagnosZcs.com/  
  11. Beispiel  „Android“   (konkret:  Know-­‐How  Inseln)   Android,  ca.  20MLoC

      Grafik:  So(ware-­‐DiagnosZcs  Studio       Grafik:  So(ware-­‐DiagnosZcs  Studio,     h>p://www.so(warediagnosZcs.com/  
  12. Effekte  von  Architektur-­‐Governance*   •  Time-­‐2-­‐Market  RedukZon      

    –  LogisZk-­‐Konzern:  vorher  3-­‐6  Monate,  jetzt  2-­‐6  Wochen   –  So(ware-­‐Hersteller:  vorher  3  Monate,  jetzt  6  Wochen   •  RedukZon  Bug-­‐Fixing  Zeit:   –  CRM-­‐Anbieter:  vorher  14  Tage,  jetzt  2  Tage   •  Vereinfachte  Disponierbarkeit  von  Mitarbeitern   –  Versicherung/Gesundheitswesen:  „free-­‐floaZng“  sta>  „fixed-­‐team“   •  Homogenisierung  benöZgten  Know-­‐Hows   *  Quelle:  Eigene  Kunden/Projekte  seit  2002  
  13. Dr.  Gernot  Starke     [email protected]     h>p://gernotstarke.de  

    h>p://innoq.com     h>ps://www.flickr.com/photos/foto_db/16000636092