www.objektspektrum.de1

advertorial

HintergrundImmer häufiger sehen sich IT-Unterneh-men und Hersteller komplexer Systeme der Notwendigkeit gegenüber, Werkzeuge aus verschiedenen an der Entwicklung be-teiligten Domänen zu einer durchgängigen Prozesskette zu integrieren. Wichtig ist hierbei auch der Aspekt der Eingliederung sogenannter vor- bzw. nachgelagerter Do-mänen, wie z. B. Projektmanagement oder Incident- (oder Ticket-)Management in diese Kette (vgl. Abbildung 1).

Insbesondere stark regulierte Branchen, wie z. B. die Finanzbranche, aber auch die Automobilindustrie oder Medizintechnik, sind aufgefordert, den Entwicklungspro-zess durchgängig nachvollziehbar zu gestal-ten (Stichwort „Traceability“). Die jeweili-gen Regularien dienen letztendlich immer

Moderne Werkzeugintegration und automatisierter Datenaustausch über Unternehmensgrenzen hinwegImmer häufiger sehen sich IT- und Entwicklungsabteilungen der Problemstellung gegenüber, Systeme aus verschiedenen Prozessbereichen zu einer durchgängigen Toolkette integrieren zu müssen – häufig auch über Unternehmensgrenzen hinweg. Angefangen beim Requirements Management über das Test Management sowie Change- und Defect Management bis hin zum Konfigurationsmanagement. Speziell in prozessorientierten Branchen scheint eine integrierte Werkzeugkette sowohl für eine effiziente als auch für eine aus Prozesssicht nachvollziehbare Software- und Systementwicklung unabdingbar geworden zu sein. Es gilt also vor allem, zwei Anwendungsfälle abzudecken: Die Integration von Software Engineering-Systemen für eine reibungslose Datensynchronisation innerhalb eines Unternehmens und den Datenaustausch, also den Transfer von (Entwick-lungs-)daten über Unternehmensgrenzen hinweg (beispielsweise im Kunden-Lieferanten-Verhältnis). Dieser Artikel diskutiert gängige Integrationstechniken und behandelt ausführlich den Aufbau einer modernen, Bus-basierten Architektur. Es wird anhand von Praxisbeispielen erläutert, wie eine zentrale Integrationsarchitektur als einheitliche Basis für alle Aspekte der Tool-integration und den Datenaustausch genutzt werden kann. Was im Bereich der Enterprise Application Integration (EAI) längst etabliert ist, wird nun auch im Bereich der Software- und Systementwicklung verfügbar.

Ralf Klimpke (ralf.klimpke@agosense.com) studierte Wirtschaftsingenieurwesen an der Fachhochschule für Technik in Esslingen. Seit 1995 war er unter anderem bei der MKS GmbH (seit 2011 PTC) in verschiedenen Positionen tätig und verantwortete den Aufbau eines indirekten Vertriebskanals für eine Produktlinie. Später etablierte er als Key Account Manager maßgeblich die starke Präsenz des Unter-nehmens in der Automobilbranche. Seit 2009 ist er als Mitgründer und Geschäftsführer der agosense GmbH tätig und bringt insgesamt mehr als15 Jahre Erfahrung in Vertrieb und Marketing in das Unternehmen ein.

Abb. 1: Domänen im Entwicklungsprozess

2Online Themenspecial Architekturen 2013

advertorialOnline Themenspecial Architekturen 2013

tik, seine bestehenden Systeme integrieren zu müssen, sondern kann auf die Kom-plettlösung eines einzelnen Anbieters set-zen.

Es wird teilweise als Nachteil angese-hen, dass der Anwender hier nicht für jede Einzeldomäne das für sich am besten ge-eignete Werkzeug auswählen kann (soge-nannte „Best-of-Breed“-Strategie), son-dern immer eine Kompromisslösung in Bezug auf Funktionalität und Akzeptanz erhält. Darüber hinaus ist man mit der ge-samten Entwicklungsumgebung an einen einzigen Toolhersteller gebunden – was je nach Standpunkt einen Vorteil (z. B. ein Ansprechpartner für Produktsupport) oder auch einen Nachteil (starke Abhängigkeit von einem Hersteller) darstellen kann.

Da aber auch ALM-Plattformen in der Regel nicht sämtliche Domänen im Le-benszyklus der Systeme beherrschen und z. B. in den Bereichen Projektmanage-ment, Modellierung oder Incident Ma-nagement Lücken vorweisen, sind auch hier die Themen Werkzeugintegration und Anbindung externer Partner präsent.

Mindestens ebenso groß ist der Anteil derer Unternehmen, welche ihre historisch heterogen angewachsene Systemland-schaft zu integrieren versuchen. Mögliche Gründe hierfür liegen unter Umständen in der Benutzerakzeptanz – Anwender wol-len das vertraute Tool und die gewohnte Arbeitsumgebung nicht gegen eine neue ersetzt wissen. Hinzu kommt gelegentlich das Argument, die getätigten Investitionen in die bestehenden Systeme schützen zu wollen, anstatt diese komplett auszutau-schen.

Als eines der wichtigsten Argumente könnte zudem die bewusste Wahl für eine bereits im obigen Abschnitt beschriebene Best-of-Breed-Strategie angeführt werden. Das heißt, das Unternehmen verfolgt den Ansatz, für die jeweilige Domäne das am besten geeignete bzw. spezialisierte Werk-zeug einzusetzen.

Dies bedeutet im Umkehrschluss, dass die Prozesslücken zwischen den einzelnen, heterogenen Werkzeugen mittels einer an-deren Lösung geschlossen werden sollten.

Alternative Möglichkeiten: Punkt-zu-Punkt-Integration (individuell programmiert, kommerziell oder auch als Open Source)Unternehmen stehen verschiedene Wege offen, ihre Systeme zu einer durchgängi-gen Prozesskette zu integrieren. Die An-

In der Domäne des Anforderungsma-nagements, speziell in der Automobilbran-che, hat sich der OMG-Standard „Requi-rements Interchange Format“ (RIF bzw. ReqIF) etabliert. Dieser ermöglicht einen verlustfreien, bi-direktionalen Austausch von Anforderungsdokumenten zwischen Zulieferern und Automobilherstellern.

In der Domäne des Defect Manage-ments werden zunehmend Fehlerdaten zwischen Lieferant und Auftraggeber auf elektronischem Weg ausgetauscht. Auch hier etabliert sich zusehends der automati-sierte Datenaustausch über Standard-Da-tenformate wie z. B. ASAM AE Issue.

Die Verwendung von unabhängigen Standards bietet für alle beteiligten Partei-en große Vorteile:

n kein direkter Zugriff auf die jeweils eingesetzten Werkzeuge der beteilig-ten Partner möglich/notwendig,

n das Datenformat ist standardisiert und verlustfrei,

n jeder Partner kann das Werkzeug der eigenen Wahl einsetzen,

n Daten können vollständig automati-siert erzeugt, transportiert und im-portiert werden.

Zusammenfassend gilt es, vor allem zwei Anwendungsfälle abzudecken: Die effiziente Integration von Software Engi-neering-Systemen für eine reibungslose Datenintegration innerhalb eines Unter-nehmens und den automatisierten Daten-austausch, also den Transfer von (Ent-wicklungs-) Daten über Unternehmens - grenzen hinweg.

Welche Möglichkeiten und Technologi-en stehen heute zur Verfügung, um diese Herausforderungen zu meistern? Welche Vor- und Nachteile bieten diese? Wie se-hen konkrete Anwendungsbeispiele aus der Praxis aus? Diese Fragestellungen werden im Folgenden näher beleuchtet.

ALM-Plattformen (zentrale Daten-ablage) als Lösung?Eine Möglichkeit, diesen Herausforderun-gen zu begegnen, sind so genannte ALM (Application Lifecycle Management) -Plattformen, die jeweils von einem Her-steller stammen und in der Regel die Da-ten aus allen Domänen der Entwicklung in einer zentralen Datenablage („Single Repository“) sammeln. Diese sind in sich hochintegriert und vereinen möglichst vie-le Domänen in sich. Ein Unternehmen steht damit nicht länger vor der Problema-

dem Zweck, die Qualität der Endprodukte auf ein möglichst hohes Niveau zu stellen und im Fehlerfall schnellstmöglich die Ur-sachen zu finden und zu beheben.

Um dies gewährleisten zu können, ist eine tiefgreifende Integration der Werk-zeuge, welche entlang des Entwicklungs-prozesses eingesetzt werden, notwendig. Diese Integration der Werkzeuge dient letztendlich dazu, die vor, während und nach der Entwicklung entstandenen Da-ten bzw. sogenannten „Artefakte“ in Be-ziehung zueinander zu setzen und deren Abhängigkeiten darzustellen. So entsteht ein durchgängiges Geflecht der Daten und es wird erleichtert, den Ursprung eines aufgetretenen Fehlers entlang dieser Bezie-hungen aufzufinden. Aber auch die Feh-lerbehebung muss unter Umständen nach-vollziehbar sein, da Regularien üblicher- weise nicht nur die Fehlerbehebung selbst, sondern auch den Nachweis über den Weg dahin fordern. Diese „revisionssichere“ Nachverfolgung ist effizient nur durch In-tegration und Verlinkung möglich.

Des Weiteren deckt die Werkzeuginteg-ration nicht nur reine regulatorische Erfor-dernisse zur stetigen Qualitätsverbesse-rung ab. Es wird auch ermöglicht, die Effizienz der Produktentwicklung wesent-lich zu steigern, indem sowohl die Abläufe als auch die Kommunikation, die zwischen den Domänen stattfindet, auto matisiert werden können. Wo dementsprechend Ar-tefakte aus verschiedenen Werkzeugen be-reits verlinkt wurden, können Informatio-nen über Änderungen, Zustand, usw. mit den entsprechenden Werkzeugen jederzeit in beide Richtungen „synchronisiert“ wer-den, sodass Anwender weder ihre jeweilige Domäne noch das Domänen-Werkzeug dabei wechseln müssen.

Diese Thematik der Integration macht aber nicht an der eigenen Unternehmens-grenze Halt – vielmehr müssen dort, wo Kunden-Lieferanten-Verhältnisse oder Ent- -wicklungspartnerschaften bestehen, Da-ten auch über Unternehmensgrenzen hin-weg ausgetauscht bzw. synchronisiert werden. Die beteiligten Unternehmen ver-fügen in der Regel nicht über gemeinsame oder gemeinsam genutzte IT-Netzwerke bzw. die Zugänge zu den jeweiligen Netz-werken sind aus guten Gründen sehr be-schränkt. Daher finden vermehrt Standar-disierungen von Datenformaten statt, welche für bestimmte Anwendungsfälle dann konkret genutzt werden können, um einen verlustfreien Datenaustausch sicher-stellen zu können.

advertorial

3 www.objektspektrum.de

aus dieser Erfahrung weiter gehende Anforderungen an eine hochintegrierte Werkzeugkette. Diese sind unter ande-rem:

n flexible, serverbasierte Infrastruktur, die sich leicht in bestehende IT-Land-schaften einbetten lässt,

n einfache Ausbaumöglichkeiten zur Integration weiterer (z.T. auch selbst-entwickelter) Werkzeuge,

n Integrationsmöglichkeit in weitere Prozessbereiche wie z. B. Product Lifecycle Management (PLM), Pro-jektmanagement, Incident Manage-ment, usw.,

n Skalierbarkeit (bei großen Datenmen-gen) und Verarbeitungsgeschwindig-keit (Echtzeit-Synchronisation),

n Automatisierung von Abläufen und Reduktion manueller Fehlerquellen,

n Robustheit, integrierte Behandlung von Fehlern und Konflikten, Re-porting/Logging,

n kein Zusatzaufwand oder zusätzliche Bedienoberflächen für den Endan-wender,

n Zentraler IT-Betrieb bei gleichzeitiger dezentraler Konfiguration für Grup-pen oder Projekte (z. B. Mandanten-fähigkeit),

n vollständiges, von einem unabhängi-gen Hersteller unterstütztes Produkt,

n Nutzung von Standardtechnologien (z. B. OSLC, REST, Webservices, BPEL, Java, usw).

Produktaktualisierungen können deshalb verzögert oder gar verhindert werden.

Die Nachteile solcher starren Integrati-onen, die meistens nur zwei spezifische Werkzeuge (oder gar Werkzeug-Versio-nen) verbinden, sind also offenkundig. Sie sind in der Erstellung und in der Pflege höchst aufwendig und stellen eine große Abhängigkeit bei Änderungen und Up-dates einzelner integrierter Werkzeuge dar.

Hinzu kommt, dass die Werkzeugland-schaft mit steigender Anzahl an Tools und dementsprechenden Punkt-zu-Punkt-Inte-grationen zunehmend unübersichtlicher und schwerfälliger in der Wartung und Pflege wird.

Darüber hinaus stellen sich unter ande-rem folgende Fragen: Wie gut skaliert der Punkt-zu-Punkt-Ansatz bei großen Daten-mengen oder einer großen Anzahl von Endanwendern? Wie aufwendig ist das Ausrollen der Skripte an die einzelnen Ar-beitsplatzrechner? Und: Wer stellt sicher, dass ein Anwender seine aktualisierten Daten auch für den nächsten Prozess-schritt (manuell) synchronisiert hat?

Weitergehende Anforderungen aus AnwendersichtDie oben beschriebenen Technologien sind sicher sinnvoll in kleineren Entwick-lungsabteilungen mit relativ wenigen An-forderungen in Bezug auf Regularien und Vorschriften. Alle anderen Unternehmen werden aber recht schnell an die Grenzen dieser Technologien stoßen und stellen

forderung lautet dabei zunächst recht schlicht, dass der gewünschte Prozessab-lauf in der Entwicklung unabhängig der eingesetzten Werkzeuge abgebildet wer-den soll.

Punkt-zu-Punkt-Integrationen zwischen jeweils zwei einzelnen Werkzeugen sind hierfür gängige Szenarien in Unterneh-men. Dabei erstellt entweder das Unter-nehmen selbst oder beispielsweise ein ex-terner Beratungsdienstleister eine Indivi- duallösung zur Integration zweier Werk-zeuge, um einen bestimmten Anwen-dungsfall abzubilden.

Diese Integrationen werden dann häu-fig von den Fachbereichen oder Dienst-leistern gepflegt und haben sich in vielen Unternehmen zwischenzeitlich zu einer kostenintensiven Parallel-IT entwickelt. Die Gründe sind auf der einen Seite ein-leuchtend, denn die Entwicklungsabtei-lungen sind in der Lage, auf Änderungsan-forderungen wesentlich schneller zu reagieren als eine zentrale IT-Abteilung.

Auf der anderen Seite müssen die Fachabteilungen von ihren eigentlichen Tätigkeiten – nämlich der Produktent-wicklung und Projektarbeit – immer mehr Zeit für die Pflege, Wartung und Anpas-sung dieser Integrationen aufwenden und können üblicherweise auch kein optimales Betriebskonzept sicherstellen. So berich-ten IT-Verantwortliche, z. B. bei Finanz-dienstleistern, dass zum Teil bereits bis zu 50 Prozent der IT-Budgets für die Ent-wicklung und Wartung von individuell programmierten Integrationen aufgewen-det werden müssen.

Teilweise werden Plugins zur Datensyn-chronisation zwischen zwei Tools auch von Drittanbietern bzw. den Herstellern der Entwicklungswerkzeuge selbst ange-boten oder stehen zum Teil auf „Plugin-Börsen“ zur Verfügung. Bezogen auf die benötigte Funktionalität und Anpassbar-keit an die eigenen Abläufe und funktio-nalen Anforderungen stellen diese jedoch immer Kompromisslösungen dar.

Vor allem wenn neue Produktversionen der eingesetzten Werkzeuge eingeführt wer den sollen, wird die Abhängigkeit zum Werkzeug-Hersteller bzw. Entwickler ei-nes Plugins deutlich. Denn gerade wenn Updates durchgeführt werden (müssen), unterstützt die jeweilige Integrationstech-nik häufig noch nicht diese neuen Versio-nen.

Je verflochtener die Werkzeugland-schaft integriert ist, desto stärker ist na-türlich diese Abhängigkeit. Notwendige Abb. 2: Typische Architektur einer Integrationsplattform (Quelle: agosense GmbH)

4Online Themenspecial Architekturen 2013

advertorialOnline Themenspecial Architekturen 2013

Zusätzliche Module erlauben die Kon-figuration z. B. von Attribut-Mappings, die Steuerung zeitlich geplanter Prozesse, das Caching von Metadaten, Links oder Checksummen, usw. Ein Vertreter dieser Technologie ist z. B. agosense.symphony von der agosense GmbH.

Die Vorteile einer prozessorientierten Integrationsplattform sind darin begrün-det, dass sie in der Regel die im vorigen Abschnitt aufgeführten Anforderungen erfüllt und selbst bei komplexeren Integ-rationsvorhaben, bei denen Automatisie-rung und Durchsetzung von Entwick-lungsprozessen im Mittelpunkt stehen, sehr übersichtlich in der Handhabung ist.

Als nachteilig wird eine gewisse Abhän-gigkeit von einem Hersteller für ein so zentrales System gesehen, was aber durch die Verwendung von Standardtechnologi-en (ESB, BPEL, OSLC, ...) relativiert wird.

Anwendungsfälle für den Einsatz einer Integrationsplattform: Ein Blick in die PraxisZunächst sollen beispielhaft die Werkzeu-gintegration und Prozessautomatisierung einer Schweizer Großbank als praktischer Anwendungsfall vorgestellt werden. Dort wurden, wie in Abb. 3 zu sehen ist, zahl-reiche Entwicklungs-Tools via agosense.symphony zu einer durchgängigen Pro-zesskette integriert.

Den Anforderungsingenieuren werden die Änderungsanträge im System für An-forderungsmanagement, Polarion Requi-rements, zunächst als Änderungsanfragen zugeordnet, damit diese die für die weite-re Entwicklung notwendigen Spezifikatio-nen und Anwendungsfälle erstellen kön-

oder einfache Webservices). Die Adapter werden dabei genutzt, um einerseits die Werkzeuge zu konnektieren (Verbin-dungsparameter) und andererseits die un-terschiedlichsten, spezifischen Datenfor-mate bzw. die Syntax der Program mier- schnittstellen in das eigentliche Bussystem hinein zu normalisieren, sprich zu verein-heitlichen.

Zusätzlich ist durch diese Technik ge-währleistet, dass alle Werkzeuge, welche durch einen Adapter repräsentiert sind, untereinander über die Plattform kommu-nizieren können. Dies erlaubt also nicht nur die direkten Verbindungen wie bei den zuvor beschriebenen Punkt-zu-Punkt-Integrationen, sondern ermöglicht beliebi-ge Kombinationen.

Der Bus ist dann die ausführende Schicht der sogenannten Prozessmodelle und gleichzeitig für den eigentlichen Transport der über die Adapter normali-sierten Informationen zuständig. Die Pro-zessmodelle dienen zur Definition der Re-geln und Abläufe, die für einen bestimmten Integrationsfall angewandt werden sollen. Diese Prozessmodelle werden in der Regel mit Standardsprachen erstellt, wie z. B. mit der Business Process Execution Lan-guage (BPEL), welche bereits aus der Inte-gration von Geschäftsanwendungen be-kannt und etabliert ist.

Idealerweise können diese Prozessmo-delle mehrfach verwendet und mithilfe ei-ner grafischen Oberfläche parametrisiert werden. Über diese Prozessmodellierung und mithilfe geeigneter Funktionen der Adapter lassen sich so definierte Prozesse einfach dokumentieren und direkt im Bus ausführen.

Für den Datenaustausch mit externen Partnern gelten außerdem folgende Anfor-derungen:

n Automatisierungsmöglichkeiten für das Abholen und Bereitstellen von Daten in Unternehmensportalen,

n Protokollierung/Aufzeichnung von Austauschvorgängen in beide Rich-tungen zur Sicherstellung der Erfül-lung von Anforderungen für externe Prozesse,

n Unterstützung standardisierter Da-tenaustauschformate, wie XML, ASAM, RIF/ReqIF usw.,

n vom Hersteller unterstütztes Produkt – keine Individualprogrammierung oder Dienstleistung.

Die Frage, die sich nun stellt, ist: Mit welcher Technologie können genau jene Anforderungen umgesetzt und gelöst wer-den?

Ein Blick in den Bereich der Integration von Geschäftsanwendungen offenbart eine dort bereits seit vielen Jahren gängige Standardtechnologie, die analog auch auf die spezialisierten Prozesse im Software Engineering übertragen werden kann, ba-sierend auf einem serviceorientiertem Da-tenbussystem.

Effiziente Integration mittels Bus-basierter ArchitekturIn den letzten Jahren haben sich nun auch Integrationstechnologien etabliert, welche auf Basis eines Datenbusses (auch ESB oder Service Bus genannt) mit einer mehr-schichtigen Architektur arbeiten. In der Architektur eines solchen Systems wird zwischen der rein technischen Anbindung an die zu integrierenden Werkzeuge und der Definition der Datenflüsse bzw. Pro-zessabläufe eine Trennung vollzogen.

Diese sind wiederum separiert von der Verwaltung der Meta- und Konfigurati-onsdaten. Somit ist eine hochflexible Kon-figuration unter Berücksichtigung der in-dividuellen Kundenanforderungen bzw. Entwicklungsprozesse bei einer gleichzei-tig hochstandardisierten technischen Inte-gration der Werkzeuge möglich (vgl. Ab-bildung 2).

Im Detail werden die einzelnen zu inte-grierenden Werkzeuge über Adapter di-rekt an ihren Programmierschnittstellen (API) angesprochen, wobei sich hier un-terschiedlichster Technologien und For-mate bedient werden kann (größtenteils anbieterspezifisch, aber auch REST, OSLC Abb. 3: Beispiel Werkzeugintegration

advertorial

5 www.objektspektrum.de

analysieren und zu beheben – so lange, bis der Entwicklungszyklus letztendlich mit erfolgreichem Test abgeschlossen werden kann.

Die Tools der verschiedenen Rollen in diesem Softwareentwicklungsprozess wer-den durchgängig mit agosense.symphony modelliert und gesteuert, wobei selbstver-ständlich auch Fehler- und Konfliktsituati-onen behandelt werden. Darüber hinaus ist es je nach Prozessdefinition möglich, dass Daten entweder direkt durch Benut-zerinteraktion (z. B. durch Statuswechsel) oder zeitgesteuert synchronisiert werden.

So ist gewährleistet, dass jeder Prozess-beteiligte in seiner Rolle mehrheitlich mit seinem spezialisierten Werkzeug arbeiten kann und dennoch alle notwendigen und persönlich relevanten Informationen er-hält, ohne Tools oder Benutzeroberflä-chen wechseln zu müssen.

Weitere Anwendungsfälle finden Sie auf http://www.agosense.com/deutsch/media-thek/case-studys-und-whitepaper n

Softwareentwicklung. Dabei können die Entwickler aus Eclipse heraus Projektauf-gaben und Anträge aus Atlassian Jira di-rekt sehen und ändern sowie mit Codeän-derungen verknüpfen.

Parallel werden freigegebene Anforde-rungen in den Testbereich nach HP Quali-ty Center/ALM übertragen. Die Testinge-nieure erstellen in diesem Werkzeug die korrespondierenden Testfälle für die neu-en Anforderungen oder passen vorhande-ne Anwendungstestfälle an. Die Planung der Testaktivitäten wird mit der Projekt-planung in Atlassian Jira synchronisiert. Ist die Codierung abgeschlossen, werden die Applikationen gemäß den Testfällen und Testplänen in HP QC/ALM geprüft.

Für nicht bestandene Tests wird in HP QC/ALM eine Fehlermeldung erstellt, die dann via agosense.symphony automati-siert nach Atlassian Jira an das Projekt-team zur Bearbeitung zurückgespielt wird. Dabei werden auch notwendige Tester-gebnisse übergeben, sodass die Entwick-lung in der Lage ist, Fehler qualifiziert zu

nen. Zugehörige UML-Modelle werden vom Anforderungsingenieur in Sparx Enterprise Architect erstellt und automa-tisch mit Polarion Requirements abgegli-chen.

Neue Statusinformationen zu den An-fragen werden regelmäßig an die Collabo-ration-Anwendung in Atlassian Jira zu-rückgemeldet, sodass die ursprünglichen Antragsteller darüber hinaus den Status der Umsetzung ihrer Anfragen jederzeit verfolgen können.

Das Software-Architekturteam benutzt die Anforderungen aus Polarion Require-ments und weitere Informationen aus der technischen Analyse in Sparx Enterprise Architect, um die Architektur der Anwen-dung zu validieren und gegebenenfalls an-zupassen. Dadurch wird eine konsistente Dokumentation der Anwendungsarchi-tektur über den gesamten Lebenszyklus gewährleistet.

Softwareingenieure nutzen die Anfor-derungsspezifikation, die Architektur und Designdokumentation für die eigentliche