Scrum Agile Produktentwicklung mit Scrum Nearshoring

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
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
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
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.
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
Herzlich
Reto Tschudi
Inhalt | ERNI Experience
Inhalt
Scrum
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.
Nearshoring
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.
Outtasking
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.
Architekturreview
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
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.
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
Scrum setzt grundsätzlich auf einen auch durch einen kontinuierlichen Verbesanderen Prozess und auf andere Rol- serungsprozess gekennzeichnet.
len als traditionelle Vorgehensmodelle. Ein wichtiges Element von Scrum Neben den Teammitgliedern existieren
ist der sogenannte Sprint (siehe Abb. 1). zwei weitere Rollen: der Product Owner
Damit werden zwei- bis vierwöchige Itera- und der ScrumMaster. Der Product Owner
tionen bezeichnet, an deren Ende ein funk- ist für die Strategie des Entwicklungspro-
4
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
Schneller und besser durch Agilität | Scrum
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
Meetings
Dokumente
Rollen
•Iteration mit fixer
Länge
•Geschützt
•Pull statt Push
•Inspect – Adapt
•Sprint Planning
•Sprint Review
•Retrospective
•Daily Scrum
•Product Backlog
•Sprint Backlog
•Burn Down Chart
•Release Plan
•Product Owner
•ScrumMaster
•Team
Abbildung 1:
Elemente von Scrum
Product
Backlog
Product
Vision
Product
Increment
Sprint
Backlog
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-
Daily Scrum
Meeting
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
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
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.
Gibt es dabei irgendwelche Hindernisse?
Was soll bis zum nächsten Treffen erreicht werden?
Was wurde seit dem letzten Treffen gemacht?
Fragen
•Daily Scrum Meeting,
15 Minuten jeden
Tag zur gleichen Zeit
am gleichen Ort
•Es werden drei
Fragen beantwortet,
reihum durch die
Teammitglieder
Abbildung 3:
Daily Scrum Meeting
leiter kommt dabei die zentrale Bedeu- Einführung immer wieder auftauchenden
tung zu. Er plant die Projekte, definiert Herausforderungen lassen sich mit ErfahArbeitspakete und legt die Dauer für ihre rung auch besser und schneller meistern.
Erledigung fest.
Da Scrum neue Rollen in eine Organisation
Um die Time-to-Market zu beschleuni- einführt, ist durch die Veränderung auch
gen, beschliesst das Unternehmen, Scrum das Selbstverständnis der Mitarbeitenden
einzuführen. Dieses Ziel wurde erreicht. in Bezug auf ihre Aufgabe und ihre PosiDie Umstellung bewirkte, dass das Unter- tion betroffen. Deswegen müssen die Mitnehmen schneller auf die aktuelle Markt- glieder des Einführungsteams nicht zuletzt
situation reagieren kann. Neuartige Funk- auch über ausgeprägte Soft Skills verfügen.
tionalitäten vergleichbarer Plattformen Die besondere Bedeutung des Verändekönnen wesentlich schneller auch für das rungsprozesses für die betroffenen Mitarbeiter legt den Beizug externer Experten für
eigene Angebot realisiert werden.
das Einführungsteam nahe. Diese können
Der Wandlungsprozess hat rund ein Jahr in auftauchende Konflikte wesentlich besser
Anspruch genommen. In dieser Zeit wur- konstruktiv lösen als Personen mit einer
den die Mitarbeitenden zum Teil intensiv langen Geschichte in der Organisation.
gecoacht und betreut. So gab es etwa Vieraugengespräche, in denen das neue Modell Nicht in jedem Fall sind allerdings die weiund die Gründe der Einführung vorgestellt chen Faktoren die entscheidende Herauswurden. Darüber hinaus wurde die Team- forderung bei der Einführung von Scrum.
bildung unterstützt, beispielsweise mit Denn es gibt auch Entwickler, welche die
einem Wochenende in einem Sporthotel. Freiheit, die ihnen das Modell bringt, zu
Nicht zuletzt konnten die Mitarbeitenden schätzen wissen. Dennoch sind auch in
den Wandlungsprozess mitgestalten. Die solchen Unternehmen vielfach AnpassunScrum-Teams wählten sich zum Beispiel gen bei der Einführung notwendig.
ihre Mitglieder selbst aus.
Beispiel 2
Da der Einführungsprozess von Scrum Scrum bei verteilten
eine Organisation grundlegend verän- Entwicklungsstandorten
dern kann, sind die Anforderungen an das Ein IT-Unternehmen entwickelt eine
Projektteam entsprechend hoch. Es muss Standardsoftware in einem Markt mit inScrum beherrschen und sollte zudem über tensivem Wettbewerb. In diesem Markt
Erfahrung mit Veränderungsprozessen ver- positioniert sich das Unternehmen als
fügen. Denn der Prozess muss nicht nur Technologieführer. Um der Herausfordemassgeschneidert werden, die während der rung des schnellen Innovationsrhythmus
6
•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
Schneller und besser durch Agilität | Scrum
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.
Product
Vision
Sprint
Backlog
Daily Scrum
Meeting
Sprint
Planning 2
Review
Product Increment
Product
Backlog
Selected Product
Backlog
Sprint
Planning 1
Retrospective
Abbildung 4:
Der Scrum Fluss
35
Ideal
30
Tatsächlich
25
20
15
10
5
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
0
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.
Abbildung 5:
Sprint Burndown Diagramm
für die Gegenüberstellung
der geplanten und der tatsächlichen Geschwindigkeit
des Teams
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
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 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. Von Philipp Rey und Christoph Krauer
8
Mit Nearshoring den Aufschwung nutzen | Nearshoring
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 ITFachleuten in westeuropäischen Ländern
verschärft sich bereits wieder.
Land kommen. Dieses Wissen ist oft über
Jahrzehnte gewachsen und häufig durch
gezielte Geheimhaltung vor Nachahmern
geschützt worden.
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.
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
Doch so naheliegend die Auslagerung von und welches Know-how auf jeden Fall im
Entwicklungsaufgaben momentan ist und Unternehmen bleiben muss.
Beispiel 1
so alltäglich sie bereits zu sein scheint: Für
Entwicklung einer Plattform-Software
die Unternehmen stellt die Zusammenar- Darüber hinaus lässt sich der Einstieg ins Ein Industrieunternehmen entwickelt
beit mit externen Partnern in der Regel Outsourcing durch Nearshoring erleich- eine neue Generation einer Gerätefamilie
einen grossen Schritt dar. Dies vor allem, tern. Dies zum einen, weil das Rechtssys- im mittleren Preissegment. Der Innovatiweil das eigene IT-Personal plötzlich Wis- tem in Ländern wie Polen, Tschechien oder onszyklus für die Produkte liegt bei mehsen mit externen Dienstleistern teilen der Slowakei dem EU-Standard entspricht. reren Jahren, so dass die Entwicklungskamuss, die sogar noch aus einem anderen Das geistige Eigentum ist von daher bes- pazitäten nur zeitlich begrenzt gebraucht
9
Nearshoring | Mit Nearshoring den Aufschwung nutzen
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.
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.
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 OutsourcingPartner ü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 RequiUm die externen Entwickler mit dem not- rements-Manager und den Testmanager.
wendigen Domänenwissen auszustatten,
holte das Unternehmen das gesamte Team Die Requirements bilden bei dieser Arbeitsfür eine Woche an den Firmensitz in die teilung die wichtigste Schnittstelle zwiSchweiz. Während des gesamten Projekt- schen dem Auftraggeber und dem externen
verlaufs wurde eine intensive Kommuni- Team. Ihre Qualität ist deswegen matchkation aufrechterhalten. So gab es täglich entscheidend. Unternehmen, die zum
Telefonate zwischen dem Hauptsitz und ersten Mal auslagern, müssen auf diesen
dem Team in Osteuropa.
Punkt entsprechend viel Gewicht legen.
Gerade auch sehr erfolgreiche Firmen aus
Neben der intensiven Kommunikation der Industrie verfügen oft über eingespielte
war die saubere Definition der Kooperati- Teams und ein informelles Vorgehen, das
onsprozesse von grosser Bedeutung. Um bei Inhouse-Entwicklungen zwar sehr efeine reibungslose Kooperation zu gewähr- fizient sein kann, beim Outsourcing aber
leisten, wurden die Prozesse für die Zusam- schnell an Grenzen stösst. Denn das grosse
menarbeit beschrieben sowie auf Deutsch implizite Wissen, das für die internen Mit-
10
arbeitenden selbstverständlich ist, kennen
die externen Entwickler nicht. Um diese Herausforderung zu meistern, kann man zum
Beispiel für jede Iteration einen Requirements-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,
Mit Nearshoring den Aufschwung nutzen | Nearshoring
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.
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.
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.
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.
Die Zusammenarbeit zwischen internen Denn sie verfügen meist über jahrelange
und externen Mitarbeitenden war des- Erfahrung aus verschiedensten Projekhalb in der Startphase entsprechend eng. ten. Sie arbeiten nicht nur zuverlässig an
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 JuniorEntwickler 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:
•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.
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
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.
12
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 EUMitgliedsland 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 ITMitarbeitende sogar deutsch sprechen.
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.
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.
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.
Momentan ist der richtige Zeitpunkt für Auslagerungen. Wer jetzt Routinearbeiten an
Beispiel 2
günstige Drittanbieter vergibt, kann nicht
Auslagerung des Service Desks
nur die Betriebs- und Wartungskosten seiner
Ein schnell wachsendes Dienstleistungs- IT reduzieren. Er setzt auch Mittel und interunternehmen hat beschlossen, sein inter- ne Ressourcen frei, die für die Entwicklung
nes Service Desk auszulagern. Man ent- neuer Produkte oder Angebote eingesetzt
schied sich in diesem Fall für Nearshoring. werden können. Mit dieser Strategie lässt
Übernommen wurden die Aufgaben von sich der Schwung der Konjunkturerholung
einem kleinen Team in der Slowakei. Das voll für die eigene Organisation nutzen.
14
Betrieb und Wartung reibungslos verlagern | Outtasking
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
Heinz Schlatter
Kontakt: heinz.schlatter@erni.ch
Senior Consultant in der Firma ERNI
Consulting AG.
Beratertätigkeit: Projekt-/Produktmanagement und Business Analysis.
Corporate Unit Leader in der Firma
ERNI Consulting AG.
Beratertätigkeit: IT-Service-Management und Process Improvement.
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
Je mehr Qualität, desto besser! Klingt
einfach und einleuchtend. Doch bei ITLö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.
16
Wie viel Qualität braucht ein IT-System? | Architekturreview
2. Analyse der Architektur
Vorgehen
Architecture Tradeoff Analysis Method Als Basis dazu dienen hauptsächlich
die Dokumentation sowie Interviews
oder kurz ATAM – so nennt sich eine bei
und Gespräche mit dem Architekten
Architekturreviews häufig angewandte
und weiteren Stakeholdern. Je nach
Evaluationsmethode. Es ist ein Vorgehen
Situation wird auch der Source-Code
in vier Schritten:
herangezogen. Dies hat sich in der
Praxis als hilfreich herausgestellt.
1. Festlegung der Qualitätsziele
Denn geschulte Architekten oder Ent Dabei spielen Szenarien die zentrale
wickler können so schnell beurteilen,
Rolle, sie konkretisieren die qualitaob die Applikation nach Best Practitiven Anforderungen (siehe Abb. 2).
ces entwickelt wurde. Ein weiterer BeIn Bezug auf die Performance eines
standteil der Analyse sind sogenannneuen IT-Systems könnte ein solches
te «Walkthroughs»: Ein bestimmtes
Szenario zum Beispiel lauten: «Das
Szenario wird gedanklich durchgeÖffnen eines umfangreichen Dokuspielt. Dabei wird geprüft, ob die inments darf nicht länger dauern als
volvierten Komponenten die notwenbisher.» Die durch die Szenarien prädigen Eigenschaften erfüllen.
zisierten Ziele werden bewertet sowie
nach Wichtigkeit (aus Businesssicht)
und nach Komplexität (aus technischer 3. Identifikation von Risiken, Nicht-Risiken
Sicht) priorisiert. Es geht grundsätzlich
und Trade-offs
um die Frage: Was ist wichtig, was ist Sind die Risiken bekannt, weiss man
weniger wichtig?
auch, wie mit ihnen umgehen. So
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?
Ein Architekturreview soll mögliche Gefahrenherde identifizieren und Gegenmassnahmen vorschlagen.
Aktivitäten
Qualitätsmerkmale
3. Qualitätsbaum
erstellen
1. Geschäftsziele
präsentieren
4. Qualitätsattribute
bewerten
5. Szenarien
identifizieren
und priorisieren
Abbildung 1:
Allgemeines Vorgehen
zur Architekturbewertung
2. Architektur
präsentieren
Artefakte
Sensitive
Punkte und
Kompromisse
7. Analyse
Nicht-Risiken
6. Architekturansätze
identifizieren
Risiken
Relevanz
Kosten
Latenz
Abbildung 2:
Ausschnitt aus
einem Qualitätsbaum
mit zwei Szenarien
Performance
Durchsatz
(M, H) > 1000 Benutzer
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-
18
(M, L) Antwortzeit < 1s
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 UserInterface-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-
Wie viel Qualität braucht ein IT-System? | Architekturreview
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.
Architekturentscheide
haben
weitrei-
chende 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.
Voraussetzung für schnelle und gehaltvolle Ergebnisse ist ein kompetentes ReviewTeam, 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.
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