Aufgabe: Analyse vorhandener Assets
Diese Aufgabe identifiziert die Designelemente einer serviceorientierten Lösung hinsichtlich der Services und Partitionen und dokumentiert die erste Spezifikation dieser Services.
Zweck
  • Designelemente einer serviceorientierten Lösung hinsichtlich der Services und Partitionen identifizieren
  • Erste Spezifikation von Services dokumentieren
  • Abhängigkeiten und die Kommunikation zwischen Services bestimmen
Beziehungen
RollenHauptrollen: Zusätzliche Rollen: Unterstützende Rollen:
EingabenVerbindlich: Optional: Extern:
  • Ohne
Ausgaben
Hauptbeschreibung
Die Analyse vorhandener Assets ist der Prozess der Nutzung von vorhandenen Assets (z. B. vorhandenen Systemen wie handelsübliche oder kundenspezifische Anwendungen) und von branchenspezifischen Standards, Modellen und Assets für die Realisierung von Services. Mit einer Bottom-up-Strategie identifiziert die Analyse vorhandener Assets geeignete Services, Komponenten und Abläufe und validiert diese. Technische Einschränkungen im Zusammenhang mit vorhandenen Systemen sollten im Interesse des Risikomanagements so früh wie möglich ausgewertet werden. Die Entscheidungsfindung bezüglich der technischen Durchführbarkeit einer Servicerealisierung schließt sich oft unmittelbar an die Analyse vorhandener Assets an oder beginnt sogar noch während der Analyse.
Schritte
Geeignete Services anhand von kundenspezifischen Anwendungen identifizieren

Die von vorhandenen Anwendungen bereitgestellte Funktionalität wird in zwei Teilschritten identifiziert. Der erste Teilschritt ist die grobe Zuordnung von Geschäftsprozessen zum Portfolio der vorhandenen Anwendungen. Beim zweiten Teilschritt, der differenzierten Zuordnung, wird ein Service einer bestimmten Transaktion oder einem Stapelprozess innerhalb der herkömmlichen Anwendung zugeordnet. Die differenzierte Zuordnung erfolgt während der Servicespezifikation.

Bei der groben Zuordnung geht es darum, eine erste vorläufige Zuordnung von Geschäftsfunktionen zu Services abzuleiten.

Um ausgehend von der Funktionalität vorhandener Anwendungen geeignete Services identifizieren zu können, muss die Beziehung zwischen dem Geschäftsprozess und den vorhandenen Anwendungen verstanden werden. Diese Beziehung kann als allgemein definierte Zuordnung beschrieben werden. Die folgende Abbildung zeigt, dass diese Zuordnung zwischen den Geschäftsaktivitäten oder -prozessen und den Geschäftsfunktionen vorhandener Anwendungen hergestellt wird.

Zur Erfassung der Beziehungen zwischen Geschäftsprozessen und vorhandenen Anwendungen in einer groben Zuordnung sind die folgenden Schritte erforderlich:

  1. Nachvollziehen der von jeder Anwendung unterstützten Geschäftsfunktionen. Normalerweise kann jede Geschäftsfunktion einer Aktivität innerhalb eines Geschäftsprozesses zugeordnet werden.
  2. Erfassen der Attribute vorhandener Anwendungen in Bezug auf verwendete Technologien, Architekturstile usw.
  3. Identifizieren von Anwendungen, die allgemeine Services ausführen

Grobe Zuordnung und Analyse des Anwendungsportfolios

Das Erkennen des geschäftlichen Nutzens und der technischen Qualität vorhandener Anwendungen ist hilfreich für die Erstellung eines Transformationsplans, der den Services mit dem größten Nutzen die höchste Priorität zuweist, sowie für die Einschätzung des Umfangs und der technischen Risiken auf der Basis der technischen Qualitäten einer Anwendung, z. B. ihrer Kopplungsmöglichkeiten.

Die Analyse des Anwendungsportfolios gibt den Umfang und die Grenzen der groben Zuordnung vor. Beispielsweise würden Anwendungen mit geringfügigem geschäftlichem Nutzen oder geringem technischem Nutzen, die bereits als veraltet angesehen werden, wahrscheinlich nicht für die Identifikation geeigneter Services in Betracht gezogen werden.

Eine durchgeführte Analyse des Anwendungsportfolios kann Informationen zu vorhandenen Services für eine allgemein definierte Zuordnung liefern. Die Ausgabe dieser Analyse sind geeignete Services. Sehen Sie sich dazu die folgende Abbildung an.

Geeignete Services anhand von Standardsoftware identifizieren

Pakete unabhängiger Softwareanbieter werden im Allgemeinen implementiert, um einer Organisation die Nutzung von Subsystemen und/oder Servicekomponenten zu ermöglichen. Umfangreiche Pakete für die Unternehmensressourcenplanung, wie beispielsweise die von SAP, PeopleSoft und Oracle, werden oft als Komplettsysteme mit mehreren Subsystemen implementiert, die eine oder mehrere Domäne(n) einer Organisation vollständig unterstützen. Dieser Abschnitt beschreibt eine Reihe von Schritten, mit denen der Fachmann die Funktionalität und geeigneten Services von Paketen unabhängiger Softwareanbieter identifizieren kann. Diese Analyse stellt ausgehend vom Leistungsspektrum der vorhandenen Pakete unabhängiger Softwareanbieter Daten für die Matrix der Geschäftsfunktionen/-systeme, den Katalog der Geschäftsregeln und das Servicemodell bereit.

Anmerkung: Da alle Pakete unabhängiger Softwareanbieter verschieden sind, kann hier nicht für jedes Paket ein detailliertes präskriptives Konzept entwickelt werden. Die folgenden Aktivitäten beschreiben einen generischen Ansatz und eine generische Gruppe von Aktivitäten für Folgendes:

  • Identifizieren geeigneter Services in Paketen unabhängiger Softwareanbieter
  • Identifizieren problemorientierter Merkmale von Paketen unabhängiger Softwareanbieter, die bei der Servicerealisierung beachtet werden müssen

Identifikation von Paketen unabhängiger Softwareanbieter

Im Idealfall wurden Pakete unabhängiger Softwareanbieter für die relevanten Domänen und Geschäftskomponenten bereits als Eingabe des Geschäftskomponentenmodellsystems für das Geschäftskomponentenlayout (oder ähnliches) identifiziert. Dann würde bereits eine Liste von Paketen unabhängiger Softwareanbieter vorliegen, die die für die anvisierte Lösung erforderliche Funktionalität der entsprechenden Geschäftskomponenten bereitstellen. Falls diese Eingabe fehlt, müssen die Pakete unabhängiger Softwareanbieter, die die relevanten Domänen und Geschäftskomponenten unterstützen, identifiziert und Geschäftskomponenten zugeordnet werden.

Beachten Sie, das Pakete von unabhängigen Softwareanbietern, z. B. von SAP, PeopleSoft und Oracle, aus einer Reihe von Kernmodulen und optionalen Modulen bestehen. Von SAP gibt es beispielsweise ein Fertigungsmodul, ein Modul für Personalwesen und ein Modul für Customer-Relationship-Management. In solchen Fällen muss genau angegeben werden, welche konkreten Module der Pakete unabhängiger Softwareanbieter verwendet werden. Dadurch ist eine fokussierte Analyse möglich, die Zeit spart und eine unnötige Ausuferung von Services vermeiden hilft.

Kategorisierung von Paketen unabhängiger Softwareanbieter

Die Kategorisierung von Paketen unabhängiger Softwareanbieter ermöglicht einen ersten Einblick in die wichtigen Merkmale, die bei der Servicerealisierung in Betracht gezogen werden müssen. (Dies gilt für funktionale und technische Komponenten.) Die unabhängigen Softwareanbieter können anhand von Merkmalen wie Kompetenz, Größe und Umsatz drei verschiedenen Ebenen zugeordnet werden. Eine solche Zusammenfassung sehen Sie in Tabelle 10. Achten Sie besonders auf die Aspekte der technischen und geschäftlichen Auswirkungen.

Kategorie für unabhängige Softwareanbieter Anbieter der Ebene 1 Anbieter der Ebenen 2 und 3
Beschreibung Große unabhängige Softwareanbieter, z. B. Hersteller von Software für Unternehmensressourcenplanung, die Anwendungspakete bereitstellen, die Unternehmen bei der Verwaltung ihrer Kernressourcen und -operationen unterstützen Mittlere und kleinere unabhängige Softwareanbieter, die in den meisten Fällen branchenspezifische vertikale Geschäftslösungen bereitstellen
Merkmale
  • Stellen integrierte, branchenübergreifende und aus mehreren Modulen aufgebaute Anwendungen für Produktplanung, Einkauf, Inventarverwaltung, Interaktionen mit Lieferanten, Kundendienst und Auftragsüberwachung bereit.
  • In Paketen können auch Anwendungsmodule für die Bereiche Rechnungswesen und Personalwesen in einem Unternehmen enthalten sein.
  • In der Regel werden mehrere Geschäftskomponenten oder sogar Domänen in einer Geschäftskomponentenmodellübersicht abgedeckt.
  • Im Paket sind oft proprietäre Middleware- und Sicherheitskomponenten sowie weitere technische Komponenten enthalten.
  • Sie sind in der Regel auf branchenspezifische vertikale Subsysteme spezialisiert, die eine bestimmte Funktion innerhalb eines Unternehmens unterstützen.
  • Pakete haben normalerweise dokumentierte Geschäftsschnittstellen zu Angeboten von Anbietern der Ebene 1.
  • In der Regel werden eine Domäne des Geschäftskomponentenmodells und eine kleine Anzahl von Geschäftskomponenten abgedeckt.
  • Die Angebote setzen oft externe Middleware anderer Anbieter und andere technische Komponenten voraus.
  • Viele Anbieter haben eigene Sicherheitskomponenten.
Technische Auswirkungen Aufgrund ihrer Marktstellung können diese unabhängigen Softwareanbieter einen signifikanten Einfluss auf die technische Architektur und auf technische Standards innerhalb eines Unternehmens haben. Solche Einflüsse werden ggf. während der Servicerealisierung identifiziert und untersucht.
Die Middleware und andere technische Komponenten wie Authentifizierung und Protokollierung werden während der Servicerealisierung berücksichtigt.
Diese unabhängigen Softwareanbieter haben normalerweise weniger Einfluss auf die Architektur innerhalb einer großen Organisation. In einer kleinen, hochspezialisierten und branchenspezifischen Organisation können sie jedoch auch einen bedeutenden Einfluss auf die Servicerealisierung haben.
Pakete werden in der Regel nicht mit eigenen Middlewarekomponenten oder technischen Komponenten bereitgestellt. Sie können auf die entsprechenden Komponenten anderer Anbieter zurückgreifen oder auf Middlewarekomponenten bzw. technische Komponenten von Anbietern der Ebene 1. Einige der kleineren unabhängigen Softwareanbieter stellen möglicherweise keine Schnittstellen zu technischen Komponenten bereit.
Geschäftliche Auswirkungen Organisationen, die in Pakete unabhängiger Softwareanbieter der Ebene 1 investiert haben, sind nicht selten bestrebt, diese Pakete maximal auszunutzen. Es kann also davon ausgegangen werden, dass diese vorhandenen Pakete gern für die Realisierung von Services genutzt und auch für die Implementierung neuer Services verwendet werden. Da diese Pakete tendenziell ein engeres Funktionsspektrum abdecken, besteht weniger Neigung und Möglichkeit, diese Pakete für die Realisierung neuer Services zu erweitern.
Beispiele SAP, Siebel, Peoplesoft, Oracle Financials Manugistics, Provia, Evoke

Da Pakete unabhängiger Softwareanbieter in praktisch jeder Organisation zum Einsatz kommen, umfassen die meisten serviceorientierten Lösungen Services, die mit Hilfe von Servicekomponenten aus Paketen unabhängiger Softwareanbieter realisiert werden. Durch die Kategorisierung dieser Pakete unabhängiger Softwareanbieter erkennt der Fachmann die Rolle und das Maß an Bedeutung, die diesen Paketen innerhalb der SOA-Lösung zuzumessen sind, und kann darüber hinaus technische und funktionale Merkmale identifizieren, die während der Servicerealisierung untersucht werden.

Durch die Analyse, die während der Kategorisierung für jedes Paket eines unabhängigen Softwareanbieters durchgeführt wird, ergeben sich Erkenntnisse in folgenden Bereichen:

  1. Einsichten bezüglich der Bedeutung und des Einflusses, die ein Paket innerhalb des Unternehmens hat
  2. Die Tendenz, alle neuen Services unter Verwendung dieses Pakets zu realisieren
  3. Erkenntnisse über die im Paket verwendeten Architekturstandards und technischen Komponenten sowie deren Rolle innerhalb des Unternehmens
  4. Besseres Verstehen der Middlewarekomponenten und technischen Komponenten, die mit dem Paket kompatibel sind

Analyse der Servicezugriffsoptionen innerhalb von Paketen unabhängiger Softwareanbieter

Dieser Schritt identifiziert die Mechanismen, mit denen auf Funktionen innerhalb der Pakete unabhängiger Softwareanbieter zugegriffen werden kann. (Das heißt, es wird ein direkter Bezug der technischen Aspekte des Pakets zur Verfügbarmachung und Realisierung von Services hergestellt.) Diese Informationen unterstützen die Identifikation geeigneter Services innerhalb der Pakete unabhängiger Softwareanbieter (die als nächster Schritt ansteht) und können später bei der Einschätzung der technischen Durchführbarkeit sowie bei der Entscheidungsfindung bezüglich der Servicerealisierung verwendet werden.

Für den Zugriff auf Pakete unabhängiger Softwareanbieter können mehrere Mechanismen genutzt werden. In diesem Schritt werden die für relevante Pakete verfügbaren Mechanismen analysiert und beschrieben. Im Allgemeinen unterstützen Pakete unabhängiger Softwareanbieter mindestens einen der folgenden Mechanismen:

Mechanismus Beschreibung
Direkte Verfügbarmachung als Service Das Paket macht Funktionalität direkt in Form SOA-kompatibler Services verfügbar, bei denen es sich in der Regel um Web-Services handelt. Diese Services können in einem Katalog aufgelistet sein. Die genaue Implementierung wird hinsichtlich ihrer Konformität mit Standards und ihrer Interoperabilität bewertet.
Verwendung von APIs Das Paket stellt APIs bereit, die für die Verfügbarmachung von Services innerhalb des Pakets genutzt werden können. Diese APIs können direkt verwendet werden, um Funktionen als Services verfügbar zu machen. Es können aber auch Web-Services-Wrapper oder eine Web-Services-Fassade entwickelt werden, die den Zugriff auf die Funktionen über die APIs ermöglichen.
Direkter Datenzugriff Wenn keine APIs zur Verfügung stehen, jedoch ein Service erforderlich ist, der vom Paket des unabhängigen Softwareanbieters verwaltete Daten verfügbar macht, wird ein Service entwickelt, der direkt auf die vom Paket verwendete Datenbank zugreift.
Anmerkung: Auch wenn diese Strategie technisch umgesetzt werden kann, birgt die Umgehung der Geschäftslogik innerhalb des Pakets eines unabhängigen Softwareanbieters ein potenzielles Risiko, dass Daten beschädigt werden oder die programmatisch gewährleistete Datenintegrität verletzt wird. Aus diesem Grunde sollte dieses Verfahren Services vorbehalten bleiben, die ausschließlich Leseoperationen ausführen. Selbst dann ist diese Vorgehensweise noch risikobehaftet, weil Änderungen am Datenschema des unabhängigen Softwareanbieters nicht auszuschließen sind. Somit ist große Vorsicht im Umgang mit diesem Verfahren geboten.

Verfahren für die Identifikation von Services in Paketen unabhängiger Softwareanbieter

In diesem Schritt werden verschiedene Verfahren für die Analyse von Paketen unabhängiger Softwareanbieter verwendet, um Funktionalität zu identifizieren, die potenziell als Service verfügbar gemacht werden kann. Die mit der Funktionalität verbundenen Geschäftsregeln werden ebenfalls identifiziert. Jedes Verfahren wird angewendet, um Pakete unter einem anderen Gesichtspunkt zu bewerten. Somit ist eine gründliche Analyse auf geeignete Services möglich. Die Analyseergebnisse werden in der Matrix der Geschäftsfunktionen/-systeme und im Katalog der Geschäftsregeln erfasst. Die geeigneten Services werden wie bei den anderen SOMA-Identifikationsaktivitäten zum Serviceportfolio und zur Servicehierarchie hinzugefügt.

  1. Katalog der vordefinierten Services für das Paket des unabhängigen Softwareanbieters prüfen

    Manche Pakete unabhängiger Softwareanbieter enthalten einen Katalog vordefinierter Services. In einem solchen Fall werden geeignete Services für die relevanten Domänen und Geschäftskomponenten anhand des Katalogs identifiziert und zum Serviceportfolio hinzugefügt. Wird dieses Verfahren vom unabhängigen Softwareanbieter unterstützt, ist es der einfachste Weg, geeignete Services in den Paketen zu identifizieren.

    Anmerkung: Während des SOMA-Spezifikationsschrittes fließt die Granularität dieser Services in die Entscheidungen über die Verfügbarmachung von Services ein. Deshalb ist es wichtig, die Granularität während der SOMA-Identifikation als Merkmal geeigneter Services zu erfassen. Möglicherweise müssen verfügbar gemachte Services zusammengefasst oder zerlegt werden. Dies hängt davon ab, in welchem Maße sie mit den Services innerhalb der Pakete unabhängiger Softwareanbieter in Einlang zu bringen sind. Diese Analyse trägt auch dazu bei, geeignete Services in die Servicehierarchie einzuordnen.
  2. APIs für das Paket des unabhängigen Softwareanbieters prüfen

    Pakete unabhängiger Softwareanbieter können APIs anbieten, die für den Zugriff auf die Funktionalität der Pakete genutzt werden können. Diese APIs werden für die relevanten Domänen und Geschäftskomponenten untersucht, um geeignete Services für das Serviceportfolio identifizieren zu können. Da über diese APIs zugängliche Funktionen nicht nativ als Service angeboten werden, muss ein Service-Wrapper oder eine Servicefassade entwickelt werden, um diese API-Aufrufe als Services verfügbar zu machen. Diese Vorgehensweise ermöglicht dank ihrer Flexibilität die Kombination von API-Aufrufen innerhalb eines Service. Auf diese Weise können Services innerhalb der Pakete so entwickelt werden, dass sie mit den Services in der Servicehierarchie in Einklang stehen. Der Fachmann identifiziert in diesem Fall Services innerhalb der Servicehierarchie und ordnet diese der unterstützenden Funktionalität und den API-Aufrufen der Pakete zu.
  3. Geschäftsprozesspläne und -abläufe für das Paket des unabhängigen Softwareanbieters prüfen

    Die durch das Paket eines unabhängigen Softwareanbieters ermöglichten Geschäftsprozesse und Abläufe können als Hardcopy oder in elektronischem Format dokumentiert werden. Diese Artefakte werden untersucht, um zusätzliche geeignete Services für das Serviceportfolio zu identifizieren. Bei dieser Prüfung sollten die Geschäftsprozesse des Pakets sowie der Ablaufkontext, in dem die Prozesse ausgeführt werden, umfassend und ganzheitlich betrachtet werden, um alle zugehörigen geeigneten Services identifizieren zu können und Fragen in Bezug auf die Geschäftsprozesse und Abläufe zu ermitteln, die während der Servicerealisierung berücksichtigt werden müssen.
  4. Serviceumfang für das Paket des unabhängigen Softwareanbieters identifizieren

    Ein Paket eines unabhängigen Softwareanbieters wird entwickelt, um Geschäftsprozesse zu unterstützen und Daten für den Geltungsbereich von Geschäftskomponenten (Funktionsbereichen) und Domänen zu verwalten. Diese Geschäftskomponenten bestimmen das Anwendungsgebiet oder den Serviceumfang der Pakete unabhängiger Softwareanbieter. In einzelnen Unternehmen kann das Paket eines unabhängigen Softwareanbieters jedoch auch für einen Teilbereich des möglichen Anwendungsgebiets implementiert werden. Indem der Fachmann den Gesamtumfang der Services für ein Paket eines unabhängigen Softwareanbieters identifiziert, kann er feststellen, ob weitere Services aus diesem Gesamtumfang zum Serviceportfolio hinzugefügt werden sollten. Noch wichtiger ist, dass er ermitteln kann, ob neue erforderliche Services mit Hilfe der Pakete unabhängiger Softwareanbieter realisiert werden können.

    Wenn festgestellt wird, dass für eine serviceorientierte Lösung neue Services notwendig sind, sollte der Fachmann prüfen, ob diese Services vom Serviceumfang des Pakets eines unabhängigen Softwareanbieters abgedeckt werden. Ist dies der Fall, müssen die Services des Pakets, die die erforderliche Funktionalität unterstützen, identifiziert und zum Serviceportfolio hinzugefügt werden. So kann das gesamte Leistungsspektrum des Pakets für die Lösung nutzbar gemacht werden. Außerdem wird auf diese Weise das Risiko verringert, dass innerhalb mehrerer Systeme, die dieselbe Geschäftskomponente unterstützen, Duplikate entwickelt werden.
  5. Analyse der innerhalb von Paketen unabhängiger Softwareanbieter gesteuerten Datenelemente

    Die für die Lösung relevanten Datenelemente werden ausgewertet, um festzustellen, ob sie innerhalb der Pakete unabhängiger Softwareanbieter verwaltet werden. Falls die Daten innerhalb der Pakete verwaltet werden, müssen weitere Prozesse innerhalb des Pakets, die dieselben Daten lesen oder aktualisieren, auf geeignete Services für das Serviceportfolio analysiert werden.

    Diese Analyse zeigt auch zugehörige oder externe Prozesse und Schnittstellen auf, die von der Lösung betroffen sein können und während der Softwarerealisierung beachtet werden müssen. Diese Prozesse und Schnittstellen werden während der Servicerealisierung dokumentiert und bewertet.
  6. Analyse von Sicherheitskomponenten und anderen technischen Komponenten des unabhängigen Softwareanbieters

    Viele Pakete unabhängiger Softwareanbieter enthalten eigene Sicherheitskomponenten für Authentifizierung und Berechtigung und können technische Komponenten zur Unterstützung von Funktionen wie Protokollierung und Messaging bereitstellen. Diese Komponenten werden für jedes Paket identifiziert und analysiert, um geeignete technische Services für das Serviceportfolio zu identifizieren.

    Darüber hinaus werden im Rahmen dieser Analyse alle Probleme und Einschränkungen identifiziert, die durch diese Komponenten auftauchen könnten und bei der Servicerealisierung berücksichtigt werden müssen. Während der Servicerealisierung muss beispielsweise Klarheit darüber bestehen, welche Interaktion mit den Sicherheitskomponenten des Pakets erforderlich ist, um auf die Funktionalität des Pakets zugreifen zu können, damit die Voraussetzungen für diese Interaktion geschaffen werden können.

Die Anwendung dieser verschiedenen Analyseverfahren ermöglicht die Identifizierung geeigneter Services innerhalb der relevanten Pakete unabhängiger Softwareanbieter aus verschiedenen Perspektiven. Die Analysen bringen auch Probleme und Einschränkungen ans Licht, die funktionale und technische Komponenten eines Pakets mit sich bringen und bei der Softwarerealisierung in Betracht gezogen werden müssen.

Dokumentation nicht funktionaler Asset-Voraussetzungen sicherstellen

Bei der Dokumentation nicht funktionaler Anforderungen für vorhandene Assets müssen die folgenden wichtigen Themenbereiche berücksichtigt werden.

  • Ausnahmebehandlung - Es muss Klarheit über die Funktionsweise der modernen Ausnahmebehandlung bestehen. Wenn bei der Stapelverarbeitung eine Ausnahme eintritt, wird das Programm abgebrochen (abnormal beendet) und ein Kernspeicherauszug erstellt. Der Programmierer muss sich den Kernspeicherauszug ansehen und daraus ableiten, was zu tun ist. Möglicherweise ist das nicht akzeptabel. Es müsste ermittelt werden, welche Vorgehensweise notwendig ist, z. B. wie eine Integration in das Framework für Ausnahmebehandlung erfolgen kann.
  • Prozess- und Datenverteilung - Sie müssen untersuchen, wo die Daten und Prozesse ausgeführt werden. Auf einer Maschine ausgeführte CICS-Anwendungen können eine Anfrage an eine andere Maschine senden (was in CICS auch als Function Shipping bezeichnet wird) oder per Fernaufruf Daten auf einer anderen Maschine aufrufen. Eine direkte Verbindung zu einer fernen Maschine, auf der sich die Daten befinden oder der Prozess ausgeführt wird (über JDBC zur DB), könnte sich gegenüber dem indirekten Weg bei Verwendung eines Konnektors über JDBC zur DB als vorteilhafter erweisen.
  • Datenverfügbarkeit - Nehmen wir an, eine Kundendatei in VSAM erfordert ein Verwaltungsfenster von vier Stunden. In diesem Fall kann kein Kundendienst rund um die Uhr unterstützt werden. Es müsste über eine neue Speicherlösung nachgedacht werden.
  • Berechtigung/Authentifizierung: Bei vielen herkömmlichen Anwendungen sind die Berechtigungs- und Authentifizierungsverfahren im Anwendungscode enthalten. Dies würde eine Migration der Benutzerzugriffsverwaltung auf eine eingebundene verwaltete und von Best Practices unterstützte Umgebung erfordern.
  • Bereitstellungsverzug - Stapelverarbeitungsprogramme werden in der Regel einmal täglich in den Nachtstunden ausgeführt. Falls es erforderlich ist, ein solches Programm öfter auszuführen, muss das Terminplanungsprogramm modifiziert werden, um die Häufigkeit zu ändern.
Eigenschaften
Mehrere Vorkommen
Ereignisgesteuert
Fortlaufend
Optional
Geplant
Wiederholt anwendbar
Weitere Informationen