Scrum Agile Produktentwicklung mit Scrum Nearshoring ...

Experience Nr. 47 Juli 2010
© by ERNI Consulting AG
Experience
ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen
Scrum
Agile Produktentwicklung
mit Scrum
Nearshoring
Outsourcing bringt Flexibilität
Outtasking
Nearshoring senkt Kosten
Architekturreview
Ein Architekturreview sorgt für Durchblick

ERNI Experience | Editorial
Titelseite: Reto Tschudi
Business Area Manager
in der Firma ERNI Consulting AG.
Beratertätigkeit: Testmanagement
und Prozessoptimierung.
Impressum
Herausgeber
ERNI Consulting AG
Zürich · Baar · Bern
ERNI (Deutschland) GmbH, München
ERNI (Slovakia) s.r.o., Bratislava
Redaktion
Maria Holla
ERNI (Slovakia) s.r.o.
Tel. +421 2 3255 37 37
E-Mail leserservice@erni.ch
Internet www.erni.ch/experience
Editorial
Reto Tschudi
Scrum
Roland Oehen Kanzow
Nearshoring
Philipp Rey
Christoph Krauer
Outtasking
Martin Sand
Heinz Schlatter
Architekturreview
Oliver Blindenbacher
Lektorat
Stefan Kyora,
Mediacontact GmbH, Luzern
Ruedi Häuptli, Sprachagentur Bahia,
Salvador BR
Konzept/Layout
Katarina Beinrohrova
Produktion
von Ah Druck AG, Sarnen
Auflage
10 000 Exemplare
Erscheint quartalsweise
Copyright © 2010
by ERNI Management Services AG
Alle Rechte vorbehalten.
2
Agilität
als Erfolgsrezept
Kürzere Time-to-Market, bessere Qualität, höhere Flexibilität und stärker motivierte Mitarbeitende
– dies sind die Vorteile agiler Produktentwicklungsmethoden. Kein Wunder, nutzen
immer mehr Unternehmen Scrum oder ähnliche Modelle. Das Konzept der Agilität
lässt sich allerdings nicht nur in der Produktentwicklung mit Gewinn anwenden. Auch agile
Organisationen besitzen gewichtige Vorteile. Zudem können auch Produkte dem Grundgedanken
der Agilität entsprechen, wenn sie nur so viel Komplexität aufweisen wie unbedingt
notwendig und daher einfach gewartet und weiterentwickelt werden können. In diesem
ERNI Experience zeigen wir Ihnen anhand konkreter Praxisbeispiele, wie Sie Prozesse, Produkte
und Ihre Organisation agil gestalten können und wo der konkrete Nutzen liegt.
Der erste Artikel widmet sich dem Thema Scrum. Sie erfahren, wie sich die agile Methodik in
Organisationen mit ganz unterschiedlichen Voraussetzungen zielgerichtet einführen lässt.
Die beiden darauf folgenden Erfahrungsberichte geben Beispiele, wie Nearshoring die Agilität
Ihrer Organisation steigert. Die geschilderten Erfahrungen beruhen auf der Praxis von
ERNI als Begleiter von Outsourcing-Projekten, aber auch als Nearshoring-Partner. Bereits
seit mehreren Jahren betreibt ERNI zu diesem Zweck einen Standort in der Slowakei.
Abgeschlossen wird das Magazin mit einem Beitrag über Architekturreviews. Sie sind ein
probates Mittel, um die Qualität von IT-Systemen bedarfsgerecht zu optimieren, ohne die
Komplexität unnötig zu erhöhen. Damit entsprechen sie ebenfalls dem Grundgedanken der
Agilität.
Ich wünsche Ihnen eine anregende Lektüre und freue mich auf Ihr Feedback.
Herzlich
Reto Tschudi

Inhalt
Scrum
Nearshoring
Outtasking
Architekturreview
Schneller und besser durch Agilität 4
Agile Produktentwicklung mit Scrum
Die rasante technologische Entwicklung, schnelle Änderungen bei den Kundenwünschen und
wachsendes Qualitätsbewusstsein stellen die Softwareentwicklung vor neue Herausforderungen.
Mit agiler Entwicklung lassen sie sich meistern. Bei der Einführung von Scrum hat sich ein behutsames
Vorgehen bewährt, das mit einem Pilotprojekt beginnt.
Mit Nearshoring den Aufschwung nutzen 8
Outsourcing bringt Flexibilität und zusätzliches Know-how
Der sich abzeichnende Aufschwung bietet Chancen für innovative Produkte. Für die Entwicklung
neuer Geräte und neuer Software ist Outsourcing eine attraktive Option. Notwendig für das
Gelingen der Auslagerung sind klar definierte Prozesse, eine intensive Kommunikation mit dem
externen Team und eine klare Unterstützung durch das Management.
Betrieb und Wartung reibungslos verlagern 12
Nearshoring senkt Kosten und erlaubt Konzentration auf Kernkompetenzen
Bei Wartung und Betrieb von IT-Applikationen ist Outsourcing attraktiv. Damit lässt sich einer der
grössten Kostenblöcke in der IT reduzieren. Gleichzeitig kann sich das eigene Personal wieder auf
die wertschöpfenden kreativen Tätigkeiten konzentrieren. Mit der richtigen Vorbereitung verlaufen
die Übergabe und der weitere Betrieb reibungslos.
Wie viel Qualität braucht ein IT-System? 16
Ein Architekturreview sorgt für Durchblick
Ein IT-System muss die gestellten Anforderungen erfüllen. Alles, was darüber hinausgeht, erhöht
neben dem Aufwand auch die Komplexität, ohne einen zusätzlichen Mehrwert zu bieten. Während
dies beim Funktionsumfang meist berücksichtigt wird, werden im Bereich der qualitativen
Anforderungen wie Performance, Sicherheit oder Wartbarkeit – im Widerspruch zu einem agilen
Vorgehen – häufig Dinge umgesetzt, die so gar nicht benötigt werden. Ein Architekturreview kann
überflüssige, aber natürlich auch ungenügend berücksichtigte Anforderungen aufdecken.
Alle Artikel online:
www.erni.ch/experience
Inhalt | ERNI Experience
3

Scrum | Schneller und besser durch Agilität
Schneller und besser durch Agilität
Agile Produktentwicklung mit Scrum
Die rasante technologische Entwicklung, schnelle Änderungen bei den Kundenwünschen und wachsendes Qualitätsbewusstsein
stellen die Softwareentwicklung vor neue Herausforderungen. Mit einer agilen Vorgehensweise wie Scrum lassen sich diese meistern.
Bei der Einführung von Scrum hat sich ein behutsames Vorgehen bewährt, das mit einem Pilotprojekt beginnt. Von Roland Oehen Kanzow
Agile Produktentwicklungsmethoden sind
dabei, sich durchzusetzen. Eine dieser Methoden
ist Scrum. Auf Scrum setzen heute
viele Grosskonzerne aus der Industrie und
dem Dienstleistungssektor. Das Vorgehensmodell
bietet einen Prozessrahmen für
agile Produktentwicklungen, in dem sich
die Flexibilität, das Tempo und die Qualität
von Entwicklungsprojekten verbessern
sollen. Der Unterschied von Scrum zu traditionellen
Vorgehensweisen, wie sie etwa
vom Wasserfall-Modell oder vom V-Modell
beschrieben werden, ist tiefgreifend. Im
Grunde geht es darum, eine Praxis, die nach
dem Motto «command and control» funktioniert,
durch selbstbestimmtes Arbeiten zu
ersetzen.
Scrum setzt grundsätzlich auf einen
anderen Prozess und auf andere Rollen
als traditionelle Vorgehensmodelle.
Ein wichtiges Element von Scrum
ist der sogenannte Sprint (siehe Abb. 1).
Damit werden zwei- bis vierwöchige Iterationen
bezeichnet, an deren Ende ein funk-
4
tionsfähiges Produktinkrement steht (siehe
Abb. 2). Ein Sprint beginnt mit der Auswahl
von Aufgaben durch das Entwicklungsteam
im Rahmen einer Planungssitzung. Während
der Entwicklung arbeitet das Team die
Aufgaben selbstorganisiert ab. Ein tägliches
Kurzmeet ing, das «Daily Scrum Meeting»,
dient der Koordination und dem Wissenstransfer
im Team. Jeden Tag stellen sich
die Mitglieder ihre Arbeitsergebnisse, ihre
Aufgaben und ihre Herausforderungen gegenseitig
vor (siehe Abb. 3). Da am Ende ein
lauffähiges Inkrement stehen soll, wird innerhalb
des Sprints auch getestet. Die Phase
endet mit einem Review und einer Retrospektive
(siehe Abb. 4). In Letzterer wird der
Sprint reflektiert und nach Verbesserungsmöglichkeiten
gesucht. Scrum ist damit
auch durch einen kontinuierlichen Verbesserungsprozess
gekennzeichnet.
Neben den Teammitgliedern existieren
zwei weitere Rollen: der Product Owner
und der ScrumMaster. Der Product Owner
ist für die Strategie des Entwicklungspro-
jekts zuständig. Zu seiner Arbeit gehören
die Releaseplanung sowie die Formulierung
und die Priorisierung von Aufgaben,
aus denen sich das Team je Sprint einige
zur Bearbeitung auswählt. Die Basis dafür
bilden sein Domänenwissen und seine
Kenntnisse über die Wünsche der Stakeholder.
Der Product Owner kommuniziert
direkt mit den Stakeholdern, aber auch mit
dem Team. Er nimmt an den Planungs- und
Reviewmeetings teil. Gegenüber dem Team
repräsentiert er damit die Stakeholder.
Der ScrumMaster bearbeitet die taktische
Ebene eines Projekts. Er schafft ein
optimales Umfeld für das Team. Konkret
macht er Vorschläge, wie sich bestimmte
Herausforderungen meistern lassen. Er
motiviert, unterstützt die Kommunikation
im Team und greift bei Konflikten ein.
Gleichzeitig schützt er das Team vor regelwidrigen
Interventionen von aussen und
sorgt dafür, dass es in Ruhe arbeiten kann.
Das Team selbst besteht bei Scrum aus

Der ScrumMaster bearbeitet die taktische Ebene eines Projekts. Er schafft ein optimales
Umfeld für das Team und achtet darauf, dass die Regeln von Scrum eingehalten
werden.
Sprint
• Iteration mit fixer
Länge
• Geschützt
• Pull statt Push
• Inspect – Adapt
Product
Vision
Product
Backlog
Meetings
• Sprint Planning
• Sprint Review
• Retrospective
• Daily Scrum
Selected Product
Backlog
fünf bis neun Mitgliedern. In der Gruppe
müssen sämtliche Kompetenzen zur
Bearbeitung der ausgewählten Aufgaben
vorhanden sein, vom Entwerfen der Architektur
über das Entwickeln bis zum
Testen. Wie das Team diese Unteraufgaben
verteilt, bleibt ihm überlassen. In jedem
Fall ist das ganze Team verantwortlich
für die Erledigung der ausgewählten
Arbeiten (siehe Abb. 5).
Wie gross der Wandel ist, den Scrum erfordert,
hängt von der Kultur und der Praxis
der Zusammenarbeit im betroffenen Unternehmen
ab. Deswegen muss der entsprechende
Prozess auf das jeweilige Un-
Dokumente
• Product Backlog
• Sprint Backlog
• Burn Down Chart
• Release Plan
Sprint
Backlog
Daily Scrum
Meeting
Rollen
• Product Owner
• ScrumMaster
• Team
Product
Increment
ternehmen angepasst werden. Am grössten
ist der Schritt für Organisationen, deren
Kultur zu Vorgehensmodellen passt, die
auf «command and control» setzen. Für die
Mitarbeitenden solcher Firmen ist sowohl
der Wissenstransfer im Team als auch die
Übernahme der Verantwortung durch die
Entwickler neu. Der Wandel löst deswegen
zu Beginn durchaus auch Vorbehalte aus.
Unterschätzt man den Wandlungsprozess
nicht und widmet man ihm genügend
Aufmerksamkeit, lässt sich Scrum aber
auch gewinnbringend in hierarchisch
strukturierten Unternehmen einführen.
Bewährt hat sich beim Umbau solcher
Schneller und besser durch Agilität | Scrum
Abbildung 1:
Elemente von Scrum
Abbildung 2:
Von der Vision zum
Product Increment
Organisationen neben einer engen Begleitung
der betroffenen Mitarbeitenden vor
allem die Pilotierung, das heisst eine erste
Einführung von Scrum in einer Keimzelle,
die dann zum Ausgangspunkt des Wandels
im gesamten Unternehmen wird.
Beispiel 1
Grundlegender Wandel
bei einem IT-Unternehmen
Ein IT-Unternehmen betreibt eine Internetplattform.
Es steht unter grossem
Marktdruck, da die Kunden mit einem
Mausklick zur Konkurrenz wechseln können.
Die Firma entwickelt neue Releases
nach einem Phasenmodell. Dem Projekt-
5

Scrum | Schneller und besser durch Agilität
leiter kommt dabei die zentrale Bedeutung
zu. Er plant die Projekte, definiert
Arbeitspakete und legt die Dauer für ihre
Erledigung fest.
Um die Time-to-Market zu beschleunigen,
beschliesst das Unternehmen, Scrum
einzuführen. Dieses Ziel wurde erreicht.
Die Umstellung bewirkte, dass das Unternehmen
schneller auf die aktuelle Marktsituation
reagieren kann. Neuartige Funktionalitäten
vergleichbarer Plattformen
können wesentlich schneller auch für das
eigene Angebot realisiert werden.
Der Wandlungsprozess hat rund ein Jahr in
Anspruch genommen. In dieser Zeit wurden
die Mitarbeitenden zum Teil intensiv
gecoacht und betreut. So gab es etwa Vieraugengespräche,
in denen das neue Modell
und die Gründe der Einführung vorgestellt
wurden. Darüber hinaus wurde die Teambildung
unterstützt, beispielsweise mit
einem Wochenende in einem Sporthotel.
Nicht zuletzt konnten die Mitarbeitenden
den Wandlungsprozess mitgestalten. Die
Scrum-Teams wählten sich zum Beispiel
ihre Mitglieder selbst aus.
Da der Einführungsprozess von Scrum
eine Organisation grundlegend verändern
kann, sind die Anforderungen an das
Projektteam entsprechend hoch. Es muss
Scrum beherrschen und sollte zudem über
Erfahrung mit Veränderungsprozessen verfügen.
Denn der Prozess muss nicht nur
massgeschneidert werden, die während der
6
Abbildung 3:
Daily Scrum Meeting
Wie gross der Wandel ist, den Scrum erfordert, hängt von der Kultur und der Praxis
der Zusammenarbeit im betroffenen Unternehmen ab. Deswegen muss der
entsprechende Prozess auf das jeweilige Unternehmen angepasst werden.
Fragen
• Daily Scrum Meeting,
15 Minuten jeden
Tag zur gleichen Zeit
am gleichen Ort
• Es werden drei
Fragen beantwortet,
reihum durch die
Teammitglieder
Einführung immer wieder auftauchenden
Herausforderungen lassen sich mit Erfahrung
auch besser und schneller meistern.
Da Scrum neue Rollen in eine Organisation
einführt, ist durch die Veränderung auch
das Selbstverständnis der Mitarbeitenden
in Bezug auf ihre Aufgabe und ihre Position
betroffen. Deswegen müssen die Mitglieder
des Einführungsteams nicht zuletzt
auch über ausgeprägte Soft Skills verfügen.
Die besondere Bedeutung des Veränderungsprozesses
für die betroffenen Mitarbeiter
legt den Beizug externer Experten für
das Einführungsteam nahe. Diese können
auftauchende Konflikte wesentlich besser
konstruktiv lösen als Personen mit einer
langen Geschichte in der Organisation.
Nicht in jedem Fall sind allerdings die weichen
Faktoren die entscheidende Herausforderung
bei der Einführung von Scrum.
Denn es gibt auch Entwickler, welche die
Freiheit, die ihnen das Modell bringt, zu
schätzen wissen. Dennoch sind auch in
solchen Unternehmen vielfach Anpassungen
bei der Einführung notwendig.
Beispiel 2
Scrum bei verteilten
Entwicklungsstandorten
Ein IT-Unternehmen entwickelt eine
Standardsoftware in einem Markt mit intensivem
Wettbewerb. In diesem Markt
positioniert sich das Unternehmen als
Technologieführer. Um der Herausforderung
des schnellen Innovationsrhythmus
Gibt es dabei irgendwelche Hindernisse?
Was soll bis zum nächsten Treffen erreicht werden?
Was wurde seit dem letzten Treffen gemacht?
• Dient der Abstimmung
des Teams, es
werden dabei keine
Probleme gelöst
• Es darf zusätzlich
zum Team und zum
ScrumMaster jeder
Interessierte daran
(passiv) teilnehmen
besser gewachsen zu sein, führt die Firma
schrittweise Scrum ein.
Das Team war von Beginn an sehr an der
Materie interessiert. Unterstützt wurde
es durch Schulung, die Klärung der neuen
Rollen sowie bei der ersten Erstellung
spezifischer Dokumente. Der Wandel ging
in diesem Fall schnell vor sich. Bereits bei
der ersten Einführung eines Sprints lieferte
das Team beachtliche Ergebnisse. Das neue
Modell steigerte zudem schnell die Aufmerksamkeit,
welche die Mitarbeitenden
dem Testen widmeten. Scrum trug so zur
Qualitätssteigerung bei.
Die reibungslose Einführung ist umso bemerkenswerter,
als das Unternehmen an
drei verschiedenen Standorten entwickelt,
während Scrum vorsieht, dass das Team in
einem Raum arbeitet, um die Kommunikation
möglichst zu vereinfachen. Trotz
der Distanz wurde aber an den wesentlichen
Punkten des Prozesses festgehalten.
Das Daily Scrum Meeting findet auch in
diesem Unternehmen statt, allerdings in
Form einer Telefonkonferenz. Die notwendigen
Sitzungen am Anfang und am Ende
jedes Sprints werden dann als gemeinsame
Meetings durchgeführt. Alle drei Wochen
kommt das gesamte Team so für zwei Tage
an einem Ort zusammen.
Wie die beiden Beispiele zeigen, lässt sich
Scrum in sehr verschiedenen Organisationen
nutzbringend einführen. Dennoch ist
das Modell nicht in jedem Fall die beste

Da Scrum neue Rollen in eine Organisation einführt, ist durch die Veränderung auch das Selbstverständnis
der Mitarbeitenden in Bezug auf ihre Aufgabe und ihre Position betroffen. Deswegen müssen die Mitglieder
des Einführungsteams nicht zuletzt auch über ausgeprägte Soft Skills verfügen.
35
30
25
20
15
10
5
0
Product
Vision
Product
Backlog
Sprint
Planning 1
01. 01. 2010
02. 01. 2010
03. 01. 2010
04. 01. 2010
05. 01. 2010
06. 01. 2010
07. 01. 2010
08. 01. 2010
09. 01. 2010
10. 01. 2010
11. 01. 2010
12. 01. 2010
13. 01. 2010
14. 01. 2010
15. 01. 2010
16. 01. 2010
17. 01. 2010
18. 01. 2010
19. 01. 2010
20. 01. 2010
21. 01. 2010
22. 01. 2010
23. 01. 2010
24. 01. 2010
25. 01. 2010
26. 01. 2010
27. 01. 2010
28. 01. 2010
29. 01. 2010
30. 01. 2010
Wahl. Vor allem bei der Entwicklung von
Produkten, die einer strengen Regulierung
unterworfen sind, ist das unbürokratische
Vorgehen, das Dokumenten keinen zentralen
Platz einräumt, nicht optimal. Auf
der anderen Seite existieren auch Märkte,
in denen Scrum seine Vorteile voll ausspielen
kann. Dies ist vor allem dann möglich,
wenn sich die Technologie im Markt schnell
weiterentwickelt oder neue Geschäftsfelder
beschritten werden. In einem solchen Umfeld
ist die Flexibilität der Methode und die
mit ihr möglichen Tempo- und Qualitätssteigerungen
besonders wertvoll.
Sprint
Backlog
Sprint
Planning 2
Selected Product
Backlog
Daily Scrum
Meeting
Review
Product Increment
Retrospective
Ideal
Tatsächlich
Roland Oehen Kanzow
Kontakt: roland.oehenkanzow@erni-deutschland.de
Senior Consultant in der Firma ERNI (Deutschland) GmbH.
Beratertätigkeit: Agiles Projektmanagement mit Scrum,
Projektleitung, Requirements Engineering
Schneller und besser durch Agilität | Scrum
Abbildung 4:
Der Scrum Fluss
Abbildung 5:
Sprint Burndown Diagramm
für die Gegenüberstellung
der geplanten und der tatsächlichen
Geschwindigkeit
des Teams
7

Nearshoring | Mit Nearshoring den Aufschwung nutzen
Mit Nearshoring den Aufschwung nutzen
Outsourcing bringt Flexibilität und zusätzliches Know-how
Der sich abzeichnende Aufschwung bietet Chancen für innovative Produkte. Für die Entwicklung neuer Geräte und neuer Soft-
ware ist Outsourcing eine attraktive Option. Notwendig für das Gelingen der Auslagerung sind klar definierte Prozesse, eine inten-
sive Kommunikation mit dem externen Team und eine klare Unterstützung durch das Management. Von Philipp Rey und Christoph Krauer
8

Das Outsourcing von Entwicklungsaufgaben
ist für westeuropäische Unternehmen
beileibe nichts Neues. Geringere
Kosten und Agilität sind die Gründe für
eine Auslagerung. Doch die anziehende
Konjunktur macht die Option noch einmal
interessanter. Denn dadurch steigt
nicht nur das Interesse an neuen Produkten,
auch der Mangel an qualifizierten IT-
Fachleuten in westeuropäischen Ländern
verschärft sich bereits wieder.
Doch so naheliegend die Auslagerung von
Entwicklungsaufgaben momentan ist und
so alltäglich sie bereits zu sein scheint: Für
die Unternehmen stellt die Zusammenarbeit
mit externen Partnern in der Regel
einen grossen Schritt dar. Dies vor allem,
weil das eigene IT-Personal plötzlich Wissen
mit externen Dienstleistern teilen
muss, die sogar noch aus einem anderen
Land kommen. Dieses Wissen ist oft über
Jahrzehnte gewachsen und häufig durch
gezielte Geheimhaltung vor Nachahmern
geschützt worden.
Wegen dieses Kulturwandels dürfen Auslagerungsprojekte
nicht unterschätzt
werden. Sie sollten immer auch eine
Management-Angelegenheit sein. Insbesondere
muss entschieden werden, was
in Übereinstimmung mit der Strategie des
Unternehmens ausgelagert werden kann
und welches Know-how auf jeden Fall im
Unternehmen bleiben muss.
Darüber hinaus lässt sich der Einstieg ins
Outsourcing durch Nearshoring erleichtern.
Dies zum einen, weil das Rechtssystem
in Ländern wie Polen, Tschechien oder
der Slowakei dem EU-Standard entspricht.
Das geistige Eigentum ist von daher bes-
Mit Nearshoring den Aufschwung nutzen | Nearshoring
ser geschützt als in den meisten Ländern
Asiens. Hinzu kommt die ähnliche Kultur.
Sie bewahrt nicht nur vor bösen Überraschungen,
sondern erleichtert auch den
Aufbau der Kooperation und die Koordination
markant. Nicht zuletzt erleichtert aber
auch die geografische Nähe die Kooperation.
Da das externe Team nur wenige Flugstunden
entfernt arbeitet, kann man in der
Startphase oder auch bei Krisen schnell
Treffen anberaumen, um Missverständnisse
zu vermeiden oder zu beseitigen.
Beispiel 1
Entwicklung einer Plattform-Software
Ein Industrieunternehmen entwickelt
eine neue Generation einer Gerätefamilie
im mittleren Preissegment. Der Innovationszyklus
für die Produkte liegt bei mehreren
Jahren, so dass die Entwicklungskapazitäten
nur zeitlich begrenzt gebraucht
9

Nearshoring | Mit Nearshoring den Aufschwung nutzen
werden. Wegen der höheren Flexibilität,
aber auch aufgrund der geringeren Kosten,
entscheidet das Management, Teile der
Entwicklung in ein osteuropäisches Land
outzusourcen. Das kleine externe Team
wird für die Entwicklung der neuen Plattform-Software
herangezogen. Die zentrale
Einheit des Gerätes und das Betriebssystem
werden dagegen bewusst nicht outgesourct.
So ist sichergestellt, dass das Knowhow
im Bereich der Kernfunktionen der
Produkte inhouse bleibt. Das Projekt wurde
unterdessen erfolgreich abgeschlossen.
Zwei Faktoren waren für den Erfolg entscheidend:
die intensive Kommunikation
und die Definition des Prozesses.
Um die externen Entwickler mit dem notwendigen
Domänenwissen auszustatten,
holte das Unternehmen das gesamte Team
für eine Woche an den Firmensitz in die
Schweiz. Während des gesamten Projektverlaufs
wurde eine intensive Kommunikation
aufrechterhalten. So gab es täglich
Telefonate zwischen dem Hauptsitz und
dem Team in Osteuropa.
Neben der intensiven Kommunikation
war die saubere Definition der Kooperationsprozesse
von grosser Bedeutung. Um
eine reibungslose Kooperation zu gewährleisten,
wurden die Prozesse für die Zusammenarbeit
beschrieben sowie auf Deutsch
10
Die Requirements bilden bei agiler Arbeitsteilung die wichtigste Schnittstelle zwischen
dem Auftraggeber und dem externen Team. Ihre Qualität ist deswegen bei
Nearshoring Projekten matchentscheidend.
und Englisch dokumentiert. Zudem wurden
Qualitätsstandards definiert. Sie umfassten
auch die Festlegung von vorgeschriebenen
Tests samt der notwendigen
Protokolle und der Fehlerdokumentation.
Wie Beispiel 1 zeigt, sollten externe Entwickler
nur für einige Schritte des Projekts
zugezogen werden. Der Auftraggeber
selbst erarbeitet die Requirements und
legt die Architektur fest. Der Outsourcing-
Partner übernimmt die Arbeit vom Design
über die Implementation bis zu den
Unit-Tests. System- und Akzeptanztests
werden jedoch beim Auftraggeber selbst
durchgeführt. Dieser stellt dann auch den
Projektleiter, den Architekten, den Requirements-Manager
und den Testmanager.
Die Requirements bilden bei dieser Arbeitsteilung
die wichtigste Schnittstelle zwischen
dem Auftraggeber und dem externen
Team. Ihre Qualität ist deswegen matchentscheidend.
Unternehmen, die zum
ersten Mal auslagern, müssen auf diesen
Punkt entsprechend viel Gewicht legen.
Gerade auch sehr erfolgreiche Firmen aus
der Industrie verfügen oft über eingespielte
Teams und ein informelles Vorgehen, das
bei Inhouse-Entwicklungen zwar sehr effizient
sein kann, beim Outsourcing aber
schnell an Grenzen stösst. Denn das grosse
implizite Wissen, das für die internen Mit-
arbeitenden selbstverständlich ist, kennen
die externen Entwickler nicht. Um diese Herausforderung
zu meistern, kann man zum
Beispiel für jede Iteration einen Require-
ments-Workshop veranstalten, während
dem die externen Entwickler ihr Verständnis
der dokumentierten Anforderungen
vorstellen. So können Missverständnisse
erkannt und sofort ausgeräumt werden.
Gleichzeitig stärken die Workshops auch
das Vertrauen zwischen den Teams.
Eine höhere Prozessreife erleichtert die
Definition der Schnittstellen und der Kooperationsprozesse.
Doch in jedem Fall
existiert implizites Wissen, welches bei
Beginn der Kooperation explizit gemacht
werden muss. Kommunikation spielt
deswegen immer eine wichtige Rolle, wie
auch das folgende Beispiel zeigt.
Beispiel 2
Entwicklung
eines Informationssystems
Ein IT-Unternehmen entscheidet sich, ein
Informationssystem für das Management
zu entwickeln. Ziel ist die Entlastung der
Führungspersonen von administrativem
Aufwand. Man entscheidet sich aus Kostengründen
für Nearshoring.
Die Prozessreife der Firma ist hoch. Der Entwicklungsprozess
ist detailliert beschrieben,

und sämtliche Dokumente existieren in
englischer Sprache. Dennoch wird grosser
Wert auf die Schulung der externen Mitarbeitenden
gelegt. So besuchen diese ein
Training zum Entwicklungsprozess, den das
Unternehmen selbst aufgebaut hat. Zudem
existiert in diesem Fall wie auch beim ersten
Beispiel implizites Wissen. Für die Mitarbeitenden
der Firma ist selbstverständlich, wie
welche Dokumente ausgefüllt werden sollen.
Werden entsprechende Aufgaben an
andere Teams ausgelagert, muss man dieses
Wissen ebenfalls explizit machen, um nicht
im Verlauf des Projekts immer wieder Überraschungen
zu erleben.
Die Zusammenarbeit zwischen internen
und externen Mitarbeitenden war deshalb
in der Startphase entsprechend eng.
Das ERNI Team in der Slowakei
Die Texte zum Thema Nearshoring
in diesem ERNI Experience basieren
auf den Erfahrungen von ERNI als
Begleiter von Nearshoring-Projekten,
aber auch als Outsourcing-Partner.
Bereits seit einigen Jahren betreibt
ERNI einen Standort in Bratislava,
der Hauptstadt der Slowakei.
In Bratislava arbeiten hochqualifizierte
IT-Spezialisten – allesamt mit
Hochschulabschluss – vom Junior-
Entwickler bis hin zu sehr erfahrenen
und versierten Seniors. Sie befassen
sich sowohl mit der Entwicklung
neuer Produkte als auch mit derjenigen
von Softwaresystemen. Hinzu
kommt der Unterhalt von IT-Applikationen.
Die Projekte werden jeweils
in enger Zusammenarbeit mit
anderen ERNI Standorten oder direkt
beim Kunden tätigen ERNI Mitarbeitenden
abgewickelt. Die bewährten
Kompetenzen des Nearshoring-Centers
umfassen:
Gemeinsam legte man Prozesse und Qualitätsstandards
fest. Insbesondere wurden
auch die vorgeschriebenen Tests im Detail
definiert. Bei der eigentlichen Entwicklung
der Informationssoftware waren die
Verantwortlichkeiten klar aufgeteilt. Die
Spezifikationen wurden in der Schweiz
entwickelt. Für das Design, die Implementation
und die Tests bis zu den Systemtests
war das externe Team verantwortlich.
Beachtet man die Bedeutung der Definition
von Prozessen und Schnittstellen
sowie der Kommunikation, geht
die Einarbeitung der osteuropäischen
IT-Spezialisten meist schnell vor sich.
Denn sie verfügen meist über jahrelange
Erfahrung aus verschiedensten Projekten.
Sie arbeiten nicht nur zuverlässig an
• Architektur, Design, Implementation
und Testen von Software
• Überwachung, Wartung und Deployment
von operativen Applikationen
• Bereitstellung von IT-Services
• Project Management der Projekte
und Aufträge.
Erfahrungen bestehen darüber hinaus
in der flexiblen Reaktion auf Kapazitätsschwankungen,
unter anderem
durch die Möglichkeit, rasch am Arbeitsmarkt
und über das Netzwerk qualifizierte
Ressourcen zu rekrutieren. Zudem
ist der zügige Start neuer Projekte
für das Team Alltag. Dies nicht zuletzt
dank moderner Infrastruktur und etablierter,
agiler Prozesse.
Mit Nearshoring den Aufschwung nutzen | Nearshoring
ihren Aufgaben, sondern haben oft auch
noch Ideen zur Optimierung einer Neuentwicklung.
Wer dank intensiver Kommunikation
eine stabile Vertrauensbasis
zwischen diesen externen Spezialisten
und dem eigenen Team geschaffen hat,
wird auch diese Ideen nutzen können.
Das Nearshoring wird damit noch einmal
attraktiver.
Philipp Rey
Kontakt: philipp.rey@erni.ch
Business Unit Leader in der Firma ERNI Consulting AG.
Beratertätigkeit: Projektmanagement und SW-Architektur.
Christoph Krauer
Kontakt: christoph.krauer@erni.ch
Head Shared Service Center Bratislava & Business Unit Leader
in der Firma ERNI Management Services AG.
Beratertätigkeit: Nearshoring, Projektmanagement
und Business Integration.
11

Outtasking | Betrieb und Wartung reibungslos verlagern
Betrieb und Wartung reibungslos verlagern
Nearshoring senkt Kosten und erlaubt Konzentration auf Kernkompetenzen
Bei Wartung und Betrieb von IT-Applikationen ist Outsourcing attraktiv. Damit lässt sich einer der grössten Kostenblöcke in
der IT reduzieren. Gleichzeitig kann sich das eigene Personal wieder auf die wertschöpfenden kreativen Tätigkeiten konzentrieren.
Mit der richtigen Vorbereitung verlaufen die Übergabe und der weitere Betrieb reibungslos. Von Martin Sand und Heinz Schlatter
12
Agil zu sein, bedeutet, über Prozesse, Produkte
und eine Organisation zu verfügen,
die durch keine überflüssigen Elemente
gebremst werden und die sich schnell an
wechselnde Bedürfnisse und Lasten anpassen
können. Ein kostenoptimaler Betrieb
und eine entsprechende Wartung scheinen
sich nur schwer in dieses Konzept einfügen
zu lassen. Betrieb und Wartung stellen eine
Grundlast dar, die nicht stark schwankt
und schlicht getragen werden muss.
Dennoch: In der konkreten Situation vieler
IT-Organisationen kann die Auslagerung
die Agilität eines Unternehmens verbessern.
Dann nämlich, wenn die Entwickler
durch Routinearbeiten so sehr ausgelastet
sind, dass sich ihre Möglichkeiten, spontan
auf Anfragen und Spitzenbelastungen
zu reagieren, markant reduzieren.
Beispiel 1
Nearshoring von nächtlicher
Überwachungstätigkeit
Ein grosses Dienstleistungsunternehmen
verfügt über eine komplexe IT-Landschaft.
In der Nacht werden Batch-Jobs abgearbeitet.
Die Abarbeitung und der erfolgreiche
Abschluss der Batch-Jobs müssen
permanent überwacht werden, da einige
Jobs nur einmal pro Woche laufen. Tritt
ein Problem auf, muss sichergestellt werden,
dass die Jobs noch in der gleichen
Nacht erledigt werden. Zudem müssen
Fehler dokumentiert und weitergemeldet
werden, so dass Massnahmen zu ihrer
Behebung eingeleitet werden können.
Die Überwachung wird von Entwicklern
übernommen. Die Doppelbelastung durch
die Routinearbeiten und die nächtliche
Überwachung ist mit der Zeit gewachsen
und relativ hoch.
Um die Entwickler von den Routineaufgaben
zu entlasten und gleichzeitig die
Kosten zu reduzieren, beschloss das
Management, die Überwachung per
Nearshoring outzusourcen. Bei der Auslagerung
in ein osteuropäisches EU-
Mitgliedsland ging man planmässig vor.
Gemeinsam mit einem kompetenten
Outsourcing-Partner ergänzte man die
Definitionen und die Dokumentationen
der Überwachungsprozesse. Besonders
viel Wert wurde zudem auf das Training
der externen Mitarbeitenden gelegt.
Nicht zuletzt musste man sicherstellen,
dass ihr Wissen über das System und
ihre Aufgaben immer mit den neuesten
Erkenntnissen ergänzt wurden. Man hat
die externen Mitarbeitenden deshalb in
die interne Kommunikation der Organisation
integriert.
Zusammen mit einem Partner konnte
das Unternehmen die Herausforderungen
meistern. Innerhalb weniger Wochen wurde
die Überwachung ausgelagert. Ein erster
Review drei Monate nach dem operativen
Start ergab ein positives Ergebnis. Veränderungsbedarf
sah man nur bei einem Punkt:
Die externen Mitarbeitenden sollten mehr
Zahlen für das Reporting liefern.
Ein erster Schlüssel zum Erfolg bei Outsourcing-Aktivitäten
ist, wie im geschilderten
Beispiel, das Training der neuen
externen Mitarbeitenden. Sie sollten einige
Zeit vor Ort beim auslagernden Unternehmen
arbeiten. Auf diese Weise sind sie
in den täglichen Ablauf eingebunden und
lernen das System sowie ihre Aufgabe im
täglichen Betrieb kennen. Damit können
sie sich optimal mit ihrer zukünftigen Arbeit
vertraut machen.

Betrieb und Wartung reibungslos verlagern | Outtasking
Agil zu sein, bedeutet, über Prozesse, Produkte und eine Organisation zu verfügen,
die durch keine überflüssigen Elemente gebremst werden und die sich
schnell an wechselnde Bedürfnisse und Lasten anpassen können.
13

Outtasking | Betrieb und Wartung reibungslos verlagern
Wegen der grossen Bedeutung der Kommunikation ist Nearshoring häufig der Auslagerung nach Fernost überlegen. Die
kürzeren Distanzen erlauben häufigere Treffen. Zudem befindet man sich in der gleichen Zeitzone. Die ähnliche Kultur
erleichtert die Kommunikation und den Vertrauensaufbau. Kommt hinzu, dass gerade in Osteuropa viele kompetente IT-
Mitarbeitende sogar deutsch sprechen.
14
Das Training vor Ort ist zudem von Bedeutung,
weil es Vertrauen aufbaut zwischen
den externen Mitarbeitenden und
der auslagernden IT-Organisation. Solche
Massnahmen zur Teambildung erleichtern
später die Zusammenarbeit zwischen den
räumlich getrennten Personen markant.
Wegen der grossen Bedeutung der Kommunikation
ist Nearshoring häufig der
Auslagerung nach Fernost überlegen.
Die kürzeren Distanzen erlauben häufigere
Treffen. Zudem befindet man sich
in der gleichen Zeitzone. Die ähnliche
Kultur erleichtert die Kommunikation
und den Vertrauensaufbau. Kommt hinzu,
dass gerade in Osteuropa viele kompetente
IT-Mitarbeitende sogar deutsch
sprechen. Trotz der räumlichen und kulturellen
Nähe empfiehlt es sich, als Leiter
für das Auslagerungsprojekt eine Person
zu wählen, welche die IT-Branche sowohl
in westlichen Ländern wie auch im ausgewählten
osteuropäischen Staat kennt.
Einschlägige Erfahrungen helfen vor allem
bei der Auswahl des Teams, das letztendlich
mit den Arbeiten betraut wird.
Der dritte Schlüssel zum Erfolg neben der
Kommunikation und der Auswahl des externen
Teams ist die klare Definition der
Prozesse, bei denen man kooperieren will.
Für die Auslagerung von Wartung und
Betrieb ist wie bei der Auslagerung von
Entwicklungsarbeiten entscheidend, dass
die Prozesse und die Schnittstellen sauber
definiert und dokumentiert sind. Fast immer
besteht in dieser Hinsicht am Anfang
des Projekts Optimierungsbedarf. Deswegen
beginnen Auslagerungsprojekte in
der Regel mit einer Prozessverbesserung,
wie das folgende Beispiel zeigt.
Beispiel 2
Auslagerung des Service Desks
Ein schnell wachsendes Dienstleistungsunternehmen
hat beschlossen, sein internes
Service Desk auszulagern. Man entschied
sich in diesem Fall für Nearshoring.
Übernommen wurden die Aufgaben von
einem kleinen Team in der Slowakei. Das
Service Desk soll als zentrale Anlaufstelle
zum einen vordefinierte Service Requests
abarbeiten, etwa beim Eintritt neuer Mitarbeitender
oder bei einem Wechsel von
Rechnern. Zum anderen hat es die Aufgabe,
auf bestimmte Vorfälle im IT-Netzwerk
des Unternehmens zu reagieren, etwa auf
den Ausfall eines Druckers.
Die Firma musste in diesem Fall die Prozesse
beschreiben und gut dokumentieren.
Dabei wurde insbesondere darauf
geachtet, dass wenig Overhead entsteht.
Insbesondere galt es, den Aufwand der
Kommunikation zwischen den betroffenen
Mitarbeitenden und dem Service
Desk zu begrenzen. Zudem ist es aufgrund
des schnellen Wachstums des Unternehmens
von Bedeutung, dass die Prozesse
gut skalieren. In Service Level Agreements
(SLA) wurden die Leistungen des Service
Desks im Detail vereinbart.
Dank der gezielten Definition der Prozesse
ging die Auslagerung reibungslos vor
sich. Das Service Desk ist seit längerer Zeit
operativ und hat sich gut bewährt. Eher
noch komplexer war die Ausgangssituation
in Beispiel 1. Viel Wissen über die
komplexe IT-Landschaft steckte in den
Köpfen der Mitarbeitenden. Man musste
die Dokumentation ergänzen und darauf
aufbauend Prozesse für die externen Mitarbeitenden
definieren. Bei einer solchen
Prozessverbesserung ist es wichtig, dass
man pragmatisch vorgeht und nur so weit
optimiert, wie es für das Ziel der Auslagerung
notwendig ist. In Auslagerungsprojekten
sind deswegen Know-how und Erfahrung
in Prozessverbesserungen gefragt.
Momentan ist der richtige Zeitpunkt für Auslagerungen.
Wer jetzt Routinearbeiten an
günstige Drittanbieter vergibt, kann nicht
nur die Betriebs- und Wartungskosten seiner
IT reduzieren. Er setzt auch Mittel und interne
Ressourcen frei, die für die Entwicklung
neuer Produkte oder Angebote eingesetzt
werden können. Mit dieser Strategie lässt
sich der Schwung der Konjunkturerholung
voll für die eigene Organisation nutzen.

Momentan ist der richtige Zeitpunkt für Auslagerungen. Wer jetzt Routinearbeiten an
günstige Drittanbieter vergibt, kann nicht nur die Betriebs- und Wartungskosten seiner
IT reduzieren. Er setzt auch Mittel und interne Ressourcen frei, die für die Entwicklung
neuer Produkte oder Angebote eingesetzt werden können.
Martin Sand
Kontakt: martin.sand@erni.ch
Senior Consultant in der Firma ERNI
Consulting AG.
Beratertätigkeit: Projekt-/Produktmanagement
und Business Analysis.
Heinz Schlatter
Kontakt: heinz.schlatter@erni.ch
Corporate Unit Leader in der Firma
ERNI Consulting AG.
Beratertätigkeit: IT-Service-Management
und Process Improvement.
Betrieb und Wartung reibungslos verlagern | Outtasking
15

Architekturreview | Wie viel Qualität braucht ein IT-System?
Wie viel Qualität braucht ein IT-System?
Ein Architekturreview sorgt für Durchblick
Ein IT-System muss die gestellten Anforderungen erfüllen. Alles, was darüber hinausgeht, erhöht neben dem Aufwand auch
die Komplexität, ohne einen zusätzlichen Mehrwert zu bieten. Während dies beim Funktionsumfang meist berücksichtigt
wird, werden im Bereich der qualitativen Anforderungen wie Performance, Sicherheit oder Wartbarkeit – im Widerspruch
zu einem agilen Vorgehen – häufig Dinge umgesetzt, die so gar nicht benötigt werden. Ein Architekturreview kann überflüssige,
aber natürlich auch ungenügend berücksichtigte Anforderungen aufdecken. Von Oliver Blindenbacher
16
Je mehr Qualität, desto besser! Klingt
einfach und einleuchtend. Doch bei IT-
Lösungen geht diese Formel oft nicht
auf. Denn je höher die Performance, die
Ausfallsicherheit oder der Schutz vor Eindringlingen
ist, desto komplexer wird das
System. Das bedeutet mehr Aufwand bei
der Dokumentation, der Wartung und bei
allfälligen Erweiterungen. Mit anderen
Worten: ein teurer Spass. Die sinnvolle
Alternative dazu ist ein agiles Vorgehen
beim Aufbau der Softwarearchitektur.
Dabei lautet die Devise: So viel Qualität
wie nötig – aber nicht mehr.
Die Entscheide, die während der Erstellung
der Softwarearchitektur gefällt werden,
bestimmen darüber, welche qualitativen
Anforderungen erfüllt werden und
inwieweit eine Lösung bedarfsgerecht ist.
Fehler und falsche Entscheide haben oft
gravierende Auswirkungen und können
ein System sogar unbrauchbar machen.
Im Zweifelsfall lohnt es sich deshalb, die
Architektur einer Prüfung zu unterziehen,
am besten durch unabhängige Spezialisten
von aussen. Denn intern sind
Probleme oft blinde Flecken – oder sie
sind bekannt, können aber nicht glaubhaft
ans Management vermittelt werden.
Das Mittel zur Prüfung – der Architekturreview
– verursacht wenig Aufwand,
wirkt sich aber langfristig positiv auf die
Kosten eines Systems aus.
Ein Architekturreview dient zur Evaluation
von Architekturentscheiden bei neu
zu entwickelnden Applikationen, aber
auch bei Erweiterungen von bisherigen
Anwendungen. Zudem kann er relevante
Lücken in der bestehenden Dokumentation
aufzeigen.

Vorgehen
Architecture Tradeoff Analysis Method
oder kurz ATAM – so nennt sich eine bei
Architekturreviews häufig angewandte
Evaluationsmethode. Es ist ein Vorgehen
in vier Schritten:
1. Festlegung der Qualitätsziele
Dabei spielen Szenarien die zentrale
Rolle, sie konkretisieren die qualitativen
Anforderungen (siehe Abb. 2).
In Bezug auf die Performance eines
neuen IT-Systems könnte ein solches
Szenario zum Beispiel lauten: «Das
Öffnen eines umfangreichen Dokuments
darf nicht länger dauern als
bisher.» Die durch die Szenarien präzisierten
Ziele werden bewertet sowie
nach Wichtigkeit (aus Businesssicht)
und nach Komplexität (aus technischer
Sicht) priorisiert. Es geht grundsätzlich
um die Frage: Was ist wichtig, was ist
weniger wichtig?
2. Analyse der Architektur
Als Basis dazu dienen hauptsächlich
die Dokumentation sowie Interviews
und Gespräche mit dem Architekten
und weiteren Stakeholdern. Je nach
Situation wird auch der Source-Code
herangezogen. Dies hat sich in der
Praxis als hilfreich herausgestellt.
Denn geschulte Architekten oder Entwickler
können so schnell beurteilen,
ob die Applikation nach Best Practices
entwickelt wurde. Ein weiterer Bestandteil
der Analyse sind sogenannte
«Walkthroughs»: Ein bestimmtes
Szenario wird gedanklich durchgespielt.
Dabei wird geprüft, ob die involvierten
Komponenten die notwendigen
Eigenschaften erfüllen.
3. Identifikation von Risiken, Nicht-Risiken
und Trade-offs
Sind die Risiken bekannt, weiss man
auch, wie mit ihnen umgehen. So
Wie viel Qualität braucht ein IT-System? | Architekturreview
lassen sich Vorschläge für Massnahmen
erarbeiten: Wie können wir das
Risiko reduzieren oder eliminieren?
Wie hoch ist die Eintretenswahrscheinlichkeit?
Doch auch die Nicht-Risiken wollen
aufgezeigt sein. Das erspart unnötige
Sorgen. Unter «Trade-offs» versteht
man Qualitätsziele, die sich
widersprechen, also z.B. hohe Performance
vs. hohe Sicherheit. Tradeoffs
erfordern stets Entscheide und
Kompromisse.
4. Bewertung der Architektur
Die Ergebnisse, ergänzt mit Vorschlägen
für konkrete Massnahmen, werden
in einer abstrahierten und auch
für Nicht-Techniker verständlichen
Form präsentiert.
17

Architekturreview | Wie viel Qualität braucht ein IT-System?
18
Abbildung 1:
Allgemeines Vorgehen
zur Architekturbewertung
Abbildung 2:
Ausschnitt aus
einem Qualitätsbaum
mit zwei Szenarien
Ein Architekturreview soll mögliche Gefahrenherde identifizieren und Gegenmassnahmen
vorschlagen.
Qualitätsmerkmale
1. Geschäftsziele
präsentieren
2. Architektur
präsentieren
Performance
3. Qualitätsbaum
erstellen
4. Qualitätsattribute
bewerten
5. Szenarien
identifizieren
und priorisieren
6. Architekturansätze
identifizieren
Latenz
Durchsatz
Beispiel 1
Entscheidungsgrundlage
für Weiterentwicklungen
Ein Medizintechnikunternehmen verfügt
über zwei Produktlinien, eine neue für ein
vorerst kleines System und eine etwas ältere
für grosse Systeme. Es stellt sich die Frage,
auf welcher Basis neue Produkte entwickelt
werden sollen. Nimmt man das Alter als Kriterium,
spricht alles für die neue Software.
Doch herrscht im Unternehmen allgemein
ein ungutes Gefühl: Die neuen Geräte erweisen
sich in der Praxis immer wieder als
fehleranfällig und sind zudem schlecht
erweiterbar. Die Bedienoberfläche der älteren
Produkte ist zwar optisch etwas aus der
Mode gekommen, aber die Produkte selbst
sind sehr robust und sauber aufgebaut. Um
der Sache auf den Grund zu gehen und die
richtige Entscheidung zu treffen, lässt das
Unternehmen von externen Spezialisten einen
Architekturreview durchführen.
Die Spezialisten analysieren die Dokumentationen
der beiden Systeme, aber auch
den Code selbst. Zudem führen sie Inter-
Relevanz Kosten
(M, L) Antwortzeit < 1s
(M, H) > 1000 Benutzer
Sensitive
Punkte und
Kompromisse
7. Analyse Nicht-Risiken
Risiken
Aktivitäten
Artefakte
views mit mehreren Stakeholdern, darunter
Architekten, Entwickler, Produktmanager
und Mitarbeitende, die für die Wartung
zuständig sind. Das Ergebnis bestätigt den
ersten Eindruck: Das ältere System ist die
bessere Basis für Weiterentwicklungen.
Der Architekturreview hat dem Unternehmen
eine Strategie für die Zukunft aufgezeigt:
die Entwicklung eines neuen User-
Interface-Layers und ein schrittweises
Reengineering der älteren Technologie.
Beispiel 2
Architekturreview
vor globalem Rollout
Ein global tätiges Dienstleistungsunternehmen
plant, eine regional verwendete
Software global auszurollen. Das Management
weiss, dass dies neue Risiken mit sich
bringt. Ein Architekturreview soll deshalb
die möglichen Gefahrenherde identifizieren
und Gegenmassnahmen vorschlagen.
Als Risiken erweisen sich insbesondere die
geringe Dokumentationstiefe und kom-

plexe, nicht nach gängigen Standards umgesetzte
Komponenten. Letztere führen
zwar zu einer leicht besseren Performance,
doch im System ist dies weder spür- noch
nutzbar. Erstere ist eine Quelle von Fehlern
und Missverständnissen: Was von den Entwicklern
falsch verstanden wird, führt zu
redundantem oder falsch angewandtem
Code. Gleichzeitig wird durch den Review
aber auch klar, welche Qualitätsziele keine
Risiken bergen. Dass die Netzwerkperformance
für die Benutzer nur während
bestimmten Operationen von Bedeutung
ist, ist für die Akzeptanz des Systems von
grosser Bedeutung. Die Ergebnisse werden
grafisch dargestellt. Das Management
kann sie problemlos nachvollziehen. Zudem
werden konkrete Empfehlungen abgegeben,
wie die identifizierten Risiken
entschärft werden können.
Der Architekturreview hat konkrete Probleme
und Massnahmen aufgezeigt sowie
Unsicherheiten beseitigt. Der zeitliche
Aufwand dafür betrug nur gerade drei
Wochen.
Fazit
Architekturentscheide haben weitreichende
Folgen. Dabei ist möglichst schnell, sicher
oder erweiterbar nicht immer wünschenswert,
da die damit verbundene
Systemkomplexität zu mehr Aufwand bei
späterer Weiterentwicklung oder Fehlersuche
führt. Stattdessen empfiehlt sich
ein agiles Vorgehen: Man setzt nur diejenigen
Anforderungen um, die man wirklich
benötigt. Ein Architekturreview hilft
dabei, die richtigen Entscheide zu treffen,
und liefert einem Unternehmen wichtige
Hinweise für das Erreichen von Qualitätszielen.
Zudem verursacht eine solche Prüfung
verhältnismässig wenig Aufwand,
wie die Beispiele gezeigt haben.
Voraussetzung für schnelle und gehaltvolle
Ergebnisse ist ein kompetentes Review-
Team, das über die nötigen Soft Skills
verfügt. Denn einerseits muss es auf einer
vertrauensvollen Basis mit dem betreffenden
Architekten zusammenarbeiten können.
Andererseits existieren in Unternehmen
oft unterschiedliche Meinungen über
die Risiken bestimmter IT-Lösungen. Da
muss das Review-Team in der Lage sein,
mit allen Beteiligten zielführend zu kommunizieren
und zu einem unparteiischen
Urteil zu kommen. In der Regel erfüllt ein
externes Team diese Voraussetzungen besser
als ein Team von Mitarbeitenden des
betreffenden Unternehmens.
Oliver Blindenbacher
Kontakt: oliver.blindenbacher@erni.ch
Senior Consultant in der Firma ERNI Consulting AG.
Beratertätigkeit: Architektur, Design
und Development sowie Requirements Engineering.
Wie viel Qualität braucht ein IT-System? | Architekturreview
Architekturentscheide haben weitreichende
Folgen. Dabei ist möglichst
schnell, sicher oder erweiterbar nicht
immer wünschenswert, da die damit
verbundene Systemkomplexität zu mehr
Aufwand bei späterer Weiterentwicklung
oder Fehlersuche führt.
19

ERNI Consulting AG
Casinoplatz 2 · CH-3011 Bern · Tel. +41 31 381 76 11
Talstrasse 82 · CH-8001 Zürich · Tel. +41 44 215 42 00
Bahnhofstrasse 4 · CH-6340 Baar · Tel. +41 41 227 35 00
ERNI (Deutschland) GmbH
Orleansstrasse 34 · D-81667 München · Tel. +49 89 6228 6788 0
ERNI (Slovakia) s.r.o.
Ševcenkova 34 · SK-851 01 Bratislava · Tel. +421 2 3255 37 37
www.erni.ch · info@erni.ch
www.erni.ch/experience