Lean Architecture - TU Dresdenst.inf.tu-dresden.de/files/teaching/ws11/ring/Lean Architecture Folien... · •Scrum •Management-Methodik für Software-Entwicklung •kann gut auf

© 2010 Capgemini. All rights reserved. 1

Ramon Anger

Dresden, 04.01.2012

Lean Architecture


Lean-Architecture-2012.pptx

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)

Zum Kennenlernen

Aktueller Kunde – Bundesagentur für Arbeit (BA)

• Technischer Architekt bei ALLEGRO • davor ELENA, ALGII, Architekturhandbuch, ITIL2010 • Projektgröße zwischen 15 und 170 MA




Show hands

• Studiengang • Semester

• Softwarearchitektur • Lean • Lean Architecture • Wasserfallmodell • Scrum

Show hands



Umgang mit Fragen

• sofort • am Ende

Show Hands




Was ist SW-Architektur ?

• viele Definitionen

• beschreibt Softwarekomponenten und deren Beziehungen untereinander, so dass ihre Realisierung Anforderungen angemessen erfüllt [BOEHM04]

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 …

Die Begriffe




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)

Plangetriebene Vorgehensmodelle



Das Projektergebnis

Die Retrospektive

• Projekt war irgendwie erfolgreich • Entwurf war fehlerhaft • Anforderungen waren unvollständig / falsch • Anforderungen wurden während der Umsetzung verändert • Architekturanforderungen waren schwer ableitbar

• 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





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




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





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




Der Lerneffekt

• wichtige von unwichtigen Anforderungen trennen • Anforderungen identifizieren, die Einfluss auf Architektur haben • Entwurf an den richtigen Stellen flexibel gestalten





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




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





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




Bildquelle: http://commons.wikimedia.org/wiki/File:Fulmer_Falls_Closeup_3000px.jpg


Analyse

Konzept

Design

Umsetzung

Test

Betrieb

http://commons.wikimedia.org/wiki/File:Fulmer_Falls_Closeup_3000px.jpg







• 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

Erkenntnisse aus dem Architekturentwurf (Wasserfall)





Werkzeuge und Sprachen

• prägen den Architekturentwurf • haben kaum Einfluss auf Qualität der Architektur

• Beispiel: UML-Tool Versionierung








Der Lerneffekt

• es muss anders gehen

• es war einmal …




• 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!!!“);

}

Es war einmal in einem Scrum-Projekt …

Agile Vorgehensmodelle




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

Root Cause Analysis




Bildquelle: http://commons.wikimedia.org/wiki/File:Iceberg_1_1997_08_07.jpg


http://commons.wikimedia.org/wiki/File:Iceberg_1_1997_08_07.jpg




• 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

Ursache lag tiefer, als auf ersten Blick ersichtlich …




• 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!

Anforderungen in Scrum


http://commons.wikimedia.org/wiki/File:Iceberg_1_1997_08_07.jpg




• 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

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


Architektur und Design schaffen keinen Geschäftswert




• 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


Einige Agile Methoden



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

Lean




Was ist Lean Architecture ?

• Schlanke Architektur ? • Effiziente Architektur ?

• Annäherung über Lean Prinzipien

Lean



• 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

Lean Prinzipien

14 Lean Prinzipien




• 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

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

Lean Prinzipien

Lean Prinzipien generell auf Architektur übertragbar




Lean Prinzipien

Architektur ist immer in Vorgehensmodell eingebettet

• Wie gut unterstützen Vorgehensmodelle Lean Prinzipien ?



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




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



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




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



Schlussfolgerungen

Erweiterung zur Unterstützung der Lean Prinzipien

Chaos Ordnung

Plan-getriebene Vorgehens-modelle

Agile Vorgehens-modelle




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



Schlussfolgerungen


• Angemessene Prozesse • Koevolutionsmodell • Identifikation häufig/seltener Änderung Coplien-Methodik • YAGNI – You Ain„t Gonna Need It • Angemessene Architekturdokumentation • Refactoring, nicht nur im Code


Backup



Angemessenheit der Geschäftsprozesse

45

19

16

13

7

Niemals

Selten

Manchmal

Oft

Immer

Wie häufig werden Features eines Systems durchschnittlich genutzt? [Standish Group 1994]





45

19

16

13

7

Niemals

Selten

Manchmal

Oft

Immer

Wie häufig werden Features eines Systems durchschnittlich genutzt?





• 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




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

Koevolutionsmodell



Koevolutionsmodell

Beschreibung des Problems

Entwicklung der Lösung

Problembeschreibung 1 Problembeschreibung 2 Problembeschreibung 3

Prototyp 1 Prototyp 2 Prototyp 3

Koevolutionsmodell des Designs nach Maher, Poon und Boulanger von 1996

[BROOKS11, S. 79]




Coplien-Methodik

• 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

Ansatz zur Identifikation von Architektur nach [COPLIEN10]



Coplien-Methodik

• Trennung der Dinge • die sich wahrscheinlich häufig ändern • die sich wahrscheinlich selten ändern

Ansatz zur SW-Partitionierung nach [COPLIEN10]

• 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

Ansatz zur SW-Partitionierung nach [POPPENDIECK07]




Coplien-Methodik

Welche Teile eines Gebäudes ändern sich eher häufig / selten ?



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




Coplien-Methodik

• 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

Warum Unterscheidung nach häufiger / seltener Änderung ?



Coplien-Methodik

• aus Retrospektiven • Änderbarkeit an den richtigen Stellen einbauen

• Was ist Software ?

• Teil eines Systems, der sich ändert • sonst wäre es Hardware

Warum Unterscheidung nach häufiger / seltener Änderung ?

• Änderbarkeit an richtigen Stellen Begrenzung von Änderungsaufwänden

Was ist daran Lean ?




YAGNI

• “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

YAGNI - You ain‘t gonna need it



YAGNI

YAGNI vs. BFUD

Aufwand für Architektur

Langfr

istige K

oste

n

Abbildung nach [COPLIEN11]

BUFD YAGNI




Architekturdokumentation

• Beschreibung der Struktur eines Softwaresystems mit Dokumenten und Modellen

• wichtig für • Verständnis des Systems • Nachvollziehbarkeit von Entwurfsentscheidungen

• aufwändig

Architekturdokumentation ist




Code Benutzermasken

Dokumente Diagramme

Ko

sten

Code Benutzermasken --------------------> Entwicklungskosten

Gesamtkosten

Kommunikations-kosten

Entwicklungsfremde Kosten

Kosten der Softwareentwicklung [nach LUI08]





• Bedarf besteht

• Änderungen mit vertretbarem Aufwand machbar sind • lieber keine als eine falsche Dokumentation

Architekturdokumentation in dem Umfang erzeugen, für den



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

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.

Refactoring

Bei Fragen fragen


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

http://c2.com/cgi/wiki?YouArentGonnaNeedIt

http://jamesshore.com/Articles/Quality-With-a-Name.html








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

Wer wir sind

Juni 2010



1/4/2012© 2010 Capgemini – All rights reserved 67

Capgemini – der weltweit größte Dienstleister für Consulting, Technology und Outsourcing mit europäischem Ursprung

Zusammenarbeit Servicebereiche Globale Sektoren

Fakten1

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 ExperienceTM.

• Consulting Services (Capgemini Consulting)

• Technology Services

• Outsourcing Services

• Local Professional Services (Sogeti)

• Energy & Utilities, Chemicals

• Financial Services

• Manufacturing, Retail & Distribution

• Public Sector

• Telecom, Media & Entertainment

• 8,371 Mrd. EUR Umsatz

• 90.516 Mitarbeiter weltweit, davon 36.236 im globalen Liefernetz-werk Near- und Offshore

• Mehr als 300 Standorte in mehr als 30 Ländern

• Börsennotiert in Paris als Cap Gemini S.A.

Nordamerika 7.950

GB & Irland 7.844

Frankreich 19.771

Südeuropa 6.714

Skandinavien 3.681

Zentraleuropa 7.724

Benelux 11.163

Asien/Pazifik 1.830

Lateinamerika 1.661

Indien 22.178

Geografische Verteilung der Capgemini-Mitarbeiter1

1 Stand: 31. Dezember 2009



Mit unseren Services liefern wir unseren Kunden maßgeschneiderte Lösungen – nachhaltig, zuverlässig und kostenoptimiert

% des globalen Umsatzes in 2009

Technology Services

Consulting Services

Local Professional Services

Outsourcing Services

Consulting Services (Capgemini Consulting)

Technology Services

Outsourcing Services

Local Professional Services

(Sogeti)

• Strategy and Transformation Consulting

• Technology Transformation

• Operations Transformation

• Business Technology

• Process Consulting & Package Based Solutions

• Custom Solution Development

• Application Management

• Business Information Management

• Business Process Outsourcing

• Infrastructure Outsourcing

• Government, Service Desk & Management

• Software Quality Management & Testing Services

• Infrastructure Services




Branchen

• Automotive • Energy & Utilities, Chemicals • Financial Services • Manufacturing, Retail & Distribution • Public Sector • Telecom, Media & Entertainment

Technology Services steht für leistungsfähige Prozess- und Softwarelösungen, die die Wettbewerbsfähigkeit unserer Kunden erhöhen

• 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 ExperienceTM

Unsere Kunden sind namhafte Unternehmen aller Branchen sowie öffentliche Institutionen, deren Erfolg von anspruchsvollen Prozess- und Softwarelösungen abhängt. Ihr Nutzen besteht in erhöhter Wettbewerbsfähigkeit durch • Differenzierung bei unternehmenskritischen Lösungen • Effizienzverbesserung bestehender Lösungen

Kunden

Leistungsangebot

• Business Technology • Process Consulting & Package Based Solutions • Custom Solution Development • Application Management • Business Information Management

Standorte in Deutschland, Österreich, Schweiz

Kompetenzen

Rightshore®-Standorte für die Region Deutschland, Österreich und Schweiz

Rightshore® ist eine eingetragene Marke von Capgemini

Wien

Berlin Hannover

Hamburg

Düsseldorf

Köln/Bonn

Stuttgart München

Walldorf

Frankfurt

Offshore

Mumbai

Bangalore

Kolkata

Zürich

Warszawa

Wrocław

Nearshore

Pune

Hyderabad

www.capgemini.com

The information contained in this presentation is proprietary. ©2011 Capgemini. All rights reserved




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

Forschung und Lehre leben vom Gedankenaustausch, dabei helfen klare Vereinbarungen:

Documents

Lean Architecture - TU Dresdenst.inf.tu-dresden.de/files/teaching/ws11/ring/Lean Architecture Folien... · •Scrum •Management-Methodik für Software-Entwicklung •kann gut auf