Managed Evolution

HAUPTBEITRAG / MANAGED EVOLUTION }

Managed EvolutionNachhaltige Weiterentwicklung großer Systeme

Stephan Murer · Carl WormsFrank J. Furrer

Die hohe Abhängigkeitder Unternehmen –und von Banken im

Besonderen – vonInformatiksystemen istbekannt und lässt sich

gelegentlich spektakulärbei grösseren Ausfällen

nachvollziehen.

Weniger bekannt, aberebenfalls von großerBedeutung für diebetroffenen Unterneh-men, sind strategischeFehler bei der Wei-terentwicklung ihresInformatiksystems.Dies gilt speziell für

die Klasse der sehr grossen Informatiksysteme mitsteigender Komplexitätstendenz [7, 8, 16], welche diefolgenden Merkmale haben:

– Grösse: Im Falle der Credit Suisse mehr als 2.800Business-Applikationen, mehr als 100.000.000Zeilen Code, weltweit auf über 100 Standorteverteilt;

– Hohe Integration: Eng gekoppeltes Netzwerk vonFunktionen, wie es beispielsweise in großenBanken für die Echtzeit-Integration ihrerRisikosysteme notwendig ist;

– Langlebigkeit: Teile des Systems sind seit mehrals 20 Jahren im produktiven Betrieb, und eswerden nicht nur zusätzliche Funktionen gebaut,sondern auch bestehende Funktionen durch neueImplementierungen abgelöst;

– Legacy-Anteil: Wichtige Funktionen sind in alterTechnologie implementiert;

– Änderungsrate: Durch zunehmende Ge-schäftsanforderungen erforderliche hoheÄnderungsrate.

Diese Systeme altern unaufhaltsam und sie ver-ändern sich kontinuierlich – und wachsen dabeischeinbar unaufhaltsam. Ein wichtiger Zeitpunkt

im Leben dieser Systeme kommt, wenn zum erstenMal grössere Systemteile ersetzt werden müssen(Systemmodernisierung, Technologieersatz, Über-gang von der ersten zur zweiten Systemgeneration).Der Ersatz, d.h. das Reengineering der betroffenenSystemteile muss parallel zur kontinuierlichenImplementierung von neuen Geschäftsanforde-rungen geschehen. Die Systeme müssen dabeizu jeder Zeit die geforderten Qualitätsmerkmale(Verfügbarkeit, Verlässlichkeit, Sicherheit, ...) ga-rantieren. Zusätzlich erschwert wird diese Aufgabenoch durch zunehmenden Kostendruck auf dieInformatiksysteme – sowohl auf deren Betriebskos-ten, wie auch auf die Entwicklungskosten für neueFunktionalität.

Zur Bewältigung dieser Aufgabe sind die Formu-lierung einer Evolutionsstrategie, die Bereitstellungentsprechender Umsetzungsinstrumente und derEinsatz von Metriken zur Kontrolle der Fortschrittenotwendig. Dieser Beitrag zeigt den eingeschlagenenWeg bei der Credit Suisse auf.

EvolutionsstrategieDie kollektive Erfahrung der Informatik zeigt, dassdie schnelle Implementation von Geschäftsanfor-derungen leicht auf Kosten der Qualität geht: Eineweitestgehend Geschäftsanforderungen folgendeEntwicklung eines Informatiksystems führt zur

DOI 10.1007/s00287-008-0290-9© Springer-Verlag 2008

Stephan Murer · Carl Worms · Frank J. FurrerCredit Suisse,P.O. Box 600, 8070 Zürich,SchweizE-Mail: {stephan.murer, carl.f.worms,frank.j.furrer}@credit-suisse.com

Informatik_Spektrum_31_6_2008 537

{ MANAGED EVOLUTION

ZusammenfassungDie nachhaltige Weiterentwicklung einesgrossen Informatiksystemes ist aufgrund derschwierigen technischen und kommerziellenRandbedingungen eine sehr anspruchsvolleAufgabe. Einerseits haben diese Informatiksys-teme eine Komplexität erreicht, deren Folgenimmer schwieriger zu beherrschen sind. An-dererseits muss ein kontinuierlicher Fluss vonneuen Geschäftsanforderungen unter hohemZeit- und Kostendruck implementiert werden.Dabei müssen die Informatiksysteme zu jederZeit verfügbar, stabil, verlässlich und sicherbleiben sowie Effizienz und Wirtschaftlichkeitgewährleisten. Damit das IT-Management diesezentrale Aufgabe erfüllen kann, muss einewirksame Evolutionsstrategie formuliert undumgesetzt werden. Credit Suisse hat für sichdie Evolutionsstrategie ,,Managed Evolution“definiert und implementiert. Dieser Beitragerklärt die Managed Evolution, einen Teil derUmsetzungsinstrumente und die bis heuteerreichten Resultate. Diese zeigen messbar, dassdie Managed Evolution die erwarteten Erfolgeliefert.

Architekturerosion und damit zur schleichendenVerringerung der Effizienz – mit deutlich spürbarenFolgen von zunehmenden EDV-Kosten, verlängerterImplementierungszeit für neue Geschäftsanfor-derungen und einer generellen Inflexibilität desInformatiksystems (,,Verhärtung“). Beispiele fürdie Architekturerosion sind funktionale und Daten-Redundanz, enge Kopplungen und Abhängigkeitensowie die unkontrollierte technologische Divergenz.

Welches ist die ,,richtige“ Evolutionsstrategiefür sehr grosse Informatiksysteme? Wie setzt mandie Evolutionsstrategie um? Wie kontrolliert undmisst man die Umsetzung? Diese entscheidendenFragen muss jeder Betreiber eines sehr grossenInformatiksystems für sich beantworten. Die CreditSuisse hat für sich die Managed Evolution gewählt.Die Managed Evolution beruht auf den folgendenGrundprinzipien:

1. Gesteuerte, ausgewogene Investitionen in die Im-plementierung von Geschäftsanforderungen ausden Fachbereichen (Business Requirements) und

in die Verbesserung der Effizienz (TechnologischeModernisierung, Reengineering, Verbesserungder Architektur, Stabilisierung etc.),

2. Durchführung von beherrschbaren, risiko-ge-steuerten Evolutionsschritten (kein Totalersatz),

3. Verwendung von Metriken zur Kontrolle desFortschritts.

Die Managed Evolution berücksichtigt sowohltechnische als auch ökonomische Anforderun-gen [10, 19].

Formalisierung der Managed EvolutionDie Definition, Durchführung und Messung derManaged Evolution benötigt einen Formalis-mus. Dieser Formalismus wird in der Form des,,Koordinatensystems der Managed Evolution“bereitgestellt. Es verknüpft die beiden grundlegen-den Begriffe ,,Geschäftsnutzen“ (Effektivität) und,,IT-Entwicklungseffizienz“.

Geschäftsnutzenund IT-Entwicklungseffizienz

Grundlegend für das Verständnis und für die Formu-lierung der Credit Suisse Evolutionsstrategie ist dasKoordinatensystem der Managed Evolution (Abb. 1).

Jeder Punkt im Koordinatensystem zeigt den Zu-stand des Informatiksystems zu einem bestimmtenZeitpunkt ti. Die Abszisse misst den Geschäftsnutzendes Informatiksystems: Der Geschäftsnutzen bestehtin der zur Verfügung gestellten IT-Funktionalitätzur Unterstützung der Geschäftsprozesse. DieOrdinate misst die IT-Entwicklungseffizienz. Wirbeschränken uns in diesem Beitrag auf die IT-Entwicklungseffizienz. Die IT-Entwicklungseffizienzbezieht sich auf die Entwicklung neuer Funktio-nalität und umfasst auch die adaptive Wartung.Selbstverständlich gibt es auch die Frage nach derIT-Betriebseffizienz. In unserem Geschäft ist dieEntwicklungseffizienz in der Regel die bedeutendereKomponente, da in ihr die adaptive Wartung mitenthalten ist. Der Grund dafür ist die notwendige,möglichst kurze ,,Time-to-Market“ für die EDV-Unterstützung von neuen Geschäftsfunktionen:Es gibt einzelne Geschäftsfelder, bei denen jedeVerzögerung um einen Monat bis zu siebenstelligeErträge verhindert.

Von Zeitpunkt tn+i zu Zeitpunkt tn+j nehmensowohl der Geschäftsnutzen als auch die IT-Entwicklungseffizienz zu (gewünschte Entwicklung)

538 Informatik_Spektrum_31_6_2008

AbstractDue to the difficult technical and commercialconstraints, the sustainable development ofvery-large-scale information technology sys-tems is a very demanding task. On the onehand these information technology systemshave reached a complexity which is more andmore difficult to manage. On the other handa continuous stream of new business require-ments must be implemented under high costand time-to-market pressure. The informationtechnology systems must at all times remainavailable, reliable, and secure and at the sametime assure effectiveness and economy. In orderto cope with the task, the IT management mustformulate and realize an effective evolution stra-tegy. For its own very-large-scale informationtechnology system Credit Suisse has defined andimplemented the evolution strategy “ManagedEvolutio”. This paper describes the ManagedEvolution, some of the implementation tools,and the results achieved so far. The resultsmeasurably show that the Managed Evolutiondelivers the expected results.

oder ab (unter gewissen Umständen leider nicht zuvermeiden).

Die Veränderung, also die Evolution desInformatiksystems, geschieht über Projekte:Projekte implementieren neue Funktionalität,korrigieren Architekturerosion, modernisierenTechnologie usw. Jedes Projekt liefert einen Beitragsowohl an den Geschäftsnutzen wie auch an dieIT-Entwicklungseffizienz: Die Projekte sind im Ko-ordinatensystem der Abb. 1 durch Pfeile dargestellt.Ihre Länge auf der Abszisse und auf der Ordinatemessen deren jeweiligen Beiträge zum Geschäfts-nutzen und zur IT-Entwicklungseffizienz (positivnach oben und rechts, negativ nach unten und links).Die Beiträge der einzelnen Projekte summieren sichund ergeben die Evolutionstrajektorie des Informa-tiksystems (in Abb. 1 die Evolutionstrajektorie vontn bis tn+k für die Projekte P1 bis und mit P11). DieDarstellung in der Abb. 1 ist vereinfacht: Zu jederZeit ist eine Vielzahl von Projekten (parallel) aktiv.Der Projektvektor wird jeweils im Zeitpunkt derBetriebsübergabe der Projektresultate eingetragen(Sequenzialisierung).

EvolutionstrajektorienWir betrachten zwei Evolutionstrajektorien undihre Folgen: a) die forcierte Implementierungvon Geschäftsanforderungen (Abb. 2), und b) dieManaged Evolution (Abb. 3).

a) Evolutionstrajektorie in Abb. 2: Forcierte Imple-mentation von Geschäftsanforderungen. Bei dieserEvolutionstrajektorie wurde über längere Zeit vielin die Implementierung von Geschäftsanforderun-gen investiert (Forcierung des Geschäftsnutzens,d.h. Fortschritte auf der Abszisse) auf Kosten derVerbesserung der IT-Entwicklungseffizienz (Ver-nachlässigung der IT-Effizienz, d.h. Rückschritte aufder Ordinate).

Die Folge des Defizites in der Investitionin die Entwicklungseffizienz ist, dass die IT-Entwicklungseffizienz kontinuierlich sinkt: DieFokussierung auf die ausschliessliche Implementa-tion von Geschäftsnutzen – unter Vernachlässigungvon Architekturfragen, Qualitätsmanagement usw.– führt zu Redundanz (neu implementieren istschneller als alte Teile verstehen und erweitern),enge Kopplungen (keine Zeit, um saubere Serviceszu bauen), vernachlässigte Integration (jeder schautfür sich selbst), technologische Divergenz (einebestimmte Datenbanktechnologie oder Webser-ver gefällt dem Entwickler besser), ungenügendeDokumentation (kostet zusätzlich Zeit) usw.

Die sinkende IT-Entwicklungseffizienz hat zurFolge, dass für den gleichen Aufwand immer wenigerFunktionalität (Geschäftsnutzen) produziert werdenkann. Dies ist aus der sinkenden Evolutionstrajek-torie und aus den kürzer werdenden Projektpfeilenersichtlich. In der Abb. 2 wurde dies so dargestellt,dass der Aufwand (Entwicklungskosten) für jedesProjekt gleich gesetzt wurde: Die Länge des Pro-jektvektors stellt damit die gelieferte Leistung dar– diese wird bei gleichem Projektaufwand wenigerund weniger!

Im Zeitpunkt tn+j befindet sich das Informa-tiksystem in einem derart verhärteten, inflexiblenZustand, dass es praktisch keine Evolution mehrzulässt. Dadurch kann auch kaum mehr Ge-schäftsnutzen geschaffen werden. Um wieder einentwicklungsfähiges System zu erhalten, muss mandas System in den gewünschten Endzustand inAbb. 2 führen: Dazu sind drastische Massnahmennotwendig – häufig ein Totalersatz des Informatik-systemes. Für grosse Systeme wären dies Projekte


{ MANAGED EVOLUTION

Abb. 1 Koordinatensystem der Managed Evolution

Abb. 2 Evolutionstrajektorie bei forcierter Implementation von Geschäftsanforderungen


im Umfang von mehreren Jahren und mehreren Jah-resbudgets des IT-Bereichs. Im Falle der SchweizerPlattform der Credit Suisse wurden sieben JahreProjektdauer und deutlich mehr als 2 MilliardenSchweizer Franken (CHF) an Kosten berechnet. ImLichte tatsächlicher Erfahrungen mit durchgeführ-ten und abgebrochenen Vorhaben zum Totalersatzerscheinen diese Schätzungen heute eher unge-nügend. Solche Projekte sind mit grossen Risikenverbunden. So müssen doch die Anforderungen unddie zugrunde liegende Technologie über mehrereJahre stabil gehalten werden. Die Beziehung zwi-schen den Geschäftseinheiten und dem IT-Bereichwird belastet, da über eine lange Zeit trotz hoherKosten wenig neuer Geschäftsnutzen entsteht. DieBeziehungen innerhalb des IT-Bereichs werdendadurch belastet, dass das alte Team das bestehendeSystem noch zu möglichst tiefen Kosten am Lebenerhalten muss, während ein anderer Bereich eineneue Lösung baut. Ist das Projekt erfolgreich, wirddie alte Mannschaft in dieser Aufgabe nicht mehrbenötigt. Liefert das Projekt nicht die erwartetenResultate, so ist die Gesamtsituation noch schlechterals vor dem Projekt, da in die alte Plattform nichtmehr investiert wurde. Gemäss unserer Erfahrunglassen sich Totalablösungen großer Informatik-

Abb. 3 Evolutionstrajektorie der Managed Evolution

systeme nur im Falle von Firmenfusionen oderFirmenübernahmen durchführen. Dabei wird dieübernommene Firma konsequent auf die bestehendePlattform überführt. Als Evolutionsstrategie eignetsich das Totalersatz-Vorgehen nur für kleinereSysteme.

b) Evolutionstrajektorie in Abb. 3: Managed Evo-lution. Die Evolutionstrajektorie befindet sich hierinnerhalb eines Kanals, den ,,Leitplanken“ derManaged Evolution. Diese Leitplanken stellen sicher,dass die Evolutionstrajektorie im Mittel nach rechts(Schaffung von Geschäftsnutzen) und nach oben(Verbesserung der IT-Entwicklungseffizienz) zeigt.

Die Auswahl und die Ausführungsreihenfolgeder Projekte werden hier so gewählt, dass sichGeschäftsnutzen und IT-Entwicklungseffizienzausgewogen (d.h. innerhalb des Kanals der ManagedEvolution) entwickeln. Falls eine Tendenz zum Ver-lassen des Evolutionskanals festgestellt wird, mussdies analysiert und gegebenenfalls durch spezielleArchitekturprojekte korrigiert werden (d.h. Projekt-vektoren, die steil nach oben zeigen). Die ManagedEvolution stellt sicher, dass das Informatiksystemsich auf Dauer im gewünschten Zustand in Bezugauf Geschäftsnutzen und IT-Entwicklungseffizienz


{ MANAGED EVOLUTION

befindet. Das wesentliche Instrument hier ist dasProjektportfolio-Management.

Metriken der Managed EvolutionDas Koordinatensystem der Managed Evolution inAbb. 1 benötigt zwei Metriken: Erstens die Metrikfür den Geschäftsnutzen (Abszisse, x-Achse), undzweitens die Metrik für die IT-Entwicklungseffizienz(Ordinate, y-Achse).

Metrik für den GeschäftsnutzenDer Geschäftsnutzen eines Projektes besteht ausder gelieferten Funktionalität zur Unterstützungder Geschäftsprozesse. Die neue Funktionalitätunterstützt z.B. einen effizienteren Geschäftspro-zess, wickelt ein neues Produkt ab, oder erlaubteine bessere Kundenbetreuung. Die neue EDV-Funktionalität ermöglicht damit neue Erträge fürdie Bank oder führt zu tieferen Abwicklungskosten– sie wirkt sich also positiv auf die Bilanz aus. DieWirkung auf die Bilanz wird über den errechnetenBeitrag beurteilt, den das Projekt zum zukünftigenGeschäftserfolg liefert. Als Metrik wird dafür derNet Present Value (NPV, vgl. [17]) verwendet. DerNPV ist eine bekannte betriebswirtschaftliche Be-rechnungsmethode aus der Investitionsrechnung,welche die Projektaufwände und die erwarteten

Abb. 4 Messung der IT-Entwicklungseffizienz

Erträge aufrechnet und abzinst. Die Einheit desNPV ist kCHF (kCHF= 1.000 Schweizer Franken).Damit hat man für jedes Projekt ein Mass für denwirtschaftlichen Geschäftsnutzen in kCHF.

Im Allgemeinen sind Projekte mit positivemNPV erwünscht (Projektvektorrichtung nachrechts). Es lässt sich aber nicht vermeiden, dasszeitweise auch Projekte mit negativem NPV durch-geführt werden müssen – Beispiele dafür sind dieErfüllung von neuen gesetzlichen oder regulatori-schen Vorschriften. Auch Re-Architekturprojektekönnen einen negativen NPV ausweisen (und da-für einen hohen Anteil an die Verbesserung derIT-Entwicklungseffizienz liefern!). Projekte miteinem negativen NPV sind nicht an sich schlecht;in vielen Fällen verbessern sie den NPV von zahl-reichen folgenden Projekten (z.B. bei Bereitstellungvon Infrastruktur, bei Komponentisierung, beiRedundanzreduktion oder bei Bereinigung desTechnologieportfolios).

Metrik für die IT-EntwicklungseffizienzDie Metrik für die IT-Entwicklungseffizienz ist inder Abb. 4 erklärt. Ein Informatiksystem mit einertiefen IT-Entwicklungseffizienz ,,sperrt“ sich gegenVeränderungen – also gegen dessen Evolution. Diesäussert sich in hohen Kosten für die Implementie-


rung von Geschäftsanforderungen und in langenProjektlaufzeiten, resultierend in später Marktver-fügbarkeit (Time-to-Market). Zusätzlich führt dieszu Ärger in den Projektteams, mit dem Managementund mit den Fachbereichen!

Im Gegensatz dazu unterstützt ein Informatik-system mit einer hohen IT-Entwicklungseffizienzdie Veränderungen und erlaubt kostengünstigeEntwicklung und kurze Time-to-Market. Eine hoheIT-Entwicklungseffizienz des Informatiksystemsist daher sehr wertvoll: Diese wirkt sich auf alledurchgeführten Projekte positiv aus und hat damiteine grosse Hebelwirkung.

Die Erfassung der Daten für die Messungder IT-Entwicklungseffizienz erfolgt pro Pro-jekt. Es werden nur Projekte für die Bildungder Metrik berücksichtigt, welche neue Busi-nessfunktionalität schaffen oder bestehendeBusinessfunktionalität erweitern, d.h. neue UseCases implementieren oder bestehende erweitern.Andere Projekttypen (z.B. korrektive Wartung,Infrastrukturprojekte, Prozessverbesserungspro-jekte) geben keinen Beitrag zur Berechnung derIT-Entwicklungseffizienz EDev. Die Quantifizierungder IT-Entwicklungseffizienz benötigt pro Projekt Pi

drei Messgrössen (Abb. 4):

1. Die Lieferzeit TtMi (Time-to-Market): Dauerdes Projektes Pi in Kalendertagen vom Mo-ment des Projektstarts bis zur Übergabe desProjektresultates an die IT-Produktion.

2. Die Entwicklungskosten DevCi (DevelopmentCost): Kosten des Projektes Pi in CHF vomMoment des Projektstarts bis zum Projektab-schluss (= Übergabe des Projektresultates an dieIT-Produktion + 3 Monate Garantieleistungen).

3. Die Grösse des funktionalen Beitrages Sizei:Menge an Funktionalität, welche das ProjektPi generiert hat. Als Mass für die funktionaleGrösse wird die Anzahl Use Case Points (UCP,vgl. [4–6]) berechnet, welche das Projekt andie IT-Produktion übergibt. Use Case Pointssind eine Weiterentwicklung des bekanntenfunktionalen Grössenmasses ,,Function Points“.Zur Berechnung der Anzahl Use Case Points,die durch ein Projekt geliefert werden, werdendie Anforderungen in der Form von Use Cases(vgl. [1]) spezifiziert. Für jeden Use Case lässtsich anschliessend einzeln seine Anzahl Use CasePoints berechnen. Die Gesamtheit aller Use Case

Points aus allen zum Projekt gehörenden UseCases ergibt die Anzahl Use Case Points, d.h.die funktionale Grösse Sizei des Beitrages desProjektes Pi.

TtMi und DevCi werden pro Projekt jeweils überSizei normiert, damit Projekte mit unterschiedlicherGrösse vergleichbar werden. Anschliessend werdenüber eine statistisch relevante Anzahl von Projektendie Mittelwerte gebildet, nämlich:

τ für die Time-to-Market, undσ für die Entwicklungskosten.

Die IT-Entwicklungseffizienz entsteht dann aus:

EDev = 1/(τ ×σ).

Ihre Einheit ist UCP2/(Tage ×kCHF). Im Zäh-ler steht die gebaute Funktionalität (gemesseninAnzahl Use Case Points im Quadrat) und imNenner steht der dazu verwendete Aufwand (Zeitmal Geld).

In gewissen Fällen wird auch die inverse IT-Entwicklungseffizienz verwendet: die Resistance-to-Change ρ = 1/EDev. Eine tiefe Resistance-to-Changeentspricht einer hohen IT-Entwicklungseffizienz.Die Resistance-to-Change ρ hat eine anschaulicheBedeutung – man ,,spürt“ den Widerstand desInformatiksystemes gegen dessen Veränderung!Die Metrik Resistance-to-Change widerspiegeltdas Empfinden der Fachbereiche besser als dieIT-Entwicklungseffizienz.

ArchitekturbezogeneSteuerungsinstrumentefür die IT-Entwicklungseffizienz

Das Ziel der Managed Evolution ist eine ausgewo-gene Implementierung von Geschäftsanforderungenund Aktivitäten zur Verbesserung der IT-Effizienz(Managed Evolution Evolutionstrajektorie inAbb. 3).

Welche Steuerungsinstrumente zur Beeinflus-sung der Projekte stehen im Rahmen der ManagedEvolution zur Verfügung? Es sind dies primär (vgl.Abb. 5):

– Starker Architekturprozess: Definition und Durch-setzung der IT-Standards in jedem Projekt übertechnische und fachliche Reviews,

– Re-Architekturprojekte: Spezielle Projekte (ausdem Architekturbudget und unter alleiniger


{ MANAGED EVOLUTION

Abb. 5 Credit SuisseArchitekturprozess

Architektur-Governance) zur gezielten Verbes-serung von architektonischen Eigenschaften derIT-Plattform, z.B. gezielte Redundanzelimination,Komplexitätsreduktion, Integrationsverbesserun-gen,

– Projektportfolio-Management: Auswahl und Steue-rung der Reihenfolge der Projektausführungen.

Die technischen und fachlichen Reviews sindintegraler Bestandteil des standardisiertenProjektvorgehens. Ein wichtiger Aspekt desProjektportfolio-Managements ist die rechtzeitigeDurchführung von Re-Architekturprojekten zurKorrektur der Architekturerosion, wenn die Projekt-sequenz droht, den Kanal der Managed Evolution inAbb. 3 (nach unten) zu verlassen.

Wichtigkeit der ArchitekturDie IT-Entwicklungseffizienz EDev ist eine glo-bale Eigenschaft des Informatiksystems und hängtvon vielen Faktoren ab (z.B. zusätzlich vom gutenRequirements-Management, vom Skillprofil derMitarbeiter, von zeitgerecht zur Verfügung stehen-der Infrastruktur, von den Entwicklungswerkzeugenusw.). Die Autoren sind der Ansicht, dass die fol-genden beiden Faktoren einen sehr grossen Einflusshaben:

1. IT-Architektur,2. Qualität der Prozesse (Vorgehensmodell,

Maturität etc.).

Damit stellt sich sofort die Frage: ,,Was ist guteIT-Architektur“? IT-Architektur zeigt sich in ihrerWirkung: Die Struktur des gesamten Informatik-systemes – also Infrastruktur und Applikationen –muss derart gestaltet werden, dass es einerseits einekontinuierliche Verbesserung der IT-Entwicklungs-und Betriebseffizienz ermöglicht und anderer-seits die nichtfunktionalen Qualitätsmerkmale(Verfügbarkeit, Verlässlichkeit, Sicherheit, ...)optimal unterstützt. Gute Architektur trägt we-sentlich zur Erhöhung der IT-Entwicklungseffizienzbei. Dabei sind sich die IT-Architekten über eineAnzahl wichtiger Architekturparadigmen einig(z.B. [3, 7, 9, 11–14]). Einige ausgewählte Paradigmensind:

– Partitionierung: Grosse Informatiksystemeaufteilen – und zwar gemäss der fachlichenKohäsion;

– Komplexitätsreduktion: Alle funktionalen, daten-mässigen und servicebezogenen Redundanzenvermeiden oder elimineren. Kapselung: Funktio-nale Einheiten und Datenbestände über Serviceszur Verfügung stellen (keine Direktzugriffe);


– Lose Kopplung: Modularisierung des Informatik-systemes, Kapselung der Systemteile, Kopplungüber Services (formale Interfaces), keine unnötigenAbhängigkeiten, leistungsfähige Middleware-Infrastruktur;

– Architekturpatterns: Pattern für die Anwendungs-entwicklung zur Erzielung von konzeptionellerund implementierter Integrität standardisieren;

– Technologieplattformen zur Verfügung stellen:Technische Funktionalität (Datenbanken, Middle-ware, Netzwerke usw.) standardisiert und getrenntvon der Applikationslandschaft zur Verfügungstellen. Keine Technologieabhängigkeiten in denApplikationen.

Architekturparadigmen beeinflussen Qualitäts-eigenschaften des Informatiksystems und lassensich – zusätzlich zu den Metriken der ManagedEvolution – teilweise ganz direkt messen, z.B. durchdie Anzahl mittels Services ausgeführter Bank-Transaktionen (im Rahmen dieses Artikels nichtweiter ausgeführt).

Credit Suisse ResultateDas Koordinatensystem der Managed Evolution(vgl. Abb. 1) verwendet die zwei Achsen (undMetriken) ,,IT Entwicklungseffizienz“ und ,,Ge-schäftsnutzen“. In diesem Abschnitt sind diequantitativen Resultate für die IT Entwicklungseffi-zienz dargestellt. Die quantitativen Resultate für den

Abb. 6 Verlauf der IT-Entwicklungseffizienz in 12 Quartalen in der Credit Suisse

Geschäftsnutzen können leider nicht veröffentlichtwerden.

Quantitative ResultateDie quantitativen Resultate für die:

– Time-to-Market TtM pro Use Case Point– Entwicklungskosten DevC pro Use Case Point– IT-Entwicklungseffizienz EDev

über 12 Quartale sind in der Abb. 6 dargestellt (mitder Trendlinie für die IT-Entwicklungseffizienz).Sie fassen die Werte von insgesamt 85 abgeschlos-senen Entwicklungsprojekten mit verlässlichenProjektmetriken seit dem Quartal Q3/05 zusammen(Projekte mit fragwürdigen Messwerten wurdennicht berücksichtigt).

Die Grafiken sind wie folgt zu lesen: Die x-Achseist jeweils die Zeitachse, die einzelnen Werte gebendas jeweilige Quartal an. Auf den y-Achsen sinddie zugehörigen Summenwerte (TtM, DevC, EDev)dargestellt. Jeder einzelne Wert in Abb. 6 stellt dieMittelung über alle Projekte im zurückliegendenJahr dar. Diese Mittelungsmethode ist bekannt als,,sliding window“ mit einer Windowgrösse voneinem Jahr und einer jeweiligen Verschiebung voneinem Quartal. Je Quartalswert betrug:

– die Anzahl der berücksichtigten Projekte zwischen24 und 34,


{ MANAGED EVOLUTION

– die Time-to-Market TtM zwischen 9.510 und 18.339Tagen,

– der implementierte Funktionsumfang Sizezwischen 7.197 und 20.549 UCPs,

– die Summe der Entwicklungskosten DevCzwischen 42,8 und 101,0 Millionen CHF.

Beispiel: Im ,,sliding window“ des Quartalswertes200709 (= 3. Quartal 2007) sind 30 Projekte erfasst:Diese repräsentieren eine Entwicklungsinvestitionin Businessapplikationen von 98,2 Millionen CHFund die Realisierung von 20.549 UCPs.

Die dargestellten Resultate sind mit einergewissen Unsicherheit behaftet:

– generell sind unsere Entwicklungsprozesse aufCMMI Maturity Level 2 noch zu wenig stabil,

– dann sind die Grössenschätzungen Sizei der ein-zelnen Projekte, die von den Projektleitern selbstdurchgeführt werden, natürlich nicht frei vonsubjektiven Gewichtungen,

– und zuletzt haben die je Quartal aufsummiertenJahreswerte noch hohe Varianzen (s.o.).

Umgekehrt ist die Zuverlässigkeit der Messungwesentlich durch die Homogenität der Projektorga-nisationen (gleiches Land, eine Branche, gleichesUnternehmen, gleiches Projektvorgehen, rela-tiv standardisiertes Technologie-Portfolio usw.)begründet.

Insgesamt sind damit die Trendaussagen plau-sibler als die absoluten Werte in den Kurven. DieTrendlinie der Entwicklungseffizienz zeigt lang-fristig nach oben. Der numerisch kleine Wert von0,0067 der Steigung in Abb. 6 täuscht leicht darüberhinweg, dass dies eine relative Effizienzsteigerungvon 23,8% (0,21 der Trendlinie im Q6 2007 verglichenmit 0,16 im Q6 2005) bedeutet – für eine Entwick-lungsorganisation mit ca. 2.500 Mitarbeitern einexzellentes Ergebnis.

ResultatanalyseDie Credit Suisse hat in den vergangenen Jah-ren grosse Anstrengungen zur Verbesserungder IT-Effizienz auf verschiedenen Gebietenunternommen, z.B. die Durchführung von Re-Architekturprogrammen (gezielte Verbesserung derarchitektonischen Eigenschaften des IT-Systems),die Einführung des starken Architekturprozesses,die Installation eines formalen Projektportfolio-

Managements und die Durchsetzung von Projekt-und Produktmetriken usw. Dabei hat sich her-ausgestellt, dass die IT-Entwicklungseffizienz imMittel verbessert wird. Dies bedeutet, dass die Cre-dit Suisse IT mit deutlich weniger Aufwand mehrBusiness-Funktionalität implementieren kann.

Zusätzlich wurden weitere Massnahmen ergrif-fen, um die IT-Entwicklungseffizienz zu erhöhen.Beispiele dafür sind der stärkere Einbezug von Ar-beitskräften in Regionen mit tieferen Arbeitskosten,das konsequente technische Applikationsplattform-Management und die Verbesserung unsererProzess-Maturität auf CMMI Maturity Level 2.Leider ist es mit den derzeit zur Verfügung stehen-den Daten – wie eine statistische Faktoranalyse [2]zeigte – nicht möglich, zuverlässig den Einflussder verschiedenen Massnahmen auf die IT-Entwicklungseffizienz auseinanderzuhalten odergar zu bewerten.

AusblickWas uns als kommerzielles Unternehmen letzt-lich interessiert, ist, herauszufinden, ob sich derfinanzielle Wert guter IT-Architektur systematischund quantitativ messen lässt. Wir sind zwar davonüberzeugt, aber das bestehende empirische undtheoretische Gerüst ist noch ungenügend.

So können wir mit der vorgestellten Metrik fürdie IT-Entwicklungseffizienz zwar einen interes-santen und erwünschten Trend unseres Informatik-systemes aufzeigen, kennen aber nur ansatzweisedie ausschlaggebenden Faktoren. Sehr interessantwäre auch eine Antwort auf die Frage, ob es einefinanziell optimale Strategie zur Evolution sehrgroßer Informatiksysteme überhaupt gibt, und wennja, welche. Hier fehlt das theoretische Fundamentebenso wie eine systematische, praktische Empirie.

Als IT-Architekten in einem Grossunternehmenkönnen wir uns zwar eine Richtung wünschen, aberdie intensive Forschungstätigkeit liegt ausserhalbunserer Möglichkeiten – diese erhoffen wir von denuniversitären Institutionen.

Danksagung. Dieser Beitrag beruht auf dem Ju-biläumsvortrag von Stephan Murer (Global CTOCredit Suisse), gehalten am 8.11.2007 auf der sd&m25-Jahrestagung ,,Bits und Steine“ in Berlin. DasIdeengut der Managed Evolution wurde im Archi-tekturdepartement der Credit Suisse in den Jahrenvon 1997 bis heute entwickelt. Die Autoren danken


allen Kollegen in der IT-Architektur und in denEntwicklungsdepartementen für ihre Beiträge. DieMetriken werden in einer eigenen Metrikstelleinnerhalb der zentralen Qualitätsorganisation derCredit Suisse erfasst und sind hier ebenfalls bestensverdankt.

Literatur. Leider existiert über die Evolutionsstrate-gie von sehr grossen Informatiksystemen (teilweisemit hohem ,,Legacy“-Anteil) wenig Literatur. Dievorhandene Literatur konzentriert sich weitgehendauf die Entwicklung von neuen Systemen (,,green-field approach“). Nützliche Information findet sichaber in [8, 11–15, 18, 20].

Literatur1. Cockburn A (2001) Writing effective use cases. Addison-Wesley, Boston2. Dobson AJ (2000) An introduction to generalized linear models, 2nd edn. Chap-

man & Hall/CRC, Boca Raton3. Gorton I (2006) Essential software architecture. Springer, Berlin4. Frohnhoff S, Jung V, Engels G (2006) Use Case Points in der industriellen Praxis.

sd&m AG, Offenbach (Zugriff über: http://www.sdm.de/web4archiv/objects/download/pdf/sdm_pub_metrikon_frohnhoff.pdf), letzter Zugriff: 12. Mai 2008

5. Frohnhoff S, Kehler K (2007) Use Case Points Aufwandschätzung auf Basis unter-schiedlicher Spezifikations-Formate. sd&m AG, Offenbach (Zugriff über:http://www.sdm.de/web4archiv/objects/download/pdf/1/sdm_frohnhoff_ucp_spezformate.pdf), letzter Zugriff: 12. Mai 2008

6. Frohnhoff S (2008) Grosse Softwareprojekte – Aufwandschätzung mit Use CasePoints. Informatik Spektrum 31(6) DOI 10.1007/s00287-008-0288-3

7. Garland J, Anthony R (2003) Large-scale software architecture. John Wiley & SonsLtd., Chicester

8. Grabski B, Günther S, Herden S, Krüger L, Rautenstrauch C, Zwanziger A (2007)Very large business applications. Informatik Spektrum 30(4):259–263

9. Hohmann L (2003) Beyond software architecture. Addison-Wesley, Boston10. Kankaanpää I, Koskinen J, Tilus T, Sivula H, Lintinen H, Ahonen J (2007) IS evolu-

tion benefit assessment – challenges with economic investment criteria. In: Tech-nologies for business information systems. Springer, Dordrecht, The Netherlands,ISBN 978-1-4020-5633-8

11. Maier MW, Rechtin E (2002) The art of systems architecting. 2nd edn. CRC Press,Boca Raton

12. Masak D (2005) Moderne Enterprise Architekturen. Springer, Berlin13. Masak D (2007) Legacysoftware – Das lange Leben der Altsysteme. Springer,

Berlin14. Mens T, Demeyer S (Hrsg) (2008) Software Evolution (speziell Part 2: Reenginee-

ring of Legacy Systems). Springer, Berlin Heidelberg15. Miller HH (1998) Legacy Software Systems. Digital Press (Butterworth-Heinemann),

Boston16. Northrop L et al. (2006) Ultra-large-scale systems – the software challenge of the

future. Software Engineering Institute, Carnegie Mellon University (Zugriff über:http://www.sei.cmu.edu/uls/), letzter Zugriff: 12. Mai 2008

17. NPV: „Net Present Value“, Wikipedia, 15.1.2008, (Zugriff über:http://en.wikipedia.org/wiki/Net_present_value)

18. Seacord RC, Plakosh D, Lewis GA (2003) Modernizing legacy systems – softwaretechnologies, engineering processes, and business practice. Addison-Wesley (Pear-son Education), Boston

19. Tilus T, Koskinen J, Ahonen JJ, Lintinen H, Sivula H, Kankaanpää I (2007) Indus-trial application and evaluation of a software evolution decision model. In: Tech-nologies for business information systems. Springer, Dordrecht, The Netherlands,ISBN 978-1-4020-5633-8

20. Warren I (1999) The renaissance of legacy systems – method support for softwareevolution. Springer, London


Managed Evolution

Documents

Transcript of Managed Evolution