Unser letzter Blogartikel über die SAP-ISA-M-Methodik ist bereits ein paar Monate her. In der Zwischenzeit gab es einige entscheidende Weiterentwicklungen innerhalb der Methodik, welche im Folgenden näher skizziert werden.
Im Rahmen der Cloud-Zentrierung und der damit einhergehenden Cloud Suite, nutzt die SAP die ISA-M-Methodik hauptsächlich, um ihre eigene Cloud Integrations Plattform (SAP CPI) in den Fokus der Integrationsszenarien zu stellen. Im Zuge dessen wurden neben dem Design der Templates, des Logos und diverser anderer Grafiken auch wordings in der ISA-M-Methodik geändert und teilweise ergänzt.
1. Overview & Terms of Use
Aufgrund des Umbruches bei der SAP hin zu den Cloud- und AI-Technologien wurden die Grafiken farblich an das neue Design angepasst. Angefangen bei dem ISA-M-Logo, aus dem inzwischen sofort die drei Kernaspekte der SAP Integrationsstrategie mittels der ISA-M Methodik hervorgehen:
- Integration Domains
- Integration Styles
- Use Case Patterns
![]()
![]()
Ebenso neu im Logo verankert, ist dabei auch der Hinweis, dass es sich bei ISA-M um eine offene Methodik handelt, die weder hersteller- noch technologieabhängig ist. Denn aufgrund der universellen Einsetzbarkeit besitzt ISA-M nicht nur eine SAP-Relevanz.
Während die Zielgruppe der Methodik im Overview der ISA-M-Version 3.1 nicht erwähnt wurde, ist diese nun ergänzt worden. Enterprise Architects sowie Integration Architects sollen von ISA-M profitieren. Somit ist klar, dass sich die Zielgruppe der ISA-M-Methodik nicht nur an Integrationsarchitekten – die eine feingranulare Sicht auf die Dinge besitzen – wendet, sondern ebenso übergeordnete Sollzielbilder, welche das gesamtheitliche Big Picture einer unternehmensinternen Integrationslandschaft, Businesscapabilities als auch unternehmensstrategische Treiber und Einflussfaktoren betrachten.
Desgleichen wurde die SAP-Integrationsstrategie für Intelligent Enterprises mit in das Template aufgenommen. Daraus geht laut SAP hervor, dass mittels der SAP Cloud Suite inklusive der Cloud Platform Integration (SAP CPI) integrierte Unternehmen intelligente Unternehmen sind und diverse digitale Plattformen – wie ein Data Management sowie eine Cloud Platform– und Intelligent Suits – für Customer Experience, Manufacturing & Supply Chain, Digital Core, People Engagement und Network & Spend Management– verwenden.
Dabei folgt die Integration den folgenden vier Kernprinzipien.
- Out-of-the-box Integration
- Open Integration
- Holistic Integration
- AI-Driven Integration
![]()
![]()
Zum besseren Verständnis wie die ISA-M-Methodik anzuwenden ist, hat die SAP einen Use Case für Enterprise Architects bereitgestellt. Anhand dessen wird exemplarisch aufgezeigt, wie in drei Schritten eine Integration durch eine systematische Herangehensweise der Integration vereinfacht werden kann.
Die drei Schritte sind wie folgt:
- Eine unternehmensweite einheitliche Terminologie etablieren, welche ganzheitlich Bestand hat, zwischen Systemintegratoren kommuniziert wird und das dazu benötigte Wissen im Unternehmen untereinander geteilt werden muss (Common Terminology).
- Die Definition einer Integrationsstrategie, welche die aktuelle Integrationsarchitektur evaluiert, die Ziel-Integrationsarchitektur definiert sowie zukünftige Bausteine identifiziert und in POCs verprobt (Integration Strategy Definition).
- Die Definition von unternehmensweiten Integrationsrichtlinien, die Erstellung eines Blueprints für eine hybride Integrationsplattform im SAP- und Non-SAP-Bereich sowie eine Definition von Bereichen für Self-Service-Integrationen (Integration Governance & Hybrid Integration Platform).
![]()
Die Einhaltung der systematischen Herangehensweise einer Integration anhand der drei ISA-M-Schritte verhilft aus einer Ad-Hoc-Integration hin zu einer Self-Service-Integration heranzuwachsen. Überdies besteht durch die Einhaltung der erwähnten Schritte eine hohe Wahrscheinlichkeit den Integrations-Reifegrad steigern zu können.
![]()
Neben den grafischen Designanpassungen wurde ebenso die Struktur des ISA-M-Templates ausgeweitet und der Teil „Integration Styles & Use Cases Patterns“ zu einem Punkt zusammengeführt.
2. Integration Roles
Ein vollkommen neuer Punkt ist 2. Integration Roles, in dem exemplarisch einige Integrationsrollen aufgezeigt und erörtert werden. Mit den Integrationsrollen soll aufgezeigt werden, dass neben dem Enterprise Architect und Integration Architect zudem weitere Integrationsrollen und Verantwortungsträger existieren, die von der ISA-M-Methodik profitieren.
- Integration Developer
- Integration Administrator
- Business Domain Experts
- Business User
- Citizen Integrator
- Application / API Developer
![]()
3. Integration Domains
Eine weitere Anpassung wurde in den Grafiken der Integration Domains und des High-Level Assessment umgesetzt.
Die Übersicht der Integration Domains wurde nicht nur visuell an das neue Design angepasst. Kürzel wurden ausgeschrieben und neue wordings wie „B2G-Integration“ und „Government Agency“ ergänzen nun die Domain-Übersicht.
![]()
![]()
Eine sinnvolle Erweiterung hat das High-Level Assessment Template zur Bewertung der Integrationsarchitektur aufzuweisen. Hier wurde zwar lediglich die Spalte „To Be“ hinzugefügt, jedoch dient diese Spalte dem direkten Vergleich vom Ist-Zustand „As Is“ hin zur Soll-Bebauung der einzusetzenden Integrationstechnologien. Somit existiert nun neben der visuellen auch eine textuelle Gegenüberstellung der aktuellen Integrationslandschaft und der Soll-Bebauung.
![]()
![]()
4. Integration Styles & Use Cases Patterns
Immer häufiger wurden wir mit der Frage konfrontiert, ob mit ISA-M denn auch mehrere Integration Styles gleichzeitig abgebildet werden können. Ja das können sie und konnten sie bereits in der Version 3.1. Einst wurde dieser Integration Style mit „Enabling Services“ deklariert, jedoch wurde auf diesen im Einzelnen nicht eingegangen. Von nun an ist von „Cross Use Cases“ die Rede, zu der es auch neben kleineren Erwähnungen detaillierte Informationen und Veranschaulichungen gibt.
Eine weitere größere Veränderung wurde bei den wordings der Integration Styles durchgeführt. Nunmehr ist die Rede von Integration anstatt von Invocation, Movement oder Consumption. Hierdurch rückt das Element der Integration klar und deutlich in den Fokus der ISA-M-Methodik.
Die Inhalte der einzelnen Integrationsstile hingegen haben sich nicht verändert.
![]()
![]()
Wie bereits erwähnt, wurden einzelne wordings vereinfacht.
- Process Integration [Process Invocation]
- Data Integration [Data Movement]
- User Integration [User-Centric Consumption]
- Thing Integration [Thing Integration]
- Cross Use Cases [Enabling Services]
Überdies wurde aber auch die Übersichtsgrafik der Integration Styles an das neue Design angepasst.
![]()
![]()
Eine neu hinzugefügte Grafik zeigt auf, inwiefern die Integration Styles und die Use Case Patterns in Beziehung zueinander stehen und sich voneinander ableiten. Welche Use Cases in einem Unternehmen existieren, muss nach wie vor jedes Unternehmen selber evaluieren und definieren. Für einen besseren Einstieg in die Use Cases bietet die SAP in der ISA-M-Methodik exemplarisch einige an. So bspw. kann bei der Process Integration eine A2A-Integration, B2B-Integration oder eine Business-Network-Integration durchgeführt werden.
![]()
Wie zuvor angemerkt, gibt es nun ein Template für Cross Use Cases, welches beispielhaft die API-Managed Integration, Event-Based Integration, Stream Analytics und das Workflow Management aufzeigt.
![]()
5. Technology Mapping
Auch aus der Übersichtsgrafik zum Integration Technology Mapping geht nun hervor, dass ISA-M SAP- und Non-SAP-Integrationskomponenten abbilden kann.
![]()
Aber nicht nur die Anpassung dieser Grafik, sondern auch neue Grafiken sind nun zum Technology Mapping hinzugekommen.
Den Anfang macht die Grafik „Customer Context“ im Kontext des Integration Technology Mappings. Hier wird aufgezeigt, welche exemplarischen Faktoren im Sinne des Kundenkontextes in einem Unternehmen berücksichtigt und evaluiert werden sollten. Hierzu gehören Aspekte wie bereits vorhandene Skills, vorhandene Investments, industrielle Unternehmensanforderungen, die aktuelle und geplante Anwendungslandschaft, die IT-Architekturstrategie und welche verfügbaren Out-Of-The-Box-Inhalte von den Integrationssystemen bereits zur Verfügung stehen.
![]()
Des Weiteren wurde ein Template hinzugefügt, welches explizit auf die einzelnen Recommendation Degrees eingeht, die am Ende im Decision Table Template verwendet werden sollen.
![]()
Darauf aufbauend werden nun für jeden Integration Style beispielhaft veranschaulicht, wie die Templates zu verwenden sind. Auch hier gibt es wieder grafische Änderungen, die den Gesamtprozess veranschaulichen. Zur Beschreibung und Erläuterung ziehen wir die Process Integration heran. Zunächst einmal wird die Übersichtsgrafik der Integration Domains betrachtet und die betroffenen Bereiche bzw. Use Cases und Komponenten farblich gekennzeichnet. Folgend sind für den Integration Style „Process Integration“ sämtliche Use Cases farblich markiert, die möglich sind. Diese müssen von jedem Unternehmen evaluiert und selber gekennzeichnet werden, so dass ein einheitliches Bild pro Use Case und Integration Style entsteht.
![]()
Anschließend wird das Decision Table Template herangezogen und alle relevanten Felder befüllt. So wird in der ersten Zeile bspw. die SAP CPI als Integrationstechnologie für On-Premise to Cloud und Cloud to Cloud generell empfohlen. Zusätzlich sollte man eine Deskription hinzufügen, welche bspw. aussagt, welche Einschränkungen, Richtlinien oder für welche Fälle die Integrationstechnologie einzusetzen ist.
![]()
Ebenso neu hinzugekommen ist eine Grafik, die aufzeigt, wie und in welchem Zusammenspiel die SAP Process Integration (SAP PI) bzw. Orchestration (SAP PO) mit der SAP CPI interagiert und welche Applikationen von Relevanz sind. Auch diese muss an die aktuelle Unternehmensarchitektur angepasst werden.
![]()
Folgend zeigt ein tabellarischer Überblick auf, wie die SAP CPI und SAP PO verwaltet werden, welche Lizenzmodelle es gibt, welche Architektur zum Einsatz kommt, welcher vorkonfigurierte Integrationscontent bereits existiert, für welche Domain welche Integrationstechnologie präferiert wird und welche Entscheidungskriterien zu beachten sind.
Hervorzuheben ist, auch wenn hier explizit die SAP CPI und SAP PO gegenübergestellt werden, so kann diese Tabelle um weitere Integrationstechnologien wie bspw. der IBM DataPower erweitert und/oder ergänzt werden.
![]()
Ergänzend ist die folgende Grafik. Hier wird visuell der Application Layer aufgezeigt und wie mittels des SAP Application Interface Frameworks (AIF) Applikationen, Funktionen, Daten, Sicherheitsrelevante Aspekte, ein Application Logging bzw. Monitoring sowie Alarme verwaltet und das Fehlerhandling abgearbeitet werden können.
![]()
Anschließend werden die Integration Pattern auf den Integration Layer sowie Application Layer hin in Bezug auf die zu integrierende Technologie überprüft und mittels Empfehlung mit entsprechenden farblichen Punkten versehen.
![]()
Hier wird deklariert, welche Integration Pattern auf welchem Layer und welcher Integrationstechnologie integriert werden sollen. Zur Auswahl existieren hier drei Empfehlungsmöglichkeiten:
- Recommended
- Partially Possible
- Not recommended
Eine neue Informationsgrafik, die lediglich aufzeigt wie evolutionär sich der Wandel hin von Unaligned APIs hin zu Aligned APIs vollzogen hat, erläutert wie es zu dem Wandel gekommen ist und was es damit auf sich hat. Die SAP möchte mit dieser Grafik darauf aufmerksam machen, dass auch in Zukunft mit weiteren Standardschnittstellen zu rechnen ist, sodass der Integrationsaufwand vermehrt minimiert wird.
![]()
Zu guter Letzt hat das Template zu jedem Integration Style und dem dazugehörigen Technologie-Mapping weitere Informationen in Form einer Tabelle mit Links zur Verfügung gestellt.
![]()
![]()
Zudem ist eine Erweiterung im ISA-M Template im Bereich des Interface Assessment zu verzeichnen.
6. Interface Assessment
Im Interface Assessment werden die Integrationsszenarien anhand der Unternehmensszenarien und einzelnen technischen Interfaces zwischen Applikationen evaluiert und entworfen. Hierbei muss der Integration Style berücksichtigt werden, der in den einzelnen technischen Interfaces umgesetzt werden soll.
Zur visuellen Veranschaulichung wurde die folgende Grafik neu aufgenommen, um dem Nutzer der ISA-M-Methodik eine detailliertere Erläuterung zur Verwendung der Interface Assessment Templates darzubieten. So leitet sich das technische Interface Design vom Unternehmensszenario ab. Was über die einzelnen Interfaces integriert wird, hängt wiederum vom Use Case und dem dazugehörigen Integration Style ab.
![]()
7. CIO Guides
Zu guter Letzt wurde der Punkt „CIO Guides“ hinzugefügt, welcher Links zu weiteren Informationen und Technologie-Guides bereitstellt.
Fazit
Im Großen und Ganzen ist der Umfang des ISA-M Templates stark angewachsen, ohne dabei für Verwirrung zu sorgen. Das sich die Grafiken visuell an das neue SAP-Design angepasst haben, ist eine logische Folge des SAP-Wandels hin zu Cloud- und AI-Technologien.
Sämtliche neu hinzugekommene Grafiken und Erörterungen dienen dem User der ISA-M-Methodik dazu, ein klareres Bild und ein besseres Verständnis von ISA-M vermittelt zu bekommen und es problemlos anwenden zu können.
Der Wegfall von unnötigen Buzzwords und die Anpassung einiger wordings führen ebenfalls dazu, dass es dem User einfacher fällt, sich die Terminologie einzuprägen und anzuwenden.
Die jedoch größte evolutionäre Weiterentwicklung der ISA-M-Methodik besteht darin, dass es nun klare und deutliche Deskriptionen jedes einzelnen Schrittes gibt. Somit ist es offensichtlich nicht mehr nur eine Methode für Enterprise-, Integrations- sowie Solutionarchitekten, sondern ebenso eine Basis für Developer, Administratoren, User usw.
Mit den richtigen Mitteln und der richtigen Dosierung an Informationen und wordings kann sichergestellt werden, dass unternehmensweit ein nach Positionen abhängiges einheitliches Bild geschaffen und die dazu benötigte Terminologie etabliert werden kann.
Alles in allem hat die Version 3.2 der ISA-M-Methodik einen wichtigen und richtigen Schritt in die richtige Richtung gemacht und sollte aufgrund der verbesserten Erläuterungen berechtigterweise einen höheren Anklang in der Integrationsszene genießen.
Petershausen, 05.11.2019 (PresseBox) - InFrame Synapse Equipment Connector (EQC), an innovative integration software from camLine, enables manufacturers to quickly and easily equip their non-IIoT systems...
Diesen Fragestellungen waren auch die Beiträge auf der Agile Night gewidmet. Nach der Begrüßung durch Manfred Baumgartner (Leiter der ASQF Fachgruppe Agiliät, Nagarro), Andreas Mayerhofer-Bollek (stv. Leiter der ASQF Fachgruppe Agilität, Erste Group IT) und Gerwald Oberleitner (Microsoft Österreich) zeigte David Heitzinger (Raiffeisen Bank International) mit seinem Vortrag „Ein Containerschiff wird Agile“ wie es gelingen kann, ein sehr großes und komplexes Unternehmen auf den agilen Kurs zu bringen. Der Vortrag machte auch deutlich, dass dieser Wandel nicht von heute auf morgen geschieht. Viele Dimensionen sind zu beachten und zu bearbeiten und dies gelingt nicht gleichzeitig in allen Bereichen. Daher sieht Heitzinger eine „Adaptive Organisation“ als Voraussetzung für eine erfolgreiche agile Transformation. Der holistische Ansatz bei RBI zielt auf den Wandel von Projekten zu Produkten (tribes), Kultur, Mitarbeiter*innen, Organisation, Prozesse und Governance ab. Diese Veränderungen basieren auf formulierten und gelebten Werten wie agiles Mindset, agile Software-Entwicklung, DevOps, Value first, etc. All diese Anstrengungen werden aber nicht unternommen, weil Agil modern ist, sondern weil gerade auch für Unternehmen des Finanzsektors die See rauer geworden ist.
Nach der Pause, die von den Teilnehmer*innen intensiv für den Erfahrungsaustausch genutzt wurde, präsentierten Veronika Kotrba und Ralph Miarka (sinnvollFÜHREN) die „12F der Fairänderung“. Damit für Menschen die Veränderungen nicht ein Verlust („weg-von“), sondern ein Gewinn („hin-zu“) wird, muss diese auch als fair wahrgenommen werden. So gibt es zum Beispiel viel Funktionierendes, das nicht aus Prinzip in die Ecke gestellt werden muss, vieles geschieht Freiwillig und muss nicht verordnet werden, eine konstruktive Fehlerkultur und neue Formen des Führens in einer freundlichen Umgebung, schaffen die Grundlage für eine erfolgreiche Transformation ohne den Fokus auf das gemeinsame Ziel zu verlieren.
Oftmals treffen organisatorische Hierarchie und agile Teamrollen aufeinander ohne Klarheit darüber, wer was tun darf oder tun soll. Autonome Teams werden aufgestellt ohne dass die Entscheidungsgrenzen definiert sind. Richard Brenner (TechTalk) erläuterte in seinem Vortrag „Enable local decision making with clarity of roles and clear boundaries“, wie eine Kombination aus RACI-Matrix (Responsible, Accountable ,Consulted, Informed) und Delegationspoker dazu beiträgt, kontinuierlich an der organisatorischen Klarheit zu arbeiten. Dies ist keine einmalige Aufgabe, sondern eine kontinuierliche Diskussion zwischen den relevanten Parteien, immer mit dem Ziel, besser und fundierter lokale Entscheidungsfindung zu ermöglichen.
Im abschließendem Vortrag „Agilität weiter gedacht! Von der Software-Entwicklung in das gesamte Unternehmen.“ schilderte Valentin Klausburg (openFORCE) wie es der openFORCE gelungen ist, agile Prozesse, die in der Software-Entwicklung bereits erfolgreich im Einsatz waren, in die Unternehmensführung zu integrieren. Es wurde beleuchtet, warum die klassische Unternehmensführung nicht mehr ausreichend war und welche Lösungen für die Probleme gefunden wurden, die mit der agilen Transformation einhergegangen sind. Valentin Klausburg konnte davon berichten, wie nicht nur die Mitarbeiter*innen, sondern das gesamte Unternehmen vom Kulturwandel profitieren.
Vor dem gemütlichen Ausklang und Networking bedankte sich Manfred Baumgartner im Namen des ASQF bei allen Teilnehmern und bei den Sponsoren der Veranstaltung: Austrian Testing Board, d.punkt-Verlag, inflectra, iSQI,Microsoft sowie Nagarro.
