WHITE PAPER November Softwareentwicklung und -Testing ohne Einschränkungen dank Service-Virtualisierung

WHITE PAPER November 2014 Softwareentwicklung und -Testing ohne Einschränkungen dank Service-Virtualisierung

2 White Paper: Schlüsselfunktionen einer LÖSUNG FÜR DIE SERVICE-VIRTUALISIERUNG Inhaltsverzeichnis Kurzfassung 3 Abschnitt 1: Eine realistische Umgebung aufbauen 4 Abhängige Systeme in Entwicklungs- und Testumgebungen simulieren Abschnitt 2: Parallele Entwicklungs- und Testing-Prozesse ermöglichen 5 Entwicklungs- und Testteams gleichzeitig arbeiten lassen Abschnitt 3: Testdaten für Abhängigkeiten außerhalb des Anwendungsbereichs behandeln 6 Probleme durch fehlende Downstream-Daten beseitigen Abschnitt 4: Heterogene Technologien und Plattformen unterstützen 8 Eine wirklich vollständige Umgebung aufbauen Abschnitt 5: Fazit 10 Die ersten Schritte optimal wählen

3 White Paper: Schlüsselfunktionen einer LÖSUNG FÜR DIE SERVICE-VIRTUALISIERUNG Kurzfassung Ausgangssituation Die zunehmende Komplexität von Anwendungen und die global verteilte Unternehmenstätigkeit konfrontieren Entwicklungs- und Testing-Teams bei ihrer Arbeit mit zahlreichen Engpässen. Der Zugang zu Mainframe- oder ERP- Testumgebungen, fehlende Testdaten, die Verfügbarkeit von Drittanbietersystemen und begrenzte Budgets sind solche Engpässe und Einschränkungen. In vielen Fällen entstehen sie, wenn parallel arbeitende Entwicklungsteams dieselbe Umgebung nutzen wollen. Die Teams versuchen dann, entweder eine vollständige Umgebung in ein Testlabor zu kopieren, oder sie simulieren zu Testzwecken reaktionsfähige Systeme, indem sie ihre eigenen Versionen dieser Systeme für Testzwecke erstellen. Dies ist ein teures und zeitaufwendiges Unterfangen. Chance Bei der Service-Virtualisierung (SV) handelt es sich im Wesentlichen um Produkte, die die Simulation und Verwendung von Stubs in Entwicklungs- und Testumgebungen professionalisieren. Sie sind ausreichend realitätsnah und kontextbezogen, um die Entwicklung zu beschleunigen, und verlagern das Testing an einen früheren Zeitpunkt des Lebenszyklus, sodass Integrations- und Releaseprozesse schneller, hochwertiger und risikoärmer durchgeführt werden können. Nutzen Im Folgenden wird eine Reihe von Leistungsmerkmalen beschrieben, die Ihr Unternehmen von einer Lösung für die Service-Virtualisierung verlangen sollte, damit Ihre erweiterten Teams hochwertige Lösungen schneller, kostengünstiger und risikoärmer auf den Markt bringen können. Dazu zählen: Möglichkeit zur Entwicklung in einer realistischeren Umgebung Möglichkeit paralleler Entwicklungs- und Testing-Prozesse Virtualisierung von Testdaten für Systeme außerhalb des Anwendungsbereichs Unterstützung leistungsstarker Umgebungen Entwicklung in höherer Qualität und effektiveres Regressions-/System-Testing Verkürzung der Zykluszeiten, Früherkennung von Fehlern, effiziente Ressourcennutzung schnellere Installation und Deinstallation, stabilere Automatisierung von Tests realistischeres und umfangreicheres Performance- Testing zu deutlich niedrigeren Kosten Da keine Anwendungsentwicklungs- und Testumgebung als Insel existieren kann, ist es außerdem wichtig, dass Lösungen für die Service-Virtualisierung eine herstellerunabhängige Grundlage bereitstellen, die mit den Tools des jeweiligen Teams genutzt werden kann. Die Lösung für die Service-Virtualisierung sollte Zielumgebungen bereitstellen, die zusammen mit den bestehenden Lösungen für den Anwendungslebenszyklus verwendet werden können, wie mit Test Management (TM), Fehlermanagement/Problemverfolgung sowie mit führenden Virtualisierungsprodukten für Hardware und Testlabor, die bereits Teil der Umgebung sind.

4 White Paper: Schlüsselfunktionen einer LÖSUNG FÜR DIE SERVICE-VIRTUALISIERUNG Abschnitt 1: Eine realistische Umgebung aufbauen Abhängige Systeme in Entwicklungs- und Testumgebungen simulieren Der Trend in der Anwendungsentwicklung geht zu stärker kombinierten, serviceorientierten Architekturen. Daher müssen Teams in ihrer Entwicklungs- und Testumgebung eine viel größere Bandbreite an vor- und nachgelagerten Systemen simulieren. Die Service-Virtualisierung sollte auf oder zwischen allen Ebenen angewendet werden, an denen Abhängigkeiten bestehen, um die Umgebung so realistisch wie möglich zu gestalten. Bei dem herkömmlichen Ansatz versuchen Teams, ihre eigene Komponente zu entwickeln, indem sie das nächste nachgelagerte System nur als Stub darstellen. Beispielsweise wird bei der Entwicklung einer Web-UI ein Stub für einige erwartete Reaktionen der nachfolgenden Ebene (d. h. dem Web Service) erstellt. Die Web Service-Entwickler wiederum erstellen vielleicht einen Stub für die zugrunde liegenden ESB-Ebenen, oder sie versuchen, bestimmte Anwenderanforderungen der Web-UI zu simulieren. Dieser aufwendige manuelle Prozess reicht jedoch keinesfalls aus, um die vielfältigen Verbindungen und Daten in den Softwarearchitekturen von Unternehmen abzubilden, und ist in manchen Fällen und wie im Folgenden gezeigt sogar überhaupt nicht möglich, wenn noch keine UI codiert wurde. Abbildung A. Realistische Umgebung für die Service-Virtualisierung: vorher nachher 30 60 Prozent Produktivitätsverlust System in der Entwicklung System in der Entwicklung Stub 1 Stub 2 Falsche Spezifikation Nur ein Datenszenario von Hunderten Nicht verfügbar: Wir warten einfach Virtuelle Services Automatisierung Spezifikation Beispieldaten Eine Besprechung Tatsächliches erfasstes Verhalten Viele Szenarien mit echten Daten Wenn Teams hingegen mit echten Datenszenarien und realistischen Verhaltensweisen arbeiten, die in Form von virtuellen Services erfasst werden, ist ihre Produktivität höher, da die so erstellte Umgebung wesentlich realistischer und aktueller ist als Sätze von Stubs, die manuell codiert und gepflegt werden müssen. Die automatisierte Erstellung virtueller Services und Daten-Maintenance sind daher die beste Möglichkeit, eine möglichst realistische Umgebung zu schaffen. Entwicklungsteams arbeiten dank realistischer virtueller Laborumgebungen deutlich produktiver, selbst wenn die Benutzeroberfläche unvollständig ist. Zugleich verbringen sie weniger Arbeitszeit mit der Erstellung von Platzhaltern oder der Aktualisierung von Stubs.

5 White Paper: Schlüsselfunktionen einer LÖSUNG FÜR DIE SERVICE-VIRTUALISIERUNG Voraussichtlicher Nutzen: Entwicklungsbeginn, auch wenn Systeme nicht verfügbar sind, zu denen Schnittstellen bestehen reduzierte Testlaufzeiten intensiveres Testen, da weniger Datenabhängigkeiten von anderen Anwendungen bestehen und mehr Zeit für das Testen verfügbar ist verbesserte Einzeltests mit weniger Aufwand höhere Codequalität durch größere Testabdeckung und Regressions-Testing schnelle Einrichtung einer Simulation mit geringem Maintenance-Aufwand Abschnitt 2: Parallele Entwicklungs- und Testing-Prozesse ermöglichen Entwicklungs- und Testteams gleichzeitig arbeiten lassen Das zweite wichtige Leistungsmerkmal einer Lösung für die Service-Virtualisierung besteht darin, dass Entwicklung und Testing parallel verlaufen können. Wenn Entwicklungs- und Testteams gleichzeitig arbeiten, eröffnen sich für den gesamten Softwarelebenszyklus ganz neue Dimensionen der Effektivität und Effizienz. Das Unternehmen kann neue Lösungen bei hoher Wertschöpfung bereitstellen. Wenn Entwicklung und Testing parallel erfolgen, fungieren virtuelle Services als Bindeglied zwischen dem zu entwickelnden und dem zu testenden System. Diese gehen sozusagen eine Symbiose ein. Im folgenden Beispiel entwickelt ein Team einen Auftragsmanagement-Service (Order Management Service, OMS), während das durch den oberen Pfeil dargestellte Team eine App für einen E-Store entwickelt und testet. Abbildung B. Paralleler Entwicklungsprozess E-Store Erfassen und in Spezifikation aktualisieren Modell unter Berücksichtigung des neuen Designs aktualisieren Modell unter Berücksichtigung des neuen Designs aktualisieren Nach Bedarf realen oder virtuellen Service verwenden Feedback Feedback Feedback Auftragsmanagement-Service

6 White Paper: Schlüsselfunktionen einer LÖSUNG FÜR DIE SERVICE-VIRTUALISIERUNG Ein virtueller Service wird aus dem vorhandenen OMS-System erfasst und als vorläufiges Back End für das Testing des E-Store verwendet. Im weiteren Testing-Verlauf kann das E-Store-Team alle unerwarteten oder neuen Reaktionsanforderungen als Feedback in Form von Anforderungen an den virtuellen Service mitteilen. Hieraus wird praktisch ein neuer Satz von Anforderungen an die Entwicklung erstellt. Jeder Zyklus der parallelen Entwicklungs- und Testing-Prozesse verläuft schneller als der vorige, da bei jedem neuen Design eine Iteration von Aktualisierungen des virtuellen Servicemodells durchgeführt wird und Feedback immer schneller mitgeteilt wird. Mit der perfekten Lösung für die parallele Entwicklung können Teams mit den Live-Services arbeiten, sobald diese verfügbar sind, ihre Funktionalität stabil ist und sie über synchronisierte Daten verfügen. In den Fällen, in denen Teams noch nicht über Services verfügen, die die Komponente korrekt unterstützen, können sie direkt zu den virtuellen Services zurückwechseln. Das Team muss sozusagen nur einen Schalter umlegen, um zwischen einem rein virtuellen Downstream-System über virtuelle Services und dem Live-System hin- und herzuwechseln, und kann jederzeit wieder zurückkehren, wenn ein neues Design fehlerhaft ist oder ein neues Datenszenario notwendig wird. Wenn Sie eine robuste Umgebung zur parallelen Entwicklung einrichten möchten, stellt dies einen enormen Vorteil dar. Bietet Ihr Vorgehen zur Erzeugung und Aktualisierung von Softwarelaborumgebungen genug Realitätsbezug? Die parallele Arbeit durch Service-Virtualisierung macht die Agilität möglich, die von der Agile-Entwicklungsmethode für komplexe Softwareumgebungen erwartet wird, da Entwicklungs- und Testzyklen enger an den geschäftlichen Releasezielen ausgerichtet und schnell aufeinanderfolgende iterative Releases möglich werden. Voraussichtlicher Nutzen: mit jedem Schritt schnellere Test- und Entwicklungszyklen echte Ansprechbarkeit der Agile-Iterationen, kontinuierliche Integration und an Testergebnissen und Unternehmensanforderungen orientierte Designs geringerer Bedarf an Versionskontrolle für die effektivere Nutzung, Verwendung zusammen mit vorhandenen ALM- und Entwicklungs-Management-Tools höherer Anteil erkannter und gelöster Probleme vor dem Übergang in die Produktion bis zu 60 % schnellere Funktionsbereitstellung bei höherer Qualität und Spezifikationserfüllung Abschnitt 3: Testdaten für Abhängigkeiten außerhalb des Anwendungsbereichs behandeln Probleme durch fehlende Downstream-Daten beseitigen Jedes Team, das ein Labor für seine Aktivitäten provisionieren muss, betrachtet manche Systeme und die zugehörigen Daten als innerhalb, andere als außerhalb seines Anwendungsbereichs. Ein System innerhalb des Anwendungsbereichs ist eines, mit dem das Entwicklungsteam Veränderungen oder direkte Testprozesse durchführt. Ein System außerhalb des Anwendungsbereichs ist eines, das zur Unterstützung des Systems innerhalb des Anwendungsbereichs dient, aber nicht Gegenstand der Entwicklungs- oder Testaktivitäten ist. Dies wird als Abhängigkeit betrachtet. Das System ist notwendig, aber wird selbst nicht entwickelt oder getestet. In diesem Szenario versucht das Team, das eine Buchungsmaschine entwickelt und testet, die notwendigen Szenarien nachgelagerter Eingabedaten des Anwenders zusammenzufassen. Das Team besitzt jedoch keine umfassenden Zugriffsrechte. Die offensichtlichste Lösung ist die beim Test Data Management übliche Vorgehensweise, Daten direkt aus den Systemen innerhalb des Anwendungsbereichs importieren und für die Systeme außerhalb des Anwendungsbereichs Stubs oder Simulationen zu verwenden. Dazu werden Code geschrieben und einige Datenzeilen importiert, die die erwarteten Reaktionen dieser Abhängigkeiten außerhalb des Anwendungsbereichs darstellen sollen. Diese Stubs sind von Natur aus instabil, und Entwickler wählen die zweckdienlichste Methode, um die grundlegenden Funktionalitätsoder Reaktionsszenarien zu simulieren, die sie erwarten. Da verteilte Software immer komplexer wird, ist der Arbeitsaufwand für die manuelle Codierung und Maintenance nützlicher Stubs inzwischen viel zu teuer.

7 White Paper: Schlüsselfunktionen einer LÖSUNG FÜR DIE SERVICE-VIRTUALISIERUNG Abbildung C. Daten außerhalb des Anwendungsbereichs nicht durch Test Data Management abgedeckt TDM-Tool SQL Ops SaaS CRS GDS Eingabedaten Buchungsmaschine Oracle FF GDS SAP Handelt es sich um reale oder virtuelle Daten? Benötigt wird eine Methode, die das Verhalten dieser Systeme außerhalb des Anwendungsbereichs so intelligent simuliert, dass das System innerhalb des Anwendungsbereichs annimmt, es kommuniziere mit dem Live-System, ohne wirklich mit diesem zu interagieren. Mit der Service-Virtualisierung sind die fehlenden Daten hinter dem System innerhalb des Anwendungsbereichs kein Problem mehr, weil die Erfassung relevanter nachgelagerter Szenarien außerhalb des Anwendungsbereichs automatisiert wird. Abbildung D. Testdaten außerhalb des Anwendungsbereichs virtualisieren SQL Ops SaaS CRS GDS Eingabedaten Buchungsmaschine Oracle FF GDS SAP

8 White Paper: Schlüsselfunktionen einer LÖSUNG FÜR DIE SERVICE-VIRTUALISIERUNG Das hier gezeigte Beispiel für den Endstatus eines virtualisierten Test Data Management sieht fast zu einfach aus, aber so sollte Ihr Testprozess tatsächlich mit externen oder außerhalb des Anwendungsbereichs befindlichen Abhängigkeiten umgehen. Mit virtuellen Modellen können alle Ihre Teams jederzeit on-demand auf relevante Datasets für zu testende Systeme zugreifen, und diese Daten decken fast unbegrenzt viele gültige Datenszenarien ab. So lassen sich Leistungstests mit hohem Volumen zuverlässig durchzuführen. Lösungen für die Service-Virtualisierung sollten Mechanismen umfassen, mit denen alle benötigten Systeme in die Entwicklungs- und Testlaborumgebung aufgenommen werden. Dazu gehören die Provisionierung der Daten von Systemen außerhalb des Anwendungsbereichs und die Beibehaltung zustandsorientierter Transaktionsdaten, die in einem Workflow zwischen Systemen übergeben werden. Ein Beispiel hierfür ist eine Simulation der Veränderungen von Werten wie Datumsangaben oder kumulativen Beträgen in einer lange andauernden Transaktion, mit der komplexe Workflows dieser Art so detailliert wie nötig geprüft werden können. Voraussichtlicher Nutzen: keine Verzögerungen durch Fehlen von Zugriffsmöglichkeiten oder aktuellen Daten von Systemen außerhalb des Anwendungsbereichs Verfügbarkeit gültiger Testszenarien für mehrere Test- und Entwicklungsteams rund um die Uhr keine Konflikte bei Testdaten und keine Beeinträchtigung von Aktivitäten anderer Teams durch überschriebene oder geänderte Daten in den Systemen geringe oder gar keine Auswirkungen auf kritische Live-Systeme Unterstützung zustandsorientierter Transaktionen für komplexe Prozesse, die sich auf mehrere Technologieebenen beziehen und dabei fortlaufend konkrete Werte wie Datumsangaben, Kunden-IDs usw. verwenden müssen bis zu 90 Prozent geringerer Zeitaufwand für Einrichtung und Zurücksetzung von Daten und um 40 bis 60 Prozent kürzere Testzyklen Abschnitt 4: Heterogene Technologien und Plattformen unterstützen Eine wirklich vollständige Umgebung aufbauen Vor Kurzem besuchte ich das Architekturteam einer der größten Banken der Welt. Dort hörte ich von einer erstaunlichen Statistik. Jemand sagte mir, dass dem Hardware Asset Management-System zufolge mehr Server in der Bank bereitgestellt sind, als sie Mitarbeiter hat. Jedes Projektteam begründet die Ausgaben für eigene Hardware für Entwicklung, Testing, Produktionsvorbereitung und Produktion. Für so gut wie jede Anwendung, die zurzeit in der Bank verwendet wird, stehen mindestens diese vier Umgebungen zur Verfügung, obwohl zwischen den Releases dieser Anwendungen und somit zwischen Maintenance- und Änderungsvorgängen in vielen Fällen Monate oder Jahre liegen. Paradoxerweise besteht die größte Herausforderung der meisten vorhandenen Produktionsvorbereitungsumgebungen darin, dass sie niemals das vollständige System abbilden. Ein Projektteam kann beliebig viele Server erwerben und verwenden, um Hardware oder Komponenten auf VMs zu replizieren, auf die es zugreifen kann. Obwohl aber jedes Team sein eigenes Hardwarebudget einsetzt, verbringen die Teams trotzdem viele Monate des Entwicklungszyklus damit, auf Zugriff zu warten und ineffizient auf gemeinsam genutzte Systemressourcen zuzugreifen. Heterogene Systeme sind in den IT-Umgebungen von Unternehmen die Norm. Daher sollte die Service-Virtualisierung genutzt werden, um alle Abhängigkeiten zu virtualisieren, die sich auf das zu testende System (System Under Test, SUT) auswirken können. Hierzu gehören Datenverkehr über das Web (HTTP), Web Services (SOAP/XML), Integrationsebenen und ESB (JMS usw.) sowie die Simulation von Transaktionen und Verbindungen mit zugrunde liegenden Mainframes (CICS, CORBA usw.), Datenbanken (JDBC, usw.) und Services von Drittanbietern.

9 White Paper: Schlüsselfunktionen einer LÖSUNG FÜR DIE SERVICE-VIRTUALISIERUNG Abbildung E. SUT SUT ESB MAINFRAME DATEN LEGACY EXTERN Da jeder Verbindungspunkt in Ihrer Softwarearchitektur einen potenziellen Änderungspunkt und ein potenzielles Ausfallrisiko darstellt, ist es wichtig, dass die Service-Virtualisierung Teams eine bessere Möglichkeit bietet, alles andere zu virtualisieren und sich so von Abhängigkeiten von diesen heterogenen Komponenten zu befreien. Mit der Service-Virtualisierung werden Hunderte von Produktionsvorbereitungslaboren zu einer einzigen, wesentlich leichter zu verwaltenden Infrastruktur zusammengefasst, die die softwarebasierte On-Demand-Provisionierung für alle erforderlichen Umgebungen ermöglicht. Projekte, an denen zurzeit keine Veränderungen vorgenommen werden, verbrauchen keinen Strom mehr, erzeugen keine Abwärme und kosten keinen Platz im Rechenzentrum. Abhängigkeiten werden erfasst und eliminiert. Statt auf das tatsächliche System für die Mainframe-Partition zugreifen zu müssen, provisioniert das Team on-demand einen virtuellen Service des Kunden-Informationsmanagementsystems. Voraussichtlicher Nutzen: schnellere Bereitstellung durch Zugang zu isolierten Laborumgebungen für alle Entwicklungs- und Testteams rund um die Uhr geringere Kosten im Vergleich zur konventionellen Produktionsvorbereitungsinfrastruktur potenzielle Einsparungen ab 20 Mio. USD pro Jahr für größere Unternehmen Eliminierung von Servicekosten und -gebühren für den Zugriff auf dezentrale Systeme Möglichkeit für Teams, das Testing an einen früheren Zeitpunkt zu verlagern und lange vor herkömmlichen Anwenderakzeptanztests für hohe Qualität auf der Ebene der Komponentenentwicklung und Systemintegration zu sorgen; Verringerung des Zeitaufwands für Einrichtung und Rücksetzung von Daten um bis zu 90 Prozent, sodass die Testlebenszykluszeiten insgesamt um 40 bis 60 Prozent gesenkt werden können Beachten Sie außerdem, dass nicht nur die virtualisierten Komponenten heterogen sind, sondern auch die Tools auf Prozessebene, die Teams für die Zusammenarbeit nutzen. Lösungen für die Service-Virtualisierung müssen unbedingt eine herstellerunabhängige Grundlage für die Tools bereitstellen, mit denen Teams bereits arbeiten. Die Service- Virtualisierung sollte Zielumgebungen bereitstellen, die zusammen mit den bestehenden Lösungen für den Anwendungslebenszyklus verwendet werden können, wie mit Test Management (TM), Fehlermanagement/ Problemverfolgung, Test Data Management sowie führenden Virtualisierungsprodukten für Hardware und Testlabor, die bereits Teil der Umgebung sind.

10 White Paper: Schlüsselfunktionen einer LÖSUNG FÜR DIE SERVICE-VIRTUALISIERUNG Abschnitt 5: Fazit Die ersten Schritte optimal wählen Wie oft haben Sie Ihre Entwicklungs- oder Testing-Manager schon gefragt: Warum haben Sie den vereinbarten Liefertermin nicht eingehalten? und dann als Erklärung bekommen, dass sämtliche Gründe für die Verzögerung bei anderen Teams und ihren (mutmaßlich) nicht eingehaltenen Versprechen oder ihren Schwierigkeiten lagen? Beispiele wie die folgenden wurden uns berichtet und habe ich selbst erlebt: Ja, aber wir sollten das Design für das neue Auftragsmanagementsystem letzten Monat bekommen, und es wurde uns erst letzte Woche zur Verfügung gestellt. Oder: Ja, aber jedes neue Design des Auftragsmanagementsystems hat zwar einige neue Aspekte gebracht, die wir benötigten, aber andere Funktionen beschädigt, die wir schon zum Laufen gebracht hatten. Oder: Ja, aber der Stub, den das andere Team mir für das Auftragsmanagement gegeben hat, enthält nur ein einziges Kundenprofil, sodass ich keines der anderen Szenarien erstellen oder testen kann, die ich aber unbedingt benötige, um das zu erledigen. Letztlich können wir unsere Arbeit so lange nicht erledigen, bis andere Personen ihre Ja, aber -Aufgabe erfüllt haben. Jedes Team, das an einer Composite-Anwendung arbeitet, muss die Möglichkeit haben, on-demand sein eigenes Labor aus der Infrastruktur zu erstellen. Abhängigkeiten zwischen Teams sind unvermeidlich. Deshalb sind Service- Virtualisierungs-Funktionen so wichtig. Jedes Team kann die Spezifikationen der nachgelagerten Abhängigkeiten nehmen und den erwarteten Sollzustand seiner nachgelagerten Abhängigkeiten nachbilden, ohne das erste Design dieser nachgelagerten Abhängigkeiten tatsächlich sehen zu müssen. Die Service-Virtualisierung bietet eine wichtige Plattform für Entwicklung und Testing von Unternehmenssoftware. Bei der Planung einer Strategie für die Service-Virtualisierung müssen viele weitere Details beachtet werden, insbesondere organisatorischer Art. Wer trägt zu der Lösung bei, und wer nutzt sie? Wer ist in Ihrem erweiterten Unternehmen von Teams und Partnern für die virtuellen Services verantwortlich und verwaltet sie? Ein guter Ansatz für die Service-Virtualisierung berücksichtigt nicht nur die technischen Details, sondern auch die betrieblichen Aspekte, um weitreichende Akzeptanz und Erfolge zu ermöglichen. Kontaktieren Sie CA Technologies unter CA Technologies (NASDAQ: CA) entwickelt Software, die Unternehmen bei der Umstellung auf die Application Economy unterstützt. Software steht im Mittelpunkt jedes Unternehmens in allen Branchen. Von der Planung über die Entwicklung bis zum Management und der Security arbeitet CA Technologies weltweit mit Unternehmen zusammen, um die Art, wie wir leben, Transaktionen durchführen und kommunizieren, mit zu verändern, ganz gleich, ob in mobilen, privaten und öffentlichen Cloud-Umgebungen oder in verteilten Systemen und Mainframe-Umgebungen. Weitere Informationen finden Sie unter. Copyright 2014 CA Technologies. Alle Rechte vorbehalten. Alle Markenzeichen, Markennamen, Dienstleistungsmarken und Logos, auf die hier verwiesen wird, sind Eigentum der jeweiligen Unternehmen. Dieses Dokument dient ausschließlich zu Informationszwecken, und CA Technologies übernimmt keine Verantwortung für die Richtigkeit oder Vollständigkeit der hierin enthaltenen Informationen. Soweit nach anwendbarem Recht erlaubt, stellt CA Technologies dieses Dokument im vorliegenden Zustand ohne jegliche Gewährleistung zur Verfügung; dazu gehören insbesondere stillschweigende Gewährleistungen der Markttauglichkeit, der Eignung für einen bestimmten Zweck und der Nichtverletzung von Rechten Dritter. In keinem Fall haftet CA Technologies für Verluste oder unmittelbare oder mittelbare Schäden, die aus der Verwendung dieses Dokumentes entstehen; dazu gehören insbesondere entgangene Gewinne, Betriebsunterbrechung, Verlust von Goodwill oder Datenverlust, selbst wenn CA Technologies über die Möglichkeit solcher Schäden informiert wurde. C cs200-94676_1114