Lean Architecture Ramon Anger Dresden, 04.01.2012 Zum Kennenlernen Ego Technischer Architekt bei Capgemini davor debis, T-Systems, TomTom, Materna als Entwickler, Architekt, Teamleiter, Technischer Projektleiter, Technischer Consultant, Head of Development Diplominformatiker (FH) Master of Computer Science (M. Comp. Sc.) Java BlackBelt (knowledgeblackbelt.com) Aktueller Kunde Bundesagentur für Arbeit (BA) Technischer Architekt bei ALLEGRO davor ELENA, ALGII, Architekturhandbuch, ITIL2010 Projektgröße zwischen 15 und 170 MA 2011 Capgemini. All rights reserved. 2 2010 Capgemini. All rights reserved. 1
Show hands Show hands Studiengang Semester Softwarearchitektur Lean Lean Architecture Wasserfallmodell Scrum 2011 Capgemini. All rights reserved. 3 Show Hands Umgang mit Fragen sofort am Ende 2011 Capgemini. All rights reserved. 4 2010 Capgemini. All rights reserved. 2
Die Begriffe Was ist SW-Architektur? viele Definitionen beschreibt Softwarekomponenten und deren Beziehungen untereinander, so dass ihre Realisierung Anforderungen angemessen erfüllt [BOEHM04] 2011 Capgemini. All rights reserved. 5 Die Begriffe Was ist gute SW-Architektur? minimiert den Aufwand, um Software zu erzeugen, anzupassen und zu warten, während die Software ein akzeptables Laufzeitverhalten aufweist [SHORE06] Wie kommt man zu guter Softwarearchitektur? Es war einmal 2011 Capgemini. All rights reserved. 6 2010 Capgemini. All rights reserved. 3
Plangetriebene Vorgehensmodelle Die Ausgangssituation 1997 Diplominformatiker (FH) Systementwickler in IT-Systemhaus Das erste Projekt Entwurf einer Kfz-Briefverwaltung auf Basis vollständig vorliegender fachlicher und technischer Anforderungen im Team mit vier Kollegen Konzept ca. 45 Seiten Wasserfallmodell, Big Front-Up Design (BFUD) 2011 Capgemini. All rights reserved. 7 Plangetriebene Vorgehensmodelle Das Projektergebnis Projekt war irgendwie erfolgreich Entwurf war fehlerhaft Anforderungen waren unvollständig / falsch Anforderungen wurden während der Umsetzung verändert Architekturanforderungen waren schwer ableitbar Die Retrospektive fehlende Erfahrung unvollständige und veränderte Anforderungen fehlende Flexibilität des Entwurfs etwa 60% Funktionalität wurde nicht benutzt Dokumentation/Handbuch wurde nicht gelesen 2011 Capgemini. All rights reserved. 8 2010 Capgemini. All rights reserved. 4
Plangetriebene Vorgehensmodelle Der Lerneffekt Anforderungen vollständig erfassen wichtige / unwichtige Anforderungen identifizieren Anforderungen mit Einfluss auf Architektur identifizieren Entwurf flexibel gestalten, um auf sich verändernde Anforderungen reagieren zu können Verwendung der Dokumentation klären 2011 Capgemini. All rights reserved. 9 Plangetriebene Vorgehensmodelle Das zweite Projekt Entwurf einer Software zur Patientenverwaltung auf Basis vollständiger Anforderungen im Team mit vier Kollegen Konzept 60 Seiten Wasserfallmodell, Big Front-up design Erfahrungen aus dem Vorprojekt Anwendung der Erfahrungen aus dem ersten Projekt Anforderungen hinterfragen Wirklich vollständig? Wirklich notwendig? Entwurf flexibel gestalten Konfigurierbarkeit / Erweiterbarkeit berücksichtigen 2011 Capgemini. All rights reserved. 10 2010 Capgemini. All rights reserved. 5
Plangetriebene Vorgehensmodelle Das Projektergebnis Projekt war irgendwie erfolgreich Anforderungen waren unvollständig / falsch Anforderungen wurden während der Umsetzung verändert Entwurf nicht flexibel genug, um auf Änderungen reagieren zu können Architekturanforderungen waren schwer ableitbar Die Retrospektive immer noch fehlende Erfahrung Entwurf war besser, aber nicht flexibel genug Flexibilität an den falschen Stellen etwa 50% Funktionalität wurde nicht benutzt Dokumentation/Handbuch wurde kaum benutzt 2011 Capgemini. All rights reserved. 11 Plangetriebene Vorgehensmodelle Der Lerneffekt wichtige von unwichtigen Anforderungen trennen Anforderungen identifizieren, die Einfluss auf Architektur haben Entwurf an den richtigen Stellen flexibel gestalten 2011 Capgemini. All rights reserved. 12 2010 Capgemini. All rights reserved. 6
Plangetriebene Vorgehensmodelle Das n-te Projekt Entwurf eines satellitengestützten Mautsystems Konzept etwa 2000 Seiten Wasserfallmodell, Big Front-Up Design Erfahrungen aus n-1 Vorprojekten Anwendung der Erfahrungen aus de vorherigen Projekten jede Anforderung hinterfragen Konfigurierbarkeit / Erweiterbarkeit berücksichtigen mit veränderten Anforderungen rechnen 2011 Capgemini. All rights reserved. 13 Plangetriebene Vorgehensmodelle Das Projektergebnis das Projekt war alles, aber nicht erfolgreich viele technische Probleme Inbetriebnahme mit 2 Jahren Verspätung voller Funktionsumfang mit 3 Jahren Verspätung Regressforderungen im Milliardenbereich Schwerer Imageschaden für Auftraggeber und Auftragnehmer Die Retrospektive Konzepte bereits während der Umsetzung veraltet damit auch Architekturentwurf veraltet Veränderung der Umweltbedingungen z.b. zweiter Fahrzeuggeräte-Anbieter misstrauensorientierte Vertragsgestaltung 2011 Capgemini. All rights reserved. 14 2010 Capgemini. All rights reserved. 7
Plangetriebene Vorgehensmodelle Plangetriebene Vorgehensmodelle sind lineare, an Phasen orientierte Verfahren Wasserfall, V-Modell XT, Rational Unified Process (RUP) einfach plan- und überprüfbar effektiv bei stabilen Anforderungen teuer bei Änderungen, Erweiterungen und Fehlern 2011 Capgemini. All rights reserved. 15 Plangetriebene Vorgehensmodelle Analyse Konzept Design Umsetzung Test Betrieb Bildquelle: http://commons.wikimedia.org/wiki/file:fulmer_falls_closeup_3000px.jpg 2011 Capgemini. All rights reserved. 16 2010 Capgemini. All rights reserved. 8
Plangetriebene Vorgehensmodelle 2011 Capgemini. All rights reserved. 17 Plangetriebene Vorgehensmodelle Erkenntnisse aus dem Architekturentwurf (Wasserfall) Anforderungen aus abgeschlossener Konzeptphase weisen nur indirekt auf Architektur hin können unvollständig sein können Fehler enthalten sind schwer eindeutig / widerspruchsfrei beschreibbar sind unter Umständen schnell veraltet und schwer änderbar Entwürfe aus abgeschlossener Designphase basieren auf fehlerhaften, veralteten, mehrdeutigen, unvollständigen Anforderungen transportieren Unzulänglichkeiten aus Vorphasen weiter Software aus abgeschlossener Realisierungsphase transportieren Unzulänglichkeiten aus Vorphasen weiter 2011 Capgemini. All rights reserved. 18 2010 Capgemini. All rights reserved. 9
Plangetriebene Vorgehensmodelle Werkzeuge und Sprachen prägen den Architekturentwurf haben kaum Einfluss auf Qualität der Architektur Beispiel: UML-Tool Versionierung 2011 Capgemini. All rights reserved. 19 Plangetriebene Vorgehensmodelle 2011 Capgemini. All rights reserved. 20 2010 Capgemini. All rights reserved. 10
Plangetriebene Vorgehensmodelle Der Lerneffekt es muss anders gehen es war einmal 2011 Capgemini. All rights reserved. 21 Agile Vorgehensmodelle Es war einmal in einem Scrum-Projekt Entwickler liefern von Sprint zu Sprint weniger Funktionalität, während Anzahl gefundener Fehler steigt entsprechend steigt Aufwand für Fehlerbehebung while (true) { System.out.exclaim( Den Fehler habe ich doch letzte Woche schon behoben!!! ); } 2011 Capgemini. All rights reserved. 22 2010 Capgemini. All rights reserved. 11
Agile Vorgehensmodelle Root Cause Analysis 1. Entwickler liefern immer weniger Funktionalität 2. Entwickler benötigen viel Zeit, um Fehler zu beheben 3. Fehler nicht automatisch verifizierbar - traten durch fehlende Koordination der Versionskontrolle bei mehreren Entwicklern auf 4. keine automatischen Testfälle 2011 Capgemini. All rights reserved. 23 Agile Vorgehensmodelle Bildquelle: http://commons.wikimedia.org/wiki/file:iceberg_1_1997_08_07.jpg 2011 Capgemini. All rights reserved. 24 2010 Capgemini. All rights reserved. 12
Agile Vorgehensmodelle Ursache lag tiefer, als auf ersten Blick ersichtlich Fokus in Scrum liegt auf Geschäftswert keine Ressourcen für Software-Architektur schwierig, Änderungen vorzunehmen, ohne betroffene Teile des Systems zu refaktorisieren neu zu schreiben Refaktorisieren ohne automatische Testfälle führt zu neuen Fehlern Konsequenz unwartbare Software Bildquelle: http://commons.wikimedia.org/wiki/file:iceberg_1_1997_08_07.jpg 2011 Capgemini. All rights reserved. 25 Agile Vorgehensmodelle Anforderungen in Scrum keine Konzeptdokumente User stories beschreiben Funktionalität, die für Benutzer / Käufer der SW von Wert ist [COHN10] Als [Rolle] will ich [Funktionalität], um [Geschäftswert]. Als [Sachbearbeiter] will ich [automatisch über Wiedervorlagen informiert werden], um [keine gesetzlichen Fristen zu verpassen]. Kunde: OK. Kauf ich! 2011 Capgemini. All rights reserved. 26 2010 Capgemini. All rights reserved. 13
Agile Vorgehensmodelle Architektur und Design schaffen keinen Geschäftswert Als [Implementierer] will ich [den Komponentenschnitt der Archivierungsschnittstelle ändern], um [leichter auf Änderungen reagieren zu können]. Kunde: Häh? Kauf ich nicht! Aufwände im Zusammenhang mit Architektur / Design werden versteckt vernachlässigt Technische Schulden resultieren 2011 Capgemini. All rights reserved. 27 Agile Vorgehensmodelle Architektur und Design schaffen keinen Geschäftswert Scrum Management-Methodik für Software-Entwicklung kann gut auf Änderungen reagieren keine Methodik zum Architekturmanagement Certified Scrum Master Training Design Sprint 0 Dauer 1-3 Wochen James Coplien: Don t even think this first sprint can take less than half a year. natürlich in Abhängigkeit vom betroffenen System 2011 Capgemini. All rights reserved. 28 2010 Capgemini. All rights reserved. 14
Agile Vorgehensmodelle Einige Agile Methoden Feature Driven Development (FDD) Behaviour Driven Development (BDD) Test Driven Development (TDD) Scrum Kanban Scrumban Crystal clear Naked Planning Extreme Programming (XP) Pair programming, Continuous integration, User stories, Refactoring, Evolutionary design, Rapid prototyping Agile Methoden unterstützen irgendwie Flexibilität, aber nur beschränkt auf der Ebene der Architektur 2011 Capgemini. All rights reserved. 29 Lean Was ist Lean, Lean Management, Lean Production? während Ölkrise 1973 in Japanischer Automobilindustrie entstanden Förderung der MA Reduktion von Verschwendung Steigerung der Effizienz Beispiel: JIT-Lieferung von Rohmaterial keine Lagerhaltungskosten 2011 Capgemini. All rights reserved. 30 2010 Capgemini. All rights reserved. 15
Lean Was ist Lean Architecture? Schlanke Architektur? Effiziente Architektur? Annäherung über Lean Prinzipien 2011 Capgemini. All rights reserved. 31 Lean Prinzipien 14 Lean Prinzipien Workflow visualisieren Einsatz der richtige Werkzeuge Gleichmäßige Aufgabenverteilung Pull statt Push Wertflussoptimierung Entscheidungen mit langfristigem Fokus treffen Probleme zuerst lösen Menschen und Teams weiterentwickeln Entscheider aus dem Team Selbst kümmern Entscheidungen im Konsens treffen Lean weitertragen Kontinuierliche Verbesserung Regeln gemeinsam definieren 2011 Capgemini. All rights reserved. 32 2010 Capgemini. All rights reserved. 16
Lean Prinzipien Lean Prinzipien generell auf Architektur übertragbar Pull statt Push Architektur nicht vollständig im Voraus beschreiben, sondern nur den Teil, der für aktuelles Problem relevant ist Wertflussoptimierung Softwarelieferung an Kunden in kurzen Lieferzyklen Kundenfeedback fließt in Architekturentwurf ein Probleme zuerst lösen Treten Probleme mit Architektur auf, tieferen Grund suchen 2011 Capgemini. All rights reserved. 33 Lean Prinzipien Lean Prinzipien generell auf Architektur übertragbar Menschen und Teams weiterentwickeln Freiraum, um Methoden, Frameworks und Muster auf Verbesserungspotential für Architektur zu untersuchen Team profitiert davon Entscheidungen im Konsens treffen Architektur ist Dienstleistung für Team Kontinuierliche Verbesserung Architektur ständig hinterfragen und nach Optimierung suchen 2011 Capgemini. All rights reserved. 34 2010 Capgemini. All rights reserved. 17
Lean Prinzipien Architektur ist immer in Vorgehensmodell eingebettet Wie gut unterstützen Vorgehensmodelle Lean Prinzipien? 2011 Capgemini. All rights reserved. 35 Lean Prinzipien Lean Prinzipien auf plangetriebene/agile Methoden übertragbar? Workflow visualisieren Plangetrieben Agil Einsatz der richtige Werkzeuge Gleichmäßige Aufgabenverteilung Pull statt Push Wertflussoptimierung Entscheidungen mit langfristigem Fokus treffen Probleme zuerst lösen Menschen und Teams weiterentwickeln Entscheider aus dem Team Selbst kümmern Entscheidungen im Konsens treffen Lean weitertragen Kontinuierliche Verbesserung Regeln gemeinsam definieren 2011 Capgemini. All rights reserved. 36 2010 Capgemini. All rights reserved. 18
Schlussfolgerungen Schlüsse aus Gegenüberstellung - plangetrieben / agil / lean Plangetriebene Vorgehensmodelle für Anwendung von Lean Prinzipien ungeeignet bei Interaktion zwischen Projektteilnehmern sind klare Regeln vorgegeben Agile Methoden unterstützen Lean Prinzipien wo keine explizite Unterstützung vorliegt, werden Prinzipien nicht behindert 2011 Capgemini. All rights reserved. 37 Schlussfolgerungen Schlüsse aus Gegenüberstellung - Architekturaspekte Agile Methoden können durch Lean Prinzipien Lean Architecture erreichen Voraussetzung: Regeln der Methode in Bezug auf die Architektur um Lean Prinzipien erweitern Bei Plangetriebene Methoden wegen fehlender Unterstützung der Lean Prinzipien nicht denkbar 2011 Capgemini. All rights reserved. 38 2010 Capgemini. All rights reserved. 19
Schlussfolgerungen Schlüsse aus Gegenüberstellung Erweiterung der Regeln Lösung hin zu angemessenen Architekturentwürfen unter Berücksichtigung der Lean Prinzipien liegt nur indirekt zwischen Agilität und plangetriebenen Verfahren Regeln plangetriebener Verfahren müssen aufgeweicht, Regeln agiler Verfahren erweitert werden 2011 Capgemini. All rights reserved. 39 Schlussfolgerungen Plangetriebene Vorgehensmodelle Agile Vorgehensmodelle Erweiterung zur Unterstützung der Lean Prinzipien Ordnung Chaos 2011 Capgemini. All rights reserved. 40 2010 Capgemini. All rights reserved. 20
Schlussfolgerungen Hilfsmittel für Unterstützung der Lean Prinzipien erforderlich Welche Hilfsmittel gibt es, Lean Architecture zu unterstützen? Hilfsmittel meint nicht Werkzeuge und Sprachen! Werkzeuge haben wenig Einfluss 2011 Capgemini. All rights reserved. 41 Schlussfolgerungen Hilfsmittel für Unterstützung der Lean Prinzipien erforderlich Angemessene Prozesse Koevolutionsmodell Identifikation häufig/seltener Änderung Coplien-Methodik YAGNI You Ain t Gonna Need It Angemessene Architekturdokumentation Refactoring, nicht nur im Code 2011 Capgemini. All rights reserved. 42 2010 Capgemini. All rights reserved. 21
Backup Angemessenheit der Geschäftsprozesse 7 13 16 45 Niemals Selten Manchmal Oft Immer 19 Wie häufig werden Features eines Systems durchschnittlich genutzt? [Standish Group 1994] 2011 Capgemini. All rights reserved. 44 2010 Capgemini. All rights reserved. 22
Angemessenheit der Geschäftsprozesse 7 13 16 45 Niemals Selten Manchmal Oft Immer 19 Wie häufig werden Features eines Systems durchschnittlich genutzt? 2011 Capgemini. All rights reserved. 45 Angemessenheit der Geschäftsprozesse Hilfsmittel für Unterstützung der Lean Prinzipien erforderlich zwischen 20 und 36 Prozent der Features wirklich benötigt restliche 64 bis 80 Prozent der Features auf keinen Fall realisieren Komplexität des Systems reduziert sich auf etwa ein Drittel Architektur des betroffenen Systems weniger komplex 2011 Capgemini. All rights reserved. 46 2010 Capgemini. All rights reserved. 23
Koevolutionsmodell Koevolutionsmodell Wasserfall: Problem ermitteln Lösung ermitteln Koevolution von Problem- und Lösungsraum werden parallel weiterentwickelt und tauschen Informationen nähern sich immer weiter an Vertreter Rapid Prototyping XP Divide, Conquer Integrate Scrum inkrementelles Design XP 2011 Capgemini. All rights reserved. 47 Koevolutionsmodell Beschreibung des Problems Problembeschreibung 1 Problembeschreibung 2 Problembeschreibung 3 Prototyp 1 Prototyp 2 Prototyp 3 Entwicklung der Lösung Koevolutionsmodell des Designs nach Maher, Poon und Boulanger von 1996 [BROOKS11, S. 79] 2011 Capgemini. All rights reserved. 48 2010 Capgemini. All rights reserved. 24
Coplien-Methodik Ansatz zur Identifikation von Architektur nach [COPLIEN10] Zwei Sichten auf ein SW-System Was das System kann funktionale Anforderungen (Use cases, User stories) nicht-funktionale Anforderungen (Sicherheit, Performance) Rahmenbedingungen (Zeitrahmen) Was das System ist, also über welche Eigenschaften das SW-System verfügt, um Fähigkeiten (Was das System kann) zu ermöglichen Architektur 2011 Capgemini. All rights reserved. 49 Coplien-Methodik Ansatz zur SW-Partitionierung nach [COPLIEN10] Trennung der Dinge die sich wahrscheinlich häufig ändern die sich wahrscheinlich selten ändern Ansatz zur SW-Partitionierung nach [POPPENDIECK07] komplexe SW-Systeme in Teilsysteme zerlegen, damit parallele Bearbeitung (Team) möglich ist kritische Funktionen (Features) unabhängig bearbeitbar sind ein Layer (z.b. DB-Schicht) ist kein Feature FDD Literatur (SOA-)Service kann Feature sein 2011 Capgemini. All rights reserved. 50 2010 Capgemini. All rights reserved. 25
Coplien-Methodik Welche Teile eines Gebäudes ändern sich eher häufig / selten? 2011 Capgemini. All rights reserved. 51 Coplien-Methodik Welche Teile eines Gebäudes ändern sich eher häufig / selten? Fundament Keller Außenwand Dach Fenster Innenwand Tür Bodenbelag Wasserleitung Stromleitung Schreibtisch Blumentopf 2011 Capgemini. All rights reserved. 52 2010 Capgemini. All rights reserved. 26
Coplien-Methodik Warum Unterscheidung nach häufiger / seltener Änderung? zwischen 40 bis 90 Prozent der Kosten für ein SW-System entstehen, nachdem das SW-System produktiv gegangen ist weil Software verändert wird [POPPENDIECK11] Beispiel ALGII/A2LL Projektstart Herbst 2003 Produktivsetzung im Herbst 2004 Kosten 7,5 Millionen Gesundheitsreform 2007 Kosten für eine SW-Änderung > 15 Millionen Beschluss der BA zur Ablösung von A2LL im Frühjahr 2008 2011 Capgemini. All rights reserved. 53 Coplien-Methodik Warum Unterscheidung nach häufiger / seltener Änderung? aus Retrospektiven Änderbarkeit an den richtigen Stellen einbauen Was ist Software? Teil eines Systems, der sich ändert sonst wäre es Hardware Was ist daran Lean? Änderbarkeit an richtigen Stellen Begrenzung von Änderungsaufwänden 2011 Capgemini. All rights reserved. 54 2010 Capgemini. All rights reserved. 27
Langfristige Kosten YAGNI YAGNI - You ain t gonna need it Always implement things when you actually need them, never when you just foresee that you need them. [CUNNINGHAM10] 60 Prozent aller Software-Funktionalität werden kaum oder gar nicht benutzt baue Dinge nicht auf Vorrat Ist YAGNI auf SW-Architektur anwendbar? nur indirekt Architektur Eigenschaften über die das SW-System verfügt, um Fähigkeiten (Was das System kann) zu ermöglichen Architektur zum spätesten möglichen Zeitpunkt zu implementieren meint nicht Architektur zum spätesten möglichen Zeitpunkt zu planen 2011 Capgemini. All rights reserved. 55 YAGNI YAGNI vs. BFUD YAGNI BUFD Abbildung nach [COPLIEN11] Aufwand für Architektur 2011 Capgemini. All rights reserved. 56 2010 Capgemini. All rights reserved. 28
Kosten Architekturdokumentation Architekturdokumentation ist Beschreibung der Struktur eines Softwaresystems mit Dokumenten und Modellen wichtig für Verständnis des Systems Nachvollziehbarkeit von Entwurfsentscheidungen aufwändig 2011 Capgemini. All rights reserved. 57 Architekturdokumentation Entwicklungsfremde Kosten Gesamtkosten Code Benutzermasken --------------------> Entwicklungskosten Kommunikationskosten Code Benutzermasken Dokumente Diagramme Kosten der Softwareentwicklung [nach LUI08] 2011 Capgemini. All rights reserved. 58 2010 Capgemini. All rights reserved. 29
Architekturdokumentation Architekturdokumentation in dem Umfang erzeugen, für den Bedarf besteht Änderungen mit vertretbarem Aufwand machbar sind lieber keine als eine falsche Dokumentation 2011 Capgemini. All rights reserved. 59 Refactoring Refactoring ist Anpassung der inneren Struktur/des inneren Verhaltens von Software, während äußeres Verhalten unverändert bleibt interne Anpassung der Software erfolgt zur Verbesserung ihres Designs Äußeres Verhalten durch automatische Tests validieren 2011 Capgemini. All rights reserved. 60 2010 Capgemini. All rights reserved. 30
Refactoring Refactoring Beschränkung auf Codeebene greift zu kurz Konsolidierung der Anwendungslandschaft einer Organisation oder Aktualisierung eines Standards als Refactoring interpretierbar Auf dieser Abstraktionsebene ist Testvorgehen schwer erzeugbar Beibehaltung des äußeren Verhaltens muss durch anderes Konstrukt überprüft werden. 2011 Capgemini. All rights reserved. 61 Bei Fragen fragen 2010 Capgemini. All rights reserved. 31
Vielen Dank Quellen BOEHM04: Barry Boehm, Richard Turner - Balancing Agility and Discipline, S. 13, Addison-Wesley, 2004 BROOKS11: Frederick P. Brooks - Erfolgreiches Design, S.79, MITP Heidelberg, 2011 COHN10: Mike Cohn - User Stories, S. 26, MITP Heidelberg, 2010 COPLIEN10: James Coplien - Lean Architecture for Agile Software Development, Wiley, 2010 CUNNINGHAM10: Cunningham & Cunningham - You arent gonna need it, http://c2.com/cgi/wiki?youarentgonnaneedit LUI08: Kim Man Lui, C. C. Chan: Software Development Rhythms: Harmonizing Agile Practices for Synergy; Wiley & Sons, 2008 POPPENDIECK07: Mary & Tom Poppendieck - Implementing Lean Software Development, Addison-Wesley, 2007 SHORE06: James Shore - Quality With a Name, http://jamesshore.com/articles/quality-with-a-name.html, 2006 2011 Capgemini. All rights reserved. 64 2010 Capgemini. All rights reserved. 32
Weiterführende Literatur David J. Anderson: Kanban Evolutionäres Change Management, dpunkt.verlag, 2011 Mike Cohn: Succeeding with Agile - Software Development Using Scrum, Addison-Wesley, 2009 Eliyahu M. Goldratt: Theory of Constraints, North River Press, 1990 Craig Larman, Bas Vodde: Scaling Lean and Agile Development, Addison-Wesley, 2008 Stephen R. Palmer: A Practical Guide to Feature-Driven Development, Prentice Hall, 2002 Mary & Tom Poppendieck: Leading Lean Software Development, Addison-Wesley, 2009 2011 Capgemini. All rights reserved. 65 Wer wir sind Juni 2010 2010 Capgemini. All rights reserved. 33
Capgemini der weltweit größte Dienstleister für Consulting, Technology und Outsourcing mit europäischem Ursprung Geografische Verteilung der Capgemini-Mitarbeiter 1 Nordamerika 7.950 Skandinavien 3.681 GB & Irland 7.844 Zentraleuropa 7.724 Frankreich 19.771 Benelux 11.163 Südeuropa 6.714 Asien/Pazifik 1.830 Lateinamerika 1.661 Indien 22.178 Zusammenarbeit Zusammenarbeit ist das zentrale Element der Capgemini-Philosophie und gleichzeitig die Säule unseres Leistungsangebots. Sie trägt zur Wertschöpfung bei, begrenzt Risiken, optimiert Kapazitäten und richtet die Organisation auf Zielerreichung aus. Wir nennen dies Collaborative Business Experience TM. Servicebereiche Consulting Services (Capgemini Consulting) Technology Services Outsourcing Services Local Professional Services (Sogeti) Globale Sektoren Energy & Utilities, Chemicals Financial Services Manufacturing, Retail & Distribution Public Sector Telecom, Media & Entertainment Fakten 1 8,371 Mrd. EUR Umsatz 90.516 Mitarbeiter weltweit, davon 36.236 im globalen Liefernetzwerk Near- und Offshore Mehr als 300 Standorte in mehr als 30 Ländern Börsennotiert in Paris als Cap Gemini S.A. 1 Stand: 31. Dezember 2009 1/4/2012 2010 Capgemini All rights reserved 67 Mit unseren Services liefern wir unseren Kunden maßgeschneiderte Lösungen nachhaltig, zuverlässig und kostenoptimiert Consulting Services (Capgemini Consulting) Technology Services Strategy and Transformation Consulting Technology Transformation Operations Transformation Business Technology Process Consulting & Package Based Solutions Custom Solution Development Application Management Business Information Management Technology Services Consulting Services Local Professional Services Outsourcing Services Local Professional Services (Sogeti) Business Process Outsourcing Infrastructure Outsourcing Government, Service Desk & Management Software Quality Management & Testing Services Infrastructure Services % des globalen Umsatzes in 2009 Outsourcing Services 1/4/2012 2010 Capgemini All rights reserved 68 2010 Capgemini. All rights reserved. 34
Technology Services steht für leistungsfähige Prozess- und Softwarelösungen, die die Wettbewerbsfähigkeit unserer Kunden erhöhen Kunden Unsere Kunden sind namhafte Unternehmen aller Branchen sowie öffentliche Institutionen, deren Erfolg von anspruchsvollen Prozessund Softwarelösungen abhängt. Ihr Nutzen besteht in erhöhter Wettbewerbsfähigkeit durch Differenzierung bei unternehmenskritischen Lösungen Effizienzverbesserung bestehender Lösungen Leistungsangebot Business Technology Process Consulting & Package Based Solutions Custom Solution Development Application Management Business Information Management Kompetenzen Umsetzungsorientierte Beratung Management komplexer IT-Projekte Software-Engineering Gestaltung anspruchsvoller IT-Architekturen Implementierung von Standardsoftwarepaketen (insbesondere SAP - und Oracle-Pakete) Rightshore Forschung & Innovation Collaborative Business Experience TM Standorte in Deutschland, Österreich, Schweiz Branchen Düsseldorf Köln/Bonn Zürich Frankfurt Walldorf Stuttgart Hamburg Hannover München Berlin Nearshore Wien Wrocław Rightshore -Standorte für die Region Deutschland, Österreich und Schweiz Automotive Energy & Utilities, Chemicals Financial Services Manufacturing, Retail & Distribution Public Sector Telecom, Media & Entertainment Offshore Mumbai Warszawa Bangalore Pune Kolkata Hyderabad Rightshore ist eine eingetragene Marke von Capgemini 1/4/2012 2010 Capgemini All rights reserved 69 www.capgemini.com The information contained in this presentation is proprietary. 2011 Capgemini. All rights reserved 2010 Capgemini. All rights reserved. 35
Forschung und Lehre leben vom Gedankenaustausch, dabei helfen klare Vereinbarungen: Die Inhalte dieser Präsentation (u.a. Texte, Grafiken, Fotos, Logos etc.) sowie die Präsentation selbst sind urheberrechtlich geschützt. Alle Rechte stehen, soweit nicht anders gekennzeichnet, Capgemini zu. Capgemini gestattet ausdrücklich die öffentliche Zugänglichmachung kleiner Teile der Präsentation zu Zwecken der nicht kommerziellen Lehre und Forschung. Jede darüber hinausgehende Nutzung ist nur mit ausdrücklicher, schriftlicher Einwilligung von Capgemini zulässig. Haftungsausschluss Auch wenn diese Präsentation und die damit zusammenhängenden Ergebnisse nach bestem Wissen und sorgfältig erstellt wurden, übernimmt weder Capgemini, noch der/die Autoren, eine Haftung für deren Verwendung. Bei Fragen wenden Sie sich bitte an: Capgemini Deutschland GmbH Ramon Anger Kurfürstendamm 22 10719 Berlin 0151/4025 1902 ramon.anger [at] capgemini.com 2011 Capgemini. All rights reserved. 73 2010 Capgemini. All rights reserved. 36