Gedanken zur Referenz-Architektur des IIoT

Referenzarchitekturen bilden die Grundlage für Best Practices und die Wiederverwendung der Architekturmuster.  Das Industrial Internet Consortium (IIC) hat die Notwendigkeit der Referenzarchitektur erkannt und die Industrial Internet Reference Architecture (IIRA) veröffentlicht. Diese dreistufige Architekutr bietet verschiedene Standpunkte, die auf die verschiedenen Interessensgruppen ausgerichtet sind. IIC definiert die Referenzarchitektur als das Ergebnis der Anwendung von Architekturprinzipien auf eine Klasse von Systemen.

Dies dient als Orientierungshilfe , da die Architekten die gemeinsamen architektonischen Probleme analysieren und lösen. Der daraus resultierende IIRA stellt dann eine Vorlage für die Verwendung in der konkreten Architektur von industriellen Internet-Systemen dar.

IIoT-Projekte und Architekturlösungen können sehr komplex sein. Ein bewährter Ansatz zu Lösung komplexer Problemstellungen ist die Zerlegung in seine Subsysteme. 

Die IIRA ist eine auf Standards basierende offene Architektur für IIoT-Systeme. Die IIRA maximiert ihren Wert durch die breite Anwendbarkeit in der Branche , um die Interoperabilität voranzutreiben, anwendbare Technologien abzubilden und die Technologie - und Standardentwicklung zu lenken. Die Beschreibung und Darstellung der Architektur ist generisch und auf einen hohen Abstraktionsniveau, um die erforderliche breite Anwendbarkeit in der Industrie zu unterstützen.

Bei der Betrachtung komplexer Systeme, wie sie von IIoT-Systemen erwartet werden, sind viele Akteure beteiligt. Die Systemkomplexität erfordert einen Rahmen , um die Anliegen der Stakeholder zu ermitteln und in geeignete Kategorien einzuordnen. Ein solcher Rahmen ermöglicht eine systematische Bewertung solcher Systeme sowie die für die Planung und den Aufbau solcher Systeme erforderliche Lösung.

Vergleich von RAMI 4.0 mit IIRA

Die Referenzarchitekturen RAMI 4.0 und IIRA beschreiben den logischen Aufbau von Gesamtsystemen und Prozessen im Umfeld des IIoT. Der Fokus liegt dabei auf der einheitlichen Definition von Abstraktionsebenen und semantischen Zusammenhängen. Beide Architekturen berücksichtigen dabei verschiedene Aspekte und strukturieren des Gesamtsystem hierarchisch mit Schichten.

Es gibt darüber hinaus zwischen den beiden Architekturen in Teilbereichen vielfach Gemeinsamkeiten , aber von Grundsatz her unterscheiden sich beide Architekturen doch erheblich. In der Tabelle sind die wesentlichen Unterschiede zwischen den beiden Referenzarchitekturen aufgeführt.

Meine Gedanken zur Trinität - Authentisierung - Authentifizierung - Authorisierung

 Authentisierung;     „Wer bin ich?“

 Authentifizierung:  “Wer sind Sie?“

Authorisierung;       “Was darf ich?“

Das Bezeichne ich als die Trinität, ich werde versuchen diese drei wichtigen Teile zu beschreiben.

Authentisierung

Unter Authentisierung versteht man den Nachweis der eigenen Identität. Dabei kann es sich um die Identität einer Person oder auch um die eines Computerprogramms handeln.

Im Allgemeinen kann man Authentisierungsmerkmalen in folgende drei Kategorien einteilen:

1. persönliches Wissen

2. persönlicher Besitz

3. biometrisches Merkmal

Unter 1 fallen die im Computerumfeld üblichen Passwörter , aber auch die Persönliche Identifikationsnummer (PIN) , Diese Merkmale haben mehrer Nachteile: So eignen sie sich beispielsweise nicht für sehr vergessliche Menschen. Außerdem können sie ausspioniert werden, auch ohne dass das Opfer es bemerkt.

Zu den Authentisierungsmerkmalen , die man besitzt (2) , zählen solche Dinge wie Fido Hardware Token , SSL - Zertifikate, JSON Web Token usw.

Der Nachteil der Merkmale der Kategorie 2 ist, dass man sie entwenden kann.

Die biometrischen Merkmale (3) gehören eigentlich auch zu den Dingen, die man besitzt. Sie haben aber den Vorteil, dass sie nicht so leicht zu entwenden sind. Zu diesen Merkmalen zählt man z.B. Aussehen,Stimme, Fingerabdruck, Augenhintergrund oder Unterschrift. Der Nachteil der biometrischen Merkmale liegt darin, dass Computer sie nicht besonders gut erkennen und verarbeiten können und dass die Authentisierung über diese Merkmale daher unter Umständen fehleranfällig ist.

Verwendung 

Alle drei Kategorien von Authentisierungsmerkmalen haben ihre Vor- und Nachteile . Idealerweise kombiniert man daher Merkmale verschiedener Kategorien, um die einzelnen Nachteile auszugleichen. Beispielsweise sind Geldgeschäfte mit einer EC-Karte (Merkmaltyp 2) nur durch zusätzliche Kenntnis einer PIN (Merkmaltyp 1) der durch leisten einer Unterschrift (Merkmaltyp 3) möglich. Auch die üblichen Token (Merkmaltyp 2) können nur in Kombination mit einer PIN (Merkmaltyp 1) benutzt werden.

Authentifizierung

Der Austausch der Informationen zwischen Benutzer und Webanwendung (Credentials der Session Token) erfolgt jeweils verschlüsselt und ist vor Manipulation geschützt. Jede Webanwendung welche eine vorherige Authentifizierung verlangt (Login) , hat auch ein Logout . 

Die Schritte sind im Einzelnen:

1. Der Benutzer möchte sich auf eine geschützte Webseite verbinden.

2. Die Anwendung stellt fest, dass für die geschützte Webseite eine Authentifizierung notwendig ist. Sie sendet dem Benutzer ein Formular zur Eingabe der Credentials.

3. Der Benutzer füllt das Formular aus (bei MFA können dies auch mehrere Formulare sein) und sendet es an die Anwendung.

4. Die Anwendung prüft gegen eine Verzeichnis, ob der Benutzer vorhanden , ob er für die entsprechenden Webseiten berechtigt ist (Authorisierung) und ob seine Credentials stimmen (Authentifizierung),

5. Ist soweit alles in Ordnung, wird dem Benutzer ein Session Token gesendet, welches für die aktuelle Session gültig ist.

6. Mithilfe des Session Token wird die Authentifizierung aufrechterhalten, ohne der Benutzer für jede Anfrage , welche er zur Webanwendung sendet, wieder authentifizieren muss.

Authorisierung

Die Autorisierung ist ein Synonym für die Zugriffskontrolle. Eng mit der Autorisierung verknüpft ist die Autditierbarkeit,mit deren Hilfe die Nutzung einer Ressource im Nachhinein überprüft werden kann. Eine Ressource kann im Kontext der Softwarearchitektur Daten meinen wie beispielsweise ein Dokument. Es kann sich aber auch um eine Geschäftsfunktion handeln, die geschützt werden soll. Es gibt hierfür zwei verschiedene Ansätze: den klassischen rollenbasierten Ansatz sowie die neuere , attributbasierte Ansätze ; den klassischen rollenbasierten Ansatz sowie die neuere , attributbasierte Authorisierung deren Vor- und Nachteile wie besprechen werden. Ein gängiges Dokument im Zusammenhang mit der Autorisierung ist das sogenannte Berechtigungskonzept , in dem sowohl die zu schützenden Ressourcen als auch die technische Strategie des Schutzes beschrieben stehen. Das Berechtigungskonzept heißt manchmal auch Rechte- und - Rollen-Konzept oder Access Control Policy. Die verschiedenen Konzepte und Prozesse rund um die Autorisierung stehen.

RBAC

Vorteile von RBAC

Der große Vorteil von RBAC ist der Determinismus; Man kann jederzeit leicht feststellen, wer auf welchen Ressourcen welche Berechtigungen besitzt. Dies macht das Berechtigungskonzept einfacher anpassbar und auch transparenter , da sich die Zusammenhänge leicht visualisierung lassen. Der Vorteil, die Auswirkungen von Änderungen im Vorfeld erkennen zu können, darf nicht unterschätzt werden. Daraus ergibt sich eine gute Auditierbarkeit des Systems auch für Business Owner. Für sie ist es einfach nachvollziehbar, welche Berechtigung er vergeben hat oder attestieren soll, da die Rollen klare Namen haben, die leicht verständlich sind. Generell gibt RBAC als einfacher als das ABAC-Modell, das wir weiter unten beschreiben.

Nachteile von RBAC

Der Nachteil von RBAC ist, dass die Rollen und Ressourcen bekannt sein müssen , um Entscheidungen im Kontext fällen zu können. Dies ist insbesondere für einen Administrator bei der Verwaltung schwierig , aber auch für einen Business Owner, der nur seine Ressourcen kennt, aber nicht die Rollen. Zudem kann die Anzahl der Rollen schnell explodieren, wenn zu feingranular berechtigt werden soll. Es besteht hier insbesondere das substanzielle Risiko dass Servicesemantik in das Rollenkonzept auf Geschäftsebene schwappt und dieses komplizierter als nötig macht.

Häufig wird bei RBAC die Verwaltung von Subdomänen delegiert. Die Delegation ist für Stellvertreterregelungen im IAM zwar sehr wichtig , aber das Rollenmodell läuft dann Gefahr , sich an der Delegatinsstruktur zu orientieren und nicht am Geschäft . Wenn viele Rollen im Einsatz sind, so muss auch eine große Anzahl von Delegationene in der Rollenverwaltung erstellt und gewartet werden. Dies bedeutet schlicht Overhead und kostet Geld. Es gibt zu RBAC diverse Zusätze , welche die Delegation erleichtern (PBDM, CRBAC).

ABAC

ABAC erlaubt den Zugriff auf Ressourcen über domänenspezufischer Attribute beispielsweise die Funktion im Unternehmen oder das Alter. Diese können dann für die Autorisierung verwendet werden. Wichtig bei diesem Konzept ist, dass nicht nur der Nutzer diese Attibute hat, sondern auch die Resource , auf die zugegriffen werden soll. Mittels einfacher mathematischer Funktionen kann ein ABAC-System dann entscheiden, ob der Zugriff erlaubt ist oder nicht. Bei diesem Verfahren kann etwa ein Dokument mit dem Attribut „Finance“ versehen werden. Hat ein Benutzer dann das Attribut „Controller“, greift eine Regel, die den Zugriff erlaubt.

Vorteile ABAC

Der größte Vorteil der attributbasierte Zugriffskontrolle ist, dass einfache Regeln definiert werden können. Diese können sehr feingranular und kontextbezogen sein, was bei RBAC schwierig ist. Zudem können die Regeln durch die Architektur auch Attribute von Ressourcen und Benutzern auswerten, die gar nicht im IDM-System vorhanden sind., sondern über den PIP provisioning werden. Es hat sich außerdem gezeigt, dass die Regeln wenig Pflege benötigen, da sie keine Struktur brauchen. Dies ist bei RBAC anders, da sich die Struktur durch die Rollen auch ändern können, wenn sich die Organisation verändert.

Nachteile von RBAC

ABAC kann auch zu einer Regelexplosion führen, ähnlich wie die Rollenexplosion beim RBAC. Hierdurch ist es auch schwierig , die Symmetrie herzustellen und so herauszufinden, welche Berechtigungen ein Benutzer hat. Hier muss gegebenenfalls eine große Anzahl von Regeln ausgeführt werden. Und dies in der exakt gleichen Reihenfolge , wie es für den Benutzer selbst erfolgt. In der Folge kann es unmöglich sein, Risiken bei Zugriffen festzustellen.

ABAC-Systeme können auch langsam in der Durchführung von Authorisationen sein, da Daten von mehreren anderen Services zur Berechnung benötigt werden. Da diese Berechnungen durch das ABAC-System nicht kontrolliert werden können, können sie auch nicht vorberechnet oder zwischengespeichert werden.

Neben der Authentisierung sind auch die Begriffe Authorisierung und Zugriffskontrolle (Access Control) wesentlich für jedes Sicherheitskonzept.

Beim Vorgang der Authorisierung wird festgelegt, mit welchen Berechtigung User auf Ressourcen im Netzwerk zugreifen dürfen. 

Meine Gedanken zu CPS und das IIoT

… Ein Cyber-Physical System (CPS) ist ein System, das reale (physische) Objekte und Prozesse verknüpft mit informationsverarbeitenden (virtuellen) Objekten und Prozessen über offene , teilweise globale und jederzeit miteinander verbundene Informationsnetze. Optional nutzt ein CPS lokal oder entfernt verfügbare Dienste, verfügt über Mensch-Maschine-Schnittstelle und bietet die Möglichkeit zur dynamischen Anpassung des Systems zur Laufzeit.

Für mich wird das CPS immer wichtiger werden um die Verbindung zwischen realen (physischen) Objekte und deren (virtuellen) Darstellungen immer wichtiger wird. Weiters die Verbindung eines Solchen Systems und eines HMI das ich weiterhin als wichtig erachte ,  nur die Aufgaben werden sich ändern bzw, anders gestalten. Der Mensch wird als Controller auftreten und weniger in den Standard Prozess eingreifen. 

Meine Gedanken werden in drei Abschnitten aufgeteilt werden:

Referenz-Architektur

Connectivity Framework

Security Framework

Diese drei Säulen bilden für mich den Ausgangspunkt meiner Betrachtung dienen , und werden in weiteren Blogs weiter betrachtet werden.

 Cyber-Physical Systems sind permanent vernetzt. Damit wird ermöglicht, eine Information für unterschiedlichste Anwendungen un in unterschiedlichsten Organisations- und Bereichsgrenzen verfügbar zu machen. Ein CPS ist in zwei Richtungen vernetzt horizontal und vertical.

Auf der horizontalen Ebene kommuniziert es mit Systemen auf der gleichen Ebene. Hierbei werden z.B. in einem Produktionssystem die nächsten Fertigungsschritte ausgehandelt oder Daten zum aktuellen Bearbeitungsstand eines Produkt ausgetauscht.Die horizontale Kommunikation kann jedoch auch zwischen Organisationsbereichen, wie beispielsweise zwischen Produktion und Konstruktion , erfolgen.

In vertikaler Richtung kommunizieren CPS mit über- oder untergeordneten Systemen. Dieser Aufbau spiegelt den zentralen Gedanken der verteilten Intelligenz wider: Die Produktion wird nicht länger durch eine zentrale Instanz gesteuert, sondern durch viele kleine Einheiten.

Es gibt folgende Funktionen eines CPS

Sensorik: Mittels Sensoren erfassen CPS die Realität. Dies ist die Basis für ein umfassendes Prozess - Monitoring

Aktorik: CPS können über Aktoren verfügen und Prozesse aktiv beeinflussen. Von besonderer Bedeutung ist dies in Robotikanwendungen.

Steuerung und Kontrolle: Durch eine gewisse Intelligenz können CPS autonom und ohne zentrale Instanzen Entscheidungen treffen und so Prozesse der realen Welt beeinflussen.

Vernetzung: CPS kommunizieren mit anderen CPS , mit Menschen (Bediener) und mit in den Unternehmen und Werschöpfungsketten bereits vorhandene IT-Systemen.

Daten- und Informations-Verarbeitung: CPS können Daten und Informationen verarbeiten. Microcontroller oder Mikroprozessoren sind ein essenzieller Bestandteil eines CPS.

Integration: CPS integrieren die reale und die virtuelle Welt sowohl innerhalb eines Unternehmens als auch unternehmensübergreifend. Basis dazu ist die automatische Identifikation von Objekten.

Anpassungs-Fähigkeit: CPS sollen das eigene Verhalten abhängig vom jeweiligen Kontext auf Basis von gelernten Wissen anpassen und die eigenen Fähigkeiten weiterentwickeln.

Technologie Agnostische Gedanken zur Hybriden Integration Teil 3

 Integration Solution Advisory Methodology (ISA-M)

In diesem dritten Teil möchte ich die ISA-M vorstellen. ISA-M ist eine von SAP entwickelte Methodik, mit deren Hilfe Enterprise-und Integrations-Architekt*innen eine Integrationsstrategie definieren und implementieren können.

Wer benutzt ISA-M

Als Zielgruppe dienen Enterprise - und Integrationss-Architekt*innen für ISA-M. 

Das bestmögliche Ergebnis erreicht man jedoch , wenn beide Zielgruppen gemeinsam mit ISA-M arbeiten: Die Integrationsarchitekt*innen geben die fachliche Expertise in der Bearbeitung der Themen vor, und die Enterprise-Architekt*innen bringen insbesondere die allgemeine architektonische Ausrichtung des Unternehmens in die Arbeit ein. Daher halte ich es für richtig , wenn ISA-M in Gemeinschaftsarbeit angewendet wird.

Übersicht

Ich beschreibe im Folgenden die vier vorgesehenen Phasen des Kreislaufs. Selbstverständlich haben Sie die Möglichkeit , vom beschriebenen Vorgehen auch abzuweichen; 

- Asses your Integration Strategy

Die Phase Assess your Integration Strategy hat zum Ziel, Ihre Integrationsarchitektur zu dokumentieren und zu begutachten. Hierzu beschreibt ISA-M verschiedene Ansätze . Mithilfe von Integrationsdomänen und Integrationsstilen können Sie sowohl ihre aktuelle Integrationslandschaft als auch ihre zukünftige Integrationslandschaft beschreiben. Beide Ansätze können aufeinander aufbauen.

Eine Weitere Methode , um ihre Integratiosstrategie zu bewerten , ist die Verwendung von Reifegradmodellen , wie schon in meinem vorigen Post beschrieben.

Design your Hybrid Integration Platform

Im Rahmen der zweiten Phase Design your Hybrid Integration Platform findet die Gestaltung der hybriden Integrationsplatform statt. Nach ISA.M sind die wichtigsten Aufgaben bei der Gestaltung einer hybriden Integrationsplattform die Zuordnung von Technologien und die Bewertung von Schnittstellen..

Define Integration Best Practices

Ziel dieser Phase ist es , mithilfe der beschriebenen Best Practices die Implementierung von neuen Integrationsanforderungen zu überwachen und Transparenz zum Schnittstellendesign zu erzeugen. 

Eine gute möglichkeit meiner Meinung nach sind die Architektur-Blueprints als Mittel zur Definition von Best Practices für die Integration.

Enable a Practice of Empowerment

In dieser Phase geht es um die Verbreiterung des Integrationswissen innerhalb der Organisation. Ziel dieser Phase ist es Integration als anerkannte Disziplin und strategische funktion innerhalb ihrer Organisation zu etablieren.. Einhergehend damit ist die weitere verbreitung von Integrationswissen durch eine Kultur der Wissensteilung.

Integrationsdomänen beschreiben typische Bereiche in einer hybriden Landschaft, in denen eine Integration erforderlich ist. Integrationsstile und Use Case Pattern umfassen eine Reihe von typischen technologieunabhängigen Integrationsanwendungsfällen. 

Schließlich können Integrationsstile und Anwendungsfälle basierend auf einem bestimmten Kundenkontext auf Integrationstechnologien/-dienste abgebildet werden.

Alles beginnt mit den Integrationsdomänen

Die Integrationsdomänen sind ideal, um eine grobe Einordnung von Schnittstellen und Schnittstellenanforderungen vorzunehmen.

Integrationsdomänen können als eine erste Indikation zur Einordnung von Schnittstellen und Schnittstellenanforderungen verwenden. Bereits auf der Ebene der Integrationsdomänen können Sie bestimmte Eigenschaften feststellen.

Integrationsdomänen bilden den Einstiegspunkt in ISA-M und können als "Big Picture" für die Integration genutzt werden. Sie können eine Bewertung Ihrer Integrationsarchitektur vornehmen, indem Sie die Integrationsdomänen auswählen, die für Ihr Unternehmen relevant sind oder die Sie eventuell weiter bewerten möchten. Anschließend können Sie Ihre aktuellen Integrationstechnologien/-dienste auflisten (Ist) und auch Ihre zukünftige Zielarchitektur ableiten (Soll). Integrationsdomänen sind technologieunabhängig und können daher auch beim Entwurf einer hybriden Integrationsplattform helfen, die aus mehreren Integrationsdiensten/-technologien besteht. Sie können auch Integrationsdomänen entfernen, die für Ihre Organisation nicht relevant sind.

Folgende Integrationsdomänen wurden von SAP vorgeschlagen:

User2Cloud

User2OnPremise

OnPremise2OnPremise

OnPremise2Cloud

Cloud2Cloud

Thing2Cloud

Thing2OnPremise

Mit den Integrationsdomänen können Sie die Frage beantworten, welche Art von Schnittstellen bzw. Schnittstellenanforderungen Ihre Integrationsarchitektur bedient oder welche von Ihrer Integrationsarchitektur bedient werden sollen. In diesem Zusammenhang beschäftigen Sie sich mit gleich zwei Fragestellungen :

Wo befinden sich die Anwendungen oder Systeme, die Sie miteinander integrieren wollen?

Welche Art von Anwendungen, Systemen , Organisationen oder Dingen soll bei Ihrer Integration miteinander kommunizieren?

Integratiosstile und Use Cases

Nachdem im ersten Schritt die relevanten Integrationsdomänen definiert wurden, müssen jetzt die anzuwendenden Integrationsstile beschrieben werden.

Integrationsstile decken die wichtigsten Integrationsarchetypen ab: Der Prozessintegrationsstil verbindet Geschäftsprozesse anwendungsübergreifend, während der Datenintegrationsstil es ermöglicht, Daten anwendungsübergreifend zu synchronisieren oder darauf zuzugreifen. Der Stil der Benutzerintegration ermöglicht die Verbindung von Objekten der realen Welt (z. B. Sensoren, Maschinen) mit Anwendungen. Der Integrationsstil "Analytik" ermöglicht die Ableitung und Offenlegung von Daten aus Datenquellen zur Unterstützung von Business Intelligence, Augmented Analytics und/oder Unternehmensplanungsszenarien. Alle Integrationsstile sind technologieunabhängig und können in verschiedenen Integrationsdomänen (z. B. Cloud, On-Premise, Hybrid) eingesetzt werden.

stilübergreifende Use Cases bilden eine Kategorie für alle integrationsbezogenen Anwendungsfälle, die einen oder mehrere der vier Kernintegrationsstile ergänzen. Zum Beispiel bietet API-Managed Integration ein vollständiges Lebenszyklusmanagement für APIs, das z. B. in benutzerprozesszentrierten Integrationsszenarien genutzt werden kann. 

Dabei wird folgende Frage beantwortet: "Wie integriere ich meine Lösungen?".

Folgende Integrationsstile werden verwendet:

- prozessbasierte Integration

- datenbasierte Integration

- Analytics Integration

- Integration der Benutzeroberflächen

- integration der Dinge

- stilübergreifende Integration (Cross Use Cases)

Folgende Use Cases gibt es derzeit

Für prozessbasierte Integration:

A2A Integration

Master Data Integration

B2B Integration

B2G Integration

Für Datenbasierte Integration:

Daten Replication

Daten Virtualization

Daten Quality Management

Daten Orchestration

Für Analytics Integration

Embedded Analytics

Applikation übergreifende Analytics

Für Integration der Benutzeroberflächen

UI Integration

Mobile Integration

Chatbot Integration

Für Integration der Dinge

Ding zu Analytics

Ding zu Prozess

Ding zu Data Lake

Ding zu Ding

Für die stilübergreifende Integration

API-Managed Integration

Event-Based Integration

Stream Analytics

Workflow Management

Robot Process Automation

Integration Technologie Mapping

Im dritten Schritt der Methodik können Integrationsstile und Anwendungsfallmuster (alle technologieunabhängig) auf Integrationstechnologien oder -services abgebildet werden, die in Ihrem Kundenkontext verwendet werden sollten. Dieses Mapping hängt stark von Ihrem spezifischen Kundenkontext ab.

Bei der Zuordung von Technologien zu Use Cases sind Empfehlungsgrade sinnvoll.

Empfehlungsgrad 

allgemeine Empfehlung (General Recommendation)

Beschreibung:

Die allgemeine Empfehlung sollten Sie für die Technologie wählen, die im Normalfall für einen bestimmten Use Case verwendet werden soll.

Beachten sie , dass mehrere Lösungen eine allgemeine Empfehlung für einen Use Case haben können.

Empfehlungsgrad:

 angemessene Alternative

(Reasonable Alternative)

Beschreibung:

Als angemessene Alternative sollten Sie Technologien empfehlen , die unter bestimmten voraussetzungen Ihre Empfehlung sind. Ein typisches Beispiel für den Use Case einer Integration von Anwendendungen wäre die direkte Integration zwischen zwei Systemen obwohl die allgemeine Empfehlung die Verwendung einer Middleware ist.

Empfehlungsgrad:

mögliche Ausnahme (possilbe Exception)

Beschreibung:

Eine mögliche Ausnahme sollten Sie für alle Technologien definieren , die Sie nicht mehr verwenden wollen, allerdings im Ausnahmefall noch zulassen. 

Empfehlungsgrad:

zu vermeiden

(To Be Avoided)

Beschreibung:

Technologien , die Sie nicht mehr verwenden wollen , sollten sie mit dem Empfehlungsgrad zu vermeiden klassifizieren. Dies können Produkte und Technologien sein die Sie in Ihrem Unternehmen langfristig ablösen wollen.

                                                          

Fazit:

In den vorangegangenen Abschnitten habe ich Ihnen versucht die Methode ISA-M vorzustellen.

Ich halte den Einsatz von Integrationsdomänen,-stilen und UseCases für sehr sinnvoll und hilfreich.

Insbesondere wenn Sie mit Ihren Mitarbeitenden, Fachbereichen oder Führungskräften diskutieren, hilft die strukturierte Vorgehensweise mit den drei genannten Einordnungskriterien. 

Ein weiterer Punkt sind für mich die Architektur-Blueprints die ich sehr sinnvoll erachte, und deswegen in einem weiteren Post genauer darauf zu sprechen komme.

Technologie Agnostische Gedanken zur Hybriden Integration Teil 2

 Reifegradmodell

Die Digitalisierung verlangt von den Unternehmen vor allem eines: Vernetzung.

 

Da sich API's , Microservices, Software as a Service (SaaS) und Serverless-Architekturen weiterentwickeln, wird der  Integration's Bedarf  nicht weniger werden.

Stattdessen beinhaltet fast jedes neue System über eine eplodierende Liste  von Endpunkten (Exploding Endpoint Problem).

 

Das Microservice Mantra von Smart Endpoint und Dumb Pipes geht auf ein tieferes Problem ein, Integration muss vom Code lernen, unveränderlicher werden, typsicher, testbar , kontinuierlich builden und deployen, damit sie robuster, belastbarer und vor allem agiler ist. 

Grundlagen zum Reifegradmodell

Ein Reifegrad beschreibt die Reife eines eines bestimmten themenkomplexes hinsichtlich einer bestimmten Methode oder eines Modells. Durch die Einstufung anhand definierter Anforderungen und Kriterien ergeben sich verschiedene Grade an Reife. Zur Erreichung eines bestimmten Reifegrades müssen die in der jeweiligen Stufe beschriebene Kriterien nachweislich erreicht sein. Die ursprüngliche Verwendung von Reifegradmodellen findet sich in der qualitativen Bewertung von Unternehmensprozessen. Die Qualität der Prozesse macht sichtbar, wie gut die Prozesse zu den Unternehmenszielen und -strategien beitragen. Ziel dabei war es, entlang eines systematischen Ansatzes die Prozessqualität im Unternehmen kontinuierlich zu messen und zu verbessern. Viele der heute bekannten Reifegradmodelle orientieren sich an diesem Grundgedanken.

 

Die Methodik erwartet nicht , dass eine Organisation von Grund auf neu beginnt , sondern zuerst eine Bewertung durchführt, um den aktuellen Zustand zu verstehen und einen Weg zu definieren , um zur nächsten gewünschten Ebene zu gelangen . 

Reifegradmodell im Kontext von Integration

 Der Gesamtansatz , von einer Stufe zur nächsten zu wechseln, ist iterativ, planen, implementieren, überprüfen, verbessern und zurück zum Plan.  

Beschreibung der Reifegradstufen

Level 0: Ad-hoc-Integration : 

Das Wissen zur Integration und den Werkzeugen ist nur bedingt vorhanden , was dazu führt , dass das Thema Integration zu Frustration bei den Mitarbeitenden führt und die Ressourcen schlichtweg überfordert sind.

Um den Reifegrad zu erhöhen , sollten Sie folgende Maßnahmen und Entscheidungen treffen:

1. Schaffen Sie Transparenz, und zeigen Sie den Stellwert der Integration im Unternehmen auf. Erkennen Sie den Bedarf , und machen Sie sich Ihre Integrationsstrategie bewusst.

2. Ermitteln Sie Ihre Integrationsanforderungen im Unternehmen. Basierend darauf sichten Sie die Werkzeuge und Integrationsplattformen auf dem Markt, um Ihre Anforderungen bestmöglich abbilden zu können.

3. Definieren Sie Rollen im Integrationsumfeld. Nutzen Sie dazu die Rollen aus ISA-M. Besetzen Sie die Rollen mit entsprechenden IT-Ressourcen.

4. Setzen Sie ISA-M ein , um effizienter und strukturierter Ihre Anforderungen an die Integration einstufen zu können.

Level 1: Einheitliche Terminologie (Common Terminology)

Die Einstufung von Reifegrad-Level 1 ist Grundlage von ISA-M. Unternehmen haben die Notwendigkeit der Integration erkannt und ihre Integrationsfähigkeiten entsprechend nach ISA-M in Domänen, Stilen und Anwendungesfälle strukturiert und klassifiziert. Die Kommunikation zwischen Unternehmensarchitekt*innen, Projektteams, Fachbereichen sowie Systemverantwortlichen ist optimiert, aber noch nicht vollständig etabliert. Die Verantwortlichkeiten sind häufig noch nicht geklärt, was die Umsetzung einer zentralen Governance für die Integration erschwert.

Um den Reifegrad zu erhöhen , sollten Sie folgende Maßnahmen und Entscheidungen treffen:

1. Etablierung eines Integration Competency Centers . 

2. Formulieren Sie eine Reihe von Integrationsregeln, Mustern und Standards für die Integration im Unternehmen.

3. Definieren Sie einen Prozess, um Projektanfragen an die Integration zentral aufnehmen zu können. Ziel ist es , Anfragen zu zentralisieren und zu standardisieren.

Level 2: Integrationsstrategie (Integration Strategy)

Unternehmens- und Integrationsarchitekt*innen sind in der Lage , die Integrationsfähigkeiten anhand der ISA-M Klassifizierung zu bewerten und zu optimieren. Anhand der ISA-M-Methodik wurden Referzarchitekturen und Integrationsmuster für Lösungen entwickelt. Das Unternehmen ist auf dem Weg, sich sowohl horizontal als auch vertikal vollständig zu vernetzen. Sie schaffen mit der Integrationsstrategie die Grundlage zur Digitalisierung. Des Weiteren gibt es ein Integration Competency Center, das sich um die Integration im Unternehmen als Ganzes kümmert.

Um den Reifegrad zu erhöhen, sollten Sie folgende Maßnahmen und Entscheidungen treffen:

1. Schaffen Sie eine Unternehmenskultur, in der Integration der Mittelpunkt für die Weiterentwicklung und Transformation des Unternehmens ist.

2. Optimieren Sie Ihre Sourcing-Strategie, und schaffen Sie eine differenzierte Sourcing-Richtlinie.

3. Etablieren Sie eine kontinuierliche Abstimmung zwischen dem Integrationsteam und den Unternehmensarchitekt*innen. Gründen Sie ein Integrations-Board, das regelmäßig Best Practices überprüft , neue Anforderungen aufgedeckt und die Integration als Managementdisziplin weiterentwickelt.

Level 3: Integrationssteurung (Integration Governance)

Richtlinien und Standards zur Integration werden durch die Unternehmens- und Integrationsarchitekt*innen entwickelt. Projektteams sind in der Lage , anhand dieser Richtlinien und 'Standards eigenständig die Integrationslösungen und - technologien auszuwählen. Die Nutzung von Richtlinien und Standards ermöglicht es nun, neue Schnittstellenanforderungen strukturiert zu bewerten und anhand der Referenzarchitekturen bestmöglich umzusetzen. Ein Expertenteam überwacht kontinuierlich neue Integrationsanforderungen und Trends und entwickelt die Fähigkeit im Unternehmen zu Integration entsprechend weiter.

Um den Reifegrad zu erhöhen , sollten Sie folgende Maßnahmen und Entscheidungen treffen:

1. Versuchen Sie, die Integration als festen Bestandteil in die Digitalisierungsstrategie einzubinden. Integration sollte in der digitalen Kultur Ihres Unternehmens fest verankert sein.

2. Entwickeln Sie neue Ansätze hinsichtlich der "Do-it-Yourself"-Integration. Schaffen Sie Grundlagen im Unternehmen, um diese Ansätze zu ermöglichen.

3. Ermutigen Sie einzelne Anwender*innen dazu, die Integration selbst einzurichten. Ziel dabei ist es, die internen Kernressourcen zu stärken und das Wissen zur Integration stärker zu dezentralisieren.

4. Definieren Sie Ihre Hybrid Integration Platform.

Level 4: Etablierte Integrationsorganisation ( Practice of Empowerment)

Unternehmen in diesem Reifegrad ermöglichen es den Endbenutzer*innen sowie Endanwender*innen, durch moderne Integrationswerkzeuge ihre Schnittstellen selbständig für bestimmte Integrationsdomänen auf der Hybrid Integration Platform zu konfigurieren. Das Integrationsteam kann nun besser skalieren und sich auf die Modernisierung der Integrationslandschaft konzentrieren. Des Weiteren ist die Integration fester Bestandteil in der digitalern Kultur des Unternehmens und ist in alle Prozesse eingebunden. SelfService -Fähigkeiten zur Integration sind etabliert.

Vorgehensweise und praktische Nutzung

Meine Empfehlung für die praktische Anwendung ist es, ein Reifegradmodell lediglich als Orientierung und für eine Analyse der Ist-Situation bzw. Einschätzung der heutigen Integrationsfähigkeiten zu nutzen. Darauf basierend , lassen sich dann Handlungsfelder und Maßnahmen ableiten, um den nächsten Reifegrad ihrer Integrationsfähigkeiten zu erreichen.

Leitfaden für Reifegradmodelle

Im Folgenden geben wir Ihnen einen Leitfaden zur Nutzung der Reifegradmethode , basierend auf den beiden vorgestellten Modellen  "Reifegradmodell für die Integration " . Zur Bewertung der Ist-Situation und Ableitung von Maßnahmen sind im Wesentlichen vier Schritte erforderlich:

1. Schätzen Sie den Reifegrad Ihrer IT in der Integrationsfähigkeit ein.

Bestimmen Sie Ihre Ausgangslage in Bezug auf die Integration. Nutzen Sie dazu die Ebenen aus ISA-M, und adaptieren Sie die Ebenendefinitionen inklusive Kriterien gemäß Gartner.

2. Legen Sie Ihre Zielsetzung anhand der Ebenen im Reifegradmodell fest.

Definieren Sie ihre gewünschten Ziele für  die Integration, und ordnen Sie diese der entsprechenden Ebene im Reifegradmodell zu. 

3. Definieren Sie Maßnahmen zur Erreichung der Ziele anhand der Kriterien des Reifegradmodells.

Beschreiben Sie zunächst anhand der Ausgangssituation Ihre definierten Ziele und Handlungsfelder . Bestimmen Sie anhand der Handlungsfelder die zur Umsetzung benötigten Maßnahmen.

4. Setzen Sie die Maßnahmen sukzessive um.

Planen Sie die Maßnahmen im Sinne einer Roadmap. Auf dieser Basis können Entscheidungen hinsichtlich Ressourcen, Investitionen usw. getroffen werden. Überwachen Sie die Umsetzung, und reflektieren Sie die Ergebnisse, z.B. nach einem Jahr erneut anhand des Reifegradmodells.

Technologie Agnostische Gedanken zur Hybriden Integration Teil 1

 In diesen Überlegungen geht es mir darum aufzuzeigen was ich als wichtig erachte um Integration möglich zu machen. Ich werde Versuchen die verschiedenen Komponenten aufzuzeigen und dabei aber immer Technologie Agnostisch zu bleiben. Die Erfahrungen die ich hier zurückgreife kommen aus meiner Funktion im Bereich SAP-Schnittstellen und der Integration dieser mit nicht SAP-Anwendungen.

Was bedeutet Integration?

In der Wirtschaftsinformatik beschreibt Integration die Verknüpfung von Menschen , Aufgaben und Technik zu einem einheitlichen Ganzen. Die wesentliche Aufgabe der Integration  die Automatisierung von Datenflüssen zwischen verschiedenen Informationssystemen. Dabei ist der Stellenwert der Integration über die Jahre deutlich gewachsen, da die Anforderungen und die Vielzahl der eingesetzten Informationssysteme immer komplexer wurden.

Nach Peter Mertens ("Integrierte Informationsverarbeitung" ) wird Integration in fünf Dimensionen unterteilt.

Integrationsgegenstand

Integrationsgegenstände können Daten, Programme, Funktionen Prozesse, aber auch Dienste sein.

Integrationsrichtung

Die Integrationsrichtung wird in die horizontale und vertikale Integration unterteilt. Bei der horizontalen Integration geht es um die Verkettung zwischen den Unternehmensprozessen.

Die vertikale Integration beschreibt wiederum die Integration von der ausführenden Ebene hin zur strategischen Planungsebene im Unternehmen.

Integrationsreichweite

Die Integrationsreichweite unterteilt sich typischerweise in die innerbetriebliche und die überbetriebliche Integration. Ein Beispiel dafürn ist die Integration zu externen Dienstleistern oder Plattformen (Unternehmen-zu-Unternehmen, B2B und Unternehmen-zu-Endkunden,B2C).

Automatisierungsgrad

Je nach Integrationszenario wird zwischen voll - oder teilautomatisiert unterschieden. 

Integrationszeitpunkt

Der Integrationszeitpunkt beschreibt die Art der Verarbeitung. Die bekanntesten Szenarien für den Integrationszeitpunkt sind das Echtzeit-oder Batch-Verfahren .

Wandel der Anforderungen

Durch die steigende Komplexität der Unternehmensarchitekturen haben sich auch die Anforderungen gewandelt. Die zunehmend vertikale und horizontale Vernetzung , die Digitalisierung der Unternehmensprozesse und die schrittweise verlagerung von Unternehmensanwendungen in Richtung Cloud führen zu einer hohen Komplexität der Unternehmensarchitektur und zu einem hohen Bedarf an Integration. Neue Trends wie Industrie 4.0 , Internet of Things(IoT) oder digitale und vernetzte Zwillinge führen weiter zu einem steigenden Integrationsbedarf führen.

Integration Solution Advisory Methodology (ISA-M)

Obwohl ISA-M von SAP entwickelt und gewartet wird, ist diese Methode durchaus offen für Nich-SAP-Integrationslösungen. Deswegen ist ein Anwendung der Methodik auch für andere Produkte möglich.

Ich beschreibe hier die vier vorgesehen Phasen des ISA-M Kreislaufs.

. Asses your Integration Strategy

Die Phase Asses your Integration Strategy hat zum Ziel, die Integrationsarchitektur zu dokumentieren und zu begutachten. Mithilfe von Integrationsdomänen und Integrationstilen können sowohl die aktuelle Integrationslandschaft als auch die zukünftige Integrationslandschaft beschrieben werden.

Design your Hybrid Integration Platform

Im Rahmen der zweiten Phase findet die Gestaltung der hybriden Integrationsplattform statt. Nach ISA-M sind die wichtigsten Aufgaben bei der Gestaltung einer hybriden Integrationsplattform die Zuordnung von Technologien und die Bewertung von Schnittstellen.

Define Integration Best Practices

Ziel dieser Phase ist es, mithilfe von beschriebenen Best Practices  die Implementierung von neuen Integrationsanforderungen zu überwachen und Transparenz zum Schnittstellendesign zu erzeugen. Hier können sogenannte Architektur-Blueprints ein gutes Mittel sein.

Enable a Practice of Empowerment

In dieser Phase geht es um die Verbreitung des Integrationswissen innerhalb der Organisation. Ziel dieser Phase ist es, die Integration als anerkannte Disziplin und strategische Funktion innerhalb der Organisation zu etablieren.. In weiteren Post's werde ich noch auf das Integration Competency Center of Excellence zu sprechen kommen.

Fazit: 

Integration wird sehr schnell sehr unübersichtlich und komplex , wir müssen uns in der Zukunft darauf einstellen das System's of System's immer mehr mehr wird und daher die Anforderung auf die Integration steigen wird.

Das bedeutet wir brauchen Vorgehensweisen die eine dokumentierte Methodik haben , um sie Nachvollziehbar zu machen , damit in Projekte besser über die jeweiligen Ansätze diskutiert werden kann und durch sog. Architektur - Blueprints  sich auf vorgehensweisen fokussieren kann , das wird das Verständnis erheblich verbessern.

Reifegradmodelle, Methodiken wie ISA-M die sich auch weiterentwickeln, werden die Organisation voranbringen. 

Unabhängig von Protokollen und Technischen Plattformen müssen diese Aufgaben erledigt sein um einen Wildwuchs von Technologien und unterschiedlichen Ansätzen zu verhindern.

Weitere Post's zu dem Thema werden sein:

Reifegradmodell

Methodik von ISA-M

Integration Center of Excellence

Hybrid Integration Platform

API - Ein paar Gedanken dazu

 Eine Programmierschnittstelle (auch Anwendungsschnittstelle, genauer Schnittstelle zur Programmierung von Anwendungen), häufig nur kurz API genannt (von englisch application programming interface, wörtlich, Anwendungsprogrammierschnittstelle), ist ein Programmteil, der von einem Softwaresystem anderen Programmen zur Anbindung an das System zur Verfügung gestellt wird. Im Gegensatz zu einer Binärschnittstelle (ABI) definiert eine Programmierschnittstelle zur die Programmanbindung auf Quelltext-Ebene. Zur Bereitstellung solch einer Schnittstelle gehört meist die detaillierte Dokumentation der Schnittstellen-Funktionen mit ihren Parametern auf Papier oder als elektronisches Dokument.

Wikipedia  (Programmierschnittstelle – Wikipedia)

So , also wir sehen API gibt es schon sehr lange , aber warum sind sie in den letzten Jahren noch sehr viel mehr ein Thema geworden?

Nun , das hat natürlich etwas mit Vernetzung von unterschiedlichen Systemen zu tun , das ist uns natürlich klar , und um hier Probleme zu vermeiden muss eine Entkopplung passieren. Das hat auch mit dem  Siegeszug des Internet zu tun.

Das hat auch dazu geführt das Unternehmen auch viel vernetzter agieren, innerhalb und auch zwischen zwei Unternehmen, hier kann ich nur das Buch Connected Company empfehlen. 

 Wo ich das große Missverständnis sehe, ist das heute in vielen Besprechungen wenn von API's gesprochen wird nur von einer , maximal zwei Technologien gesprochen wird. Und hier geht es nicht nur um Technologien sondern auch von Paradigmen. Ich sehe das z.B. REST als API Technologien als der heilige Gral angesehen wird, und alles andere oft nicht mehr gesehen wird. Und bitte mich nicht falsch verstehen, natürlich ist REST ein gutes Paradigma und in vielen Anforderungen sinnvoll aber nicht in allen. Ich möchte das jetzt ein wenig Spezifizieren, bei Anforderungen wo zwei Applikationen sehe ich jetzt nicht das eine REST API das Tool das Wahl ist , wenn es darum geht das eine Microservice Architektur aufzubauen sehe ich auch nicht unbedingt das REST die Technologie der Wahl ist , hier geht es nicht darum eine API zur Verfügung zu stellen die für den Konsum von verschiedenen geeignet sind, wo ich als Anbieter die Funktionalität verschiedenen Institutionen zur Verfügung zu stellen in einem genormten Format.

Ich plädiere dafür die verschiedenen Technologien wie Werkzeuge in einem Werkzeugkoffer zu sehen. Indem ich dementsprechend entscheide welches Werkzeug oder Werkzeuge ich benutze um meine Lösung bestmöglich aufbaue. 

Es wird in der Zukunft Blueprint's innerhalb eines Unternehmens erfordern, die Kollegen Informationen an der Hand gibt wie das Unternehmen Integration von Systemen sieht , die laufend Review's unterzogen wird um hier auch immer  gewährleistet das diese Blueprint's an den neuen Technologien dranbleiben.

Fazit:

Integration wird weiterhin ein Thema bleiben, ich sehe es nicht das diese Entscheidungsprozesse  durch Software-Agenten abgenommen werden können , da sind die Variationen zu groß, und hier liegt die stärke des erfahrenen Mitarbeiter im Unternehmen  der auch die Domaine des Unternehmens versteht und auch die Kultur kennt. 

Das ist Teamarbeit, das Thema ist zu vielfältig das einer dieses Thema , vollständig erfassen kann.