Die Industrialisierung der Software-Entwicklung

Die Industrialisierung der Software-Entwicklung Frank Simon, SQS Software Quality Systems AG Bislang haben sich die meisten Unternehmen eine eigene IT-Abteilung geleistet. Diese hat durch klassisches Outsourcing schon länger und jüngst durch Cloud Computing Konkurrenz bekommen. Doch ist das ungeprüfte Outsourcing von bestimmten organisatorischen Aufgaben an Drittanbieter genauso risikobehaftet wie das Bildnachweis: Fotolia 1.1 Motivation In der Vergangenheit haben sich viele Unternehmen eine eigene IT-Abteilung für Software-Entwicklung mit nachfolgender Software-Wartung geleistet. Neben vielen technologischen Innovationen gab es bezüglich der Frage, wer in welcher Form Leistungen für das Business erbringt, vor allem zwei wesentliche Neuerungen: - das klassische Outsourcing, vom IT-Branchenverband BITKOM definiert als jegliche Art des Fremdbezugs von Dienstleistungen [1]. - Cloud-Computing, das heißt die Nutzung des Internets zur Leistungserbringung. Dabei sind die Services selbst skalierend implementiert (Nutzungs-Peaks können bedient werden) und werden benutzungsorientiert abgerechnet (nach Gartner [2]). unsystematische Nutzen der Cloud. Was kann derartigen Risiken vorbeugen? Was muss im eigenen Haus bleiben? Statt kurzfristiger, nicht nachhaltiger Maßnahmen bietet sich eine Langfriststrategie an: die Industrialisierung der Software-Entwicklung. KURZ UND BÜNDIG Nach dem klassischen Outsourcing haben interne IT-Abteilungen durch Cloud Computing weitere Konkurrenz bekommen. Mehr noch als beim klassischen Outsourcing bringt das Cloud Computing wegen seiner weiter vorangeschrittenen Standardisierung Risiken mit sich, wenn der Kunde nicht ebenfalls über standardisierte und qualitätsgemanagte Prozesse verfügt. Als langfristige Strategie bietet sich deshalb die Industrialisierung der Software-Entwicklung an. Sie wird auch die derzeitige Arbeitsteilung in der Software-Produktion wesentlich verändern. Stichworte: Cloud Computing, Software-Entwicklung, IT-Outsourcing, Industrialisierung, IT-Qualität IM Information Management und Consulting 03 2012 43

Bereits heute entfallen 7,1 Prozent des gesamten IT-Budgets auf Outsourcing [3]. Für 2020 sagen die IT-Analysten von PAC (Pierre Audoin Consultants) zum Beispiel voraus [4], dass 25 Prozent des gesamten Budgets auf Outsourcing entfallen, wobei dann bereits 70 Prozent über die Cloud erbracht sein werden. Beide Innovationen stellen Unternehmen vor folgende grundsätzliche Fragen: Wie kann ich mein Business mit reduzierter oder vollständig abgebauter eigener IT-Abteilung kosteneffizient durch eine andere externe IT unterstützen? Wie schaffe ich es, mich wieder auf mein Kernbusiness zu konzentrieren, ohne auf eine leistungsstarke IT verzichten zu müssen? Outsourcing und/oder Cloud-Computing stellen hierfür konkrete Möglichkeiten dar. Hierfür bedarf es aber zuvor der Beantwortung folgender Frage: Was sind die Vorbedingungen, um derartige Fragestellungen rund um die eigene IT-Abteilung beantworten zu können? Karl Benz zum Beispiel entwickelte neben dem ersten Benzinauto auch den Differentialantrieb, die Zündkerzen und den Wasserkühler. Die nachfolgenden Schritte zu den heutigen Prozessen werden als Industrialisierung bezeichnet. Industrialisierung beschreibt eine Kette von strategischen Zielen, die sequenziell erreicht werden müssen. Und exakt diese Zielkette hat ebenso für die IT Gültigkeit wie für die Automobilindustrie: Auch die IT muss einen Prozess der Industrialisierung durchlaufen, bevor über Outsourcing und Cloud nachgedacht werden kann. Die Industrialisierung ist damit eine typische Maßnahme des Risiko-Managements in Form einer Risiko-Reduktionstechnik. Um die Risiken der Nutzung von Outsourcing oder Cloud-Services zu reduzieren, sind damit entlang der Industrialisierung die folgenden fünf Schritte sequentiell zu durchlaufen. 1.3 Modularisierung 1.2 Industrialisierung Hier hilft ein Blick in das produzierende Gewerbe und dort vor allen Dingen in die Automobilbranche: Sie arbeitet höchst profitabel und hat trotzdem in neueren Automodellen nur noch 15 bis 20 Prozent der Wertschöpfungstiefe innerhalb der eigenen Firma Auch die IT muss einen Prozess der Industrialisierung durchlaufen, bevor über Outsourcing und Cloud nachgedacht werden kann. [5]. Den Rest erbringt ein globales Netz von Zulieferern, die zusammen eine weltweit umspannende Prozesskette implementieren. Und trotz dieses Trends genießt die Marke Made in Germany gerade in der Automobilbranche einen hohen Stellenwert. Die Automobilbranche hat dabei ähnlich angefangen wie die IT: Die ersten Autos wurden in Manufakturen händisch von den einzelnen Mitarbeitern bis zum fertigen Automobil gebaut. Die Wertschöpfungstiefe innerhalb der Unternehmen lag bei fast 100 Prozent: Der erste wichtige Schritt ist die Modularisierung: Um einen oder mehrere Produktions-Bereiche in einem Unternehmen überhaupt adressieren zu können, müssen sie erst einmal als solche bekannt sein. Wenn die einzige Sicht auf ein IT-Unternehmen diejenige ist, dass es eine Einheit gibt, die das alles irgendwie macht, dann ist die Cloud zum Beispiel keine Lösung, da sie eben gerade nicht alles irgendwie macht. Die Idee der Modularisierung ist es folglich, Business-Prozesse sowie die sie unterstützenden IT-Prozesse zu modellieren. Typische Beispiele für solche Modellierungsergebnisse sind Prozessübersichten (inkl. Abhängigkeiten) und Verantwortlichkeits-Matrizen: Erstere stellen Dekompositionen der gesamten Wertschöpfungskette dar: Eine Software-Entwicklung kann demnach zum Beispiel entlang des Prozessreferenzmodells CMMI in 21 Teilprozesse dekomponiert werden. Innerhalb jedes Teilprozesses hilft zum Beispiel eine RACI-Matrix zur Modellierung von Verantwortlichkeiten: Hierbei wird zwischen der Durchführungsverantwortung (Responsible), der Kostenverantwortung (Accountable), der Fachverantwortung (Consulted) und dem Informationsrecht (Informed) unterschieden. 44

Positivbeispiele für Modularisierung Gerade für die Software-Entwicklung und den Betrieb von IT-Systemen gibt es vorgefertigte Modularisierungsreferenzen. Für die Entwicklung haben sich beispielsweise sogenannte Prozessreferenzmodelle wie CMMI oder SPICE etabliert. Sie liefern ein Rahmenwerk von Prozessen, die üblicherweise in reifen Unternehmen Anwendung finden. Für den Betrieb existiert mit ITIL eine ähnliche Prozesslandschaft. Auch auf der nächsten Verfeinerungsebene gibt es teilweise bereits Modularisierungsreferenzen. So wird in TMMI beispielsweise die Aufgabe der Qualitätssicherung mit wohldefinierten Prozessen, Verantwortlichkeiten und Schnittstellen beschrieben. Alle Referenzmodelle haben den Zweck, für eine individuelle Modularisierung wiederverwendet werden zu können. Für eine etwaige Zertifizierung müssen sie sogar eingehalten sein. In jedem Fall bedeutet allein der Wunsch nach einer Zertifizierung die Arbeit an einer IT-Industrialisierung. Negativbeispiele für Modularisierung Negativbeispiele sind häufig, aber nicht nur, in kleinen und mittleren IT-Unternehmen zu finden. Typische Symptome sind kleinere Teams, in denen es weder prozessorale Vorgaben noch klare Verantwortlichkeiten gibt. Der Erfolg IT-relevanter Aktivitäten hat in solchen Unternehmen häufig einen starken Personenbezug: Wenn die richtigen Leute beteiligt sind, gelingt es. Sind diese nicht verfügbar (oder ist nicht klar, wer richtig ist), ist der Erfolg gefährdet. Aufgrund der fehlenden Modularisierung ist es für neue Mitarbeiter auch extrem schwierig, dort Fuß zu fassen, da sich die Gesamtaufgabe als monolithisch und hochkomplex darstellt. Erst eine Modularisierung ermöglicht, sich Schritt für Schritt über einzelne Prozesse einzuarbeiten. 1.4 Standardisierung Nachdem durch die Modularisierung eine Wertschöpfungslandkarte erstellt wurde und so der Gesamtprozess mittels Teile und herrsche in einfacher steuerbare Einheiten verfeinert wurde, kann damit begonnen werden, Redundanzen und Inkonsistenzen in der Modularisierung zu identifizieren. Dabei sollte auch eine begriffliche Standardisierung stattfinden: nämlich inhaltlich ähnliche Prozessglieder mit unterschiedlichen Namen namentlich zu vereinheitlichen. Redundante Prozessglieder werden so erkannt und sind anschließend gute Kandidaten für eine Zusammenführung. Da die Redundanz meist eher eine Die Automatisierung hat die Aufgabe, die Vielfalt der Eingabeparameter und der Ausgabeparameter vollständig zu erfassen. große Ähnlichkeit anstelle einer Gleichheit aufweist, ist hier eine Standardisierung nötig. Diese Standardisierung muss beide Prozessglieder unterstützen. Hierfür ist eine Dekomposition der Aufgabenschritte innerhalb eines Prozesses nötig: Dort können dann Gemeinsamkeiten ebenso modelliert werden wie Besonderheiten. Neben der Standardisierung der einzelnen Prozessketten sollten natürlich auch die Schnittstellen standardisiert werden. Denn ein Änderungsmanagement kann grundsätzlich die unterschiedlichsten Kanäle als Input akzeptieren: Telefoneingaben, E-Mails, Flurgespräche etc. Pro Kanal werden dann meist auch unterschiedliche Informationsmengen und -granularitäten übergeben. Während der Standardisierung werden sowohl die Kanäle als auch der Umfang und Typ der übergebenen Informationen standardisiert. Positivbeispiele für Standardisierung Bezüglich der Prozesse selbst sind auch hier wieder etablierte Prozessstandards wie CMMI oder ITIL zu nennen. Während die Modularisierung nur sicherstellt, dass eine Prozessmodellierung existiert, stellt die Standardisierung zum Beispiel einen engen Bezug zu solchen Standards her. Aufgrund der umfangreichen Literatur dazu wäre die Begrifflichkeit präzise definiert, es würde klar, dass keine Tätigkeitsfelder vergessen wären und es wäre für Außenstehende schnell möglich, sich zurechtzufinden. Eine Standardisierung bezüglich der Schnittstellen würde zum Beispiel bedeuten, dass Anforderungen grundsätzlich einem spezifischen Template genügen, dass Statusberichte 45

nicht jedes Mal ad hoc neu erstellt werden, sondern nur durch die Aktualisierung von Daten innerhalb eines abgestimmten Reporting-Dokuments entstehen und dass innerhalb eines Prozesses die Aktivitäten systematisch durchlaufen werden. Viele technische Automatisierungen leiden an einem fehlenden industrialisierten Unterbau. Negativbeispiele für Standardisierung Viele Organisationen tun sich mit einer Standardisierung sehr schwer. Dazu gehören unter anderem solche Firmen, die es über Jahre hinweg nicht schaffen, in Standards wie CMMI höhere Reifegrade zu erreichen. In solchen Unternehmen existiert zwar eine grundsätzliche Modularisierung. Aber spätestens jedes einzelne Projekt findet gute Gründe, warum es gerade in diesem einen Projekt ganz anders arbeiten muss: Es verwendet dann zwar sehr wohl eine Modularisierung, sie ist aber eben eine ganz spezifische, die keinerlei Synergien zu anderen Projekten erlaubt. Auch auf technischer Seite gibt es immer wieder Phänomene des Not invented here-syndroms, dem klassischen Gegenspieler der Standardisierung: So werden heute immer noch in Firmen eigene Werkzeuge für die Anforderungserfassung erstellt, eigene Bug-Tracking-Werkzeuge implementiert oder schwergewichtige Excel-Makros zur Erzeugung animierter Reports erstellt. Jede einzelne Lösung mag funktionieren, aber Industrialisierung funktioniert anders: Die Schrauben und Muttern in einem Auto sind eben in der Regel ebenso sechskantig und haben ein metrisches ISO-Gewinde (zum Beispiel M8 für die Schlüsselweite 13) wie die Schrauben im Hausbau oder dem Modellbau. 1.5 Automatisierung Mit der im vorherigen Schritt erfolgten Standardisierung können die einzelnen Prozessschritte als Automat beschrieben werden: Er zeichnet sich durch mehr oder weniger formale Eingabeparameter aus, die den Automaten zur Bearbeitung dieser Daten anstoßen. Das Ergebnis wird dann wieder ähnlich formal als Ausgangsparameter ausgegeben. Als Beispiel sei hier ein typischer Firmenparkplatz genannt: Als Eingabe- parameter kann hier ein einfahrendes Auto mit einem Fahrer bezeichnet werden, der seinen Firmenausweis zeigt. Diese Eingabeparameter führen dazu, dass der Pförtner die Daten prüft (evtl. den Dienstausweis und/oder das Fahrzeug) und anschließend die Schranke öffnet. Dies ist der formale Ausgabewert. Die Automatisierung hat die Aufgabe, die Vielfalt der Eingabeparameter und der Ausgabeparameter vollständig zu erfassen: Wenn ein Prozessschritt mal dieses und mal jenes als Eingangs-Parameter erhält und wenn ein Prozessschritt mal diesen und mal jenen Ergebnistyp erzeugt, beides jeweils noch erschwert durch unterschiedlichste Datentypen und Datenformate, dann ist eine Automatisierung kaum möglich. Wenn es allerdings, wie im Fall der Schrankenöffnung, bereits eine gute Standardisierung gibt, dann kann die Automatisierung vollendet werden, indem IT-Systeme die Prozessketten vollständig bearbeiten (im Parkbeispiel zum Beispiel durch Funkchips in den Firmenausweisen möglich). Die Idee der Automatisierung ist nicht, jeden Prozessschritt zu automatisieren, wohl aber solche, die kaum oder keiner menschlichen Interaktion bedürfen. Auch hier gilt: Automatisierung benötigt Standardisierung und Modularisierung. Positivbeispiele für Automatisierung Interessanterweise gibt es deutlich mehr Automatisierungsbeispiele als Standardisierungsbeispiele. Dies resultiert aus der starken Präsenz von Tool-Herstellern und ihren in Aussicht gestellten Versprechen: Workflow-Engines zum automatisierten Durchreichen von Informationen über verschiedene Stellen hinweg, Capture-Replay-Werkzeuge zur automatisierten Erfassung und Wiedergabe von Testfällen oder aber automatische Business-Intelligence-Suiten zur vollautomatischen täglichen Berichtserstellung. Werden diese Automatisierungen auf ein solides Industrialisierungsfundament gestellt, das heißt, es gibt wohl definierte und standardisierte Prozesse, innerhalb derer sie systematisch eingesetzt werden, so sind sie hervorragende Indikatoren für die Erreichung der nächsten Industrialisierungsebene. Negativbeispiele Sehr viel häufiger leiden diese technischen Automatisierungen allerdings an einem fehlenden indust- 46

rialisierten Unterbau. Dadurch fehlen die Prozesse, was wann automatisiert getestet werden soll, Workflow-Engines werden bewusst umgangen und die Business Intelligence-Ergebnisse werden vor dem finalen Weiterleiten manuell modifiziert ( pimp my report ). Ein weiteres Negativsymptom ist die Vielzahl von sogenannter Schrankware : Das sind teuer gekaufte Software-Lizenzen, die am Ende dann doch nicht eingesetzt werden. Bereits 2004 wurde dieser Umfang von der Meta Group auf 90 Milliarden Euro geschätzt [6]. Dies sind bei einem Gesamt-Budget für IT-Lizenzen in Höhe von 239 Milliarden Euro mehr als 30 Prozent und somit klassische Belege für gescheiterte Automatisierung. 1.6 Kompetenz-Fokussierung In einer solchen modularisierten, standardisierten und teilweise automatisierten Wertschöpfungskette lassen sich strategische Überlegungen anstellen und systematisch umsetzen: An welcher Stelle werden meine Alleinstellungsmerkmale in den Gesamtprozess induziert, die einen signifikanten Marktvorteil generieren? Was ist die Kernkompetenz meines Unternehmens heute und morgen? Was muss lediglich als unterstützende Funktion funktionieren und welche Bereiche sind mein Business-Treiber? An dieser Stelle kann erstmals über Wertschöpfungstiefe und Wertschöpfungsbreite nachgedacht werden. Jüngste Beispiele zeigen hier bereits für ausgewählte Prozessbereiche einige Erfolge. Einer Capgemini IT- Trend-Studie [7] zufolge ist zum Beispiel beim Infrastrukturmanagement die Eigenleistungstiefe von 60,9 Prozent im Jahr 2009 auf 49,6 Prozent 2010 gesunken. Entlang der Modularisierung ist offensichtlich die Bereitstellung einer IT-Infrastruktur mit nachfolgender Standardisierung soweit automatisierbar, dass dieser Bereich an externe Zulieferer ausgelagert werden kann. Bezüglich der Kompetenz-Fokussierung hat daher knapp die Hälfte der Unternehmen die strategische Entscheidung getroffen, dass die Bereitstellung einer IT-Infrastruktur (also noch nicht der darauf laufenden Applikationen) nicht zu ihren Kernkompetenz zählt. 1.7 Kontinuierliche Verbesserung In einer derart strukturierten Wertschöpfungslandkarte kann eine systematische Optimierung vorgenommen werden: Dies umfasst vor allen Dingen die fortwährende Beobachtung, ob hinzugekaufte Prozessschritte durch andere Anbieter besser/günstiger oder schneller angeboten werden. In diesen Bereich fällt insbesondere die Service Level Agreement-(SLA)- Erstellung, innerhalb derer Erwartungen an Zulieferer messbar hinterlegt werden, um so gegebenenfalls auch Malus/Bonus-Regelungen ermöglichen zu können. Eine solche Optimierung ist natürlich nur dann möglich, wenn es klare Anforderungsprofile an die zu liefernden Services gibt. Erst wenn die Prozessschritte Wenn die deutsche Wirtschaft und IT-Industrie den Weg der IT-Industrialisierung konsequent gehen, können beide zusammen den Wirtschaftsstandort Deutschland stärken. soweit standardisiert vorliegen, ist ein Vergleich zwischen unterschiedlichen Leistungserbringern für bestimmte, einzelne Prozessschritte möglich. Cloud: Vollendung der Industrialisierung Mit der oben beschriebenen Definition von Cloud Computing ist klar, dass die Cloud bestimmte (Modularisierung), standardisierte (Standardisierung) und automatisierte (Automatisierung) Services via Internet erbringt, die auf einer Nutzungsbasis abzurechnen sind. Das Nutzen von Services von einem Kunden via Cloud bedeutet, dass dieser Service vom Kunden als unterstützender Service eingestuft wird und nicht zu dessen Kernkompetenz zählt (Kompetenz-Fokussierung). Die Lösungen Cloud Computing als auch Outsourcing passen damit exakt zum Prinzip der IT-Industrialisierung: Keiner kann Cloud-Services nutzen, ohne überhaupt zu wissen, welche Prozesse davon profi- 47

tieren können (Modularisierung). Aufgrund der oben beschriebenen inhaltlichen Nähe zwischen Outsourcing und Cloud gilt diese Anforderung ebenfalls für Outsourcing. Keiner kann Cloud-Services ohne klare Schnittstellen nutzen (Standardisierung). Da Cloud-Services via Internet erbracht werden, ist dies leicht verständlich, da es sich um Schnittstellen-Implementierungen handelt. Grundsätzlich gilt dies aber auch für Outsourcing allgemein: Auch hier müssen Rollen als Adressaten sowie gewünschte Informationen semi-formal bekannt und eingehalten sein. Keiner kann Cloud-Services nutzen, ohne ein Automatisierungspotential erkannt zu haben (Automatisierung). Da Cloud-Services elektronisch erbracht werden, ist die Automatisierung eine implizite Notwendigkeit. Diese Anforderung gilt für Outsourcing Die Idee der Automatisierung ist nicht, jeden Prozessschritt zu automatisieren, wohl aber solche, die kaum oder keiner menschlichen Interaktion bedürfen. dagegen nicht zwangsläufig: Nach einer entsprechenden Standardisierung kann durchaus ein externer Partner beauftragt werden, um einen Service zu erbringen. Ein typisches Beispiel für Outsourcing sind Helpdesks: Aufgrund der notwendigen menschlichen Interaktion werden sie nicht als Cloud-Services erbracht, da sie kaum automatisierbar sind. Die Verwendung von Cloud-Services erfordert demnach entlang der Industrialisierungsstufen eine höhere Reife als die Verwendung von Outsourcing. Erst wenn diese Vorbedingungen erfüllt werden, kann Cloud Computing und/oder Outsourcing effizient und effektiv eingesetzt werden. In die jüngste Diskussion muss insbesondere zwischen der Cloud und Outsourcing ein weiterer Begriff eingeführt werden: der Managed Service. Nach Gartner [8] stellt er einen extern erbrachten Service inklusive Management dar, der über ein Netzwerk (nicht zwangsläufig Internet) erbracht wird und auf Basis einer monatlichen Gebühr abgerechnet wird. Auch Managed Services können nur dann sinnvoll verwendet werden, wenn auf der Industrialisierungsleiter alle Schritte bis einschließlich der Standardisierung erfolgreich durchlaufen sind. 2. Software Made in Germany : Quo Vadis Wenn die deutsche Wirtschaft (als IT-Anforderer) und die deutsche IT-Industrie (als IT-Leistungserbringer) den Weg der IT-Industrialisierung konsequent gehen, können beide zusammen den Wirtschaftsstandort Deutschland stärken, indem profitable Business-Prozesse auf Anforderseite durch eine effektive IT auf der Seite der Leistungserbringer effizient unterstützt werden. Beide müssen am Ende jeweils entscheiden, was ihre Kernkompetenzen sind. Dies kann punktuell durchaus bedeuten, dass bestimmte IT-Services gar nicht mehr durch die deutsche Software-Industrie erfüllt werden. Wenn diese durch andere Anbieter aus dem Ausland besser, günstiger oder zügiger erbracht werden können, scheint dies ohnehin kein deutsches Alleinstellungsmerkmal zu sein. Dieser Prozess, in dem die Alleinstellungsmerkmale identifiziert und anschließend geschützt und ausgebaut werden, ist ein höchst kreativer Prozess und erfordert ein langfristiges, strategisches Management. 3. Fazit Die IT-Entwicklung ist insbesondere im Hochpreisland Deutschland im Umbruch. Cloud Computing und das Outsourcing stellen weitere Symptome dieses Umbruchs dar: Wie in anderen Industrien bereits geschehen, muss die IT für sich entscheiden, welche Prozessschritte zur Sicherung des eigenen Standorts im eigenen Land bleiben und welche gegebenenfalls ausgelagert werden können, zum Beispiel in die Cloud. 48 IM information Management und Consulting 03 2012

LITERATUR [1] BITKOM: Positionspapier IT-Outsourcing, Dezember 2004 [2] Gartner: Gartner Says Cloud Computing Will Be As Influential As E-business. Gartner.com, 2010 [3] Computer Economics: IT outsourcing statistics 2010/2011: Outsourcing and Offshoring Trends, available at www.computereconomics.com SERVICE AUTOR Dr. Frank Simon SQS Software Quality Systems AG, Leiter SQS- Research [4] Karsten Leclerque: Outsourcing im Jahr 2020, in CIO-Magazine vom 29.09.2010 [5] Matthias Krust: Auf fremder Werkbank, in Automobilwoche von September 2007 [6] Der Standard: Second-Hand-Software stößt auf wachsendes Interesse bei den Unternehmen, vom 22. August 2004 [7] Capgemini: Studie IT-Trends 2010: Die IT wird erwachsen, 2010, erhältlich unter http://www.at.capgemini.com/m/at/tl/it-trends_2010.pdf [8] Gartner: Glossary, verfügbar unter http://www.gartner.com/6_help/glossary/ GlossaryM.jsp KEYWORDS Cloud Computing, Software-Entwicklung, IT-Outsourcing, Industrialisierung, IT-Qualität Dr. Frank Simon studierte und promovierte in Software-Engineering an der Universität Oldenburg sowie an der Technischen Universität Cottbus. 2001 trat er als Senior Consultant bei der SQS AG ein und leitet dort seit 2008 die Research-Abteilung. In seinem Blog stellt er als Diagnostiker regelmäßig IT-Trends auf den Prüfstand. KONTAKT frank.simon@sqs.com SQS Software Quality Systems AG Stollwerckstr. 11 51149 Köln Tel.: +49 (0)2203 / 91 54 0 www.sqs.com www.sqs-blog.com/de/author/dr-frank-simon 49