“Das ist historisch so gewachsen…” – mit diesem Satz werden gern Unzulänglichkeiten in der IT-Systemlandschaft entschuldigt. Einer chaotische, schlecht wartbare und ineffiziente Systemlandschaft entsteht meist unter folgenden Rahmenbedingungen:
Egal wie Sie diese Situation bewältigen wollen – neben einer strukturierten Überarbeitung der Geschäftsprozesse sollten Sie Architekturprinzipen festlegen und nachhalten.
Hier ein Beispiel für Prinzipien und Regeln, die wir bei unseren Kunden einsetzen.
Mehrere miteinander konkurrierende Plattformen führen zu erheblichen Reibungsverlusten, die wir möglichst vermeiden wollen.
Festlegung auf ein integratives ERP als Technologie. Damit ist die Technologie gesetzt für ERP-Funktionalitäten, Stammdatensysteme und Schnittstelllen/Integration.
End-to-end Integrationsplattform für Lieferkettenvorgänge. Es wird eine End-to-End Integrationsplattform für Lieferkettenvorgänge aufgebaut, in der es möglich ist, alle operativen Vorgänge entlang aller Teil-Lieferketten eines Unternehmens zu sammeln und für übergreifende Optimierungs- und Steuerungszwecke zu nutzen. Alle Teilsysteme entlang der gesamten Lieferkette, von der Beschaffung über Lagerlogistik, Vertrieb bis zur Transportlogistik, sowie alle Teilplattformen der Bereiche werden mit dieser Integrations-Plattform über Schnittstellen verbunden.
Single Point of Truth in einem Data-Warehouse für analytische Daten. Analytische Daten, die mehrere Quellsysteme (Multi Source) und/oder mehrere Nutzungsfelder (Multi Use) haben, werden immer über ein Data-Warehouse für analytische Applikationen bereitgestellt, um einen Single Point of Truth zu gewährleisten. Anmerkung: die Daten aus den Kerngeschäftsprozessen Einkauf, Vertrieb und Logistik sind fast ohne Ausnahme Multi-Source/Multi-Use. Single-Source/Single-Use Daten findet man nur in peripheren Bereichen wie Personal oder evtl. Finanzen.
Modularisierung ist auch auf der Eben der gesamten IT-Systemlandschaft wichtig, weil sie hilft, Komplexität zu beherrschen.
Einhaltung der Zielarchitektur. Es werden zur Umsetzung von Geschäftsanforderungen in Projekten nur Applikationen/Systeme eingesetzt, die Bestandteil der definierten Zielarchitektur sind.
Funktionale Eindeutigkeit. Für einen zusammenhängenden Firmenverbund gibt es jeweils nur genau eine Applikation / ein System, das einen Teilprozess der Geschäftsprozesslandkarte bzw. dessen Schritte bearbeitet. Ein Teilprozess darf für einen zusammenhängenden Firmenverbund nicht einmal in System A und ein andermal in System B bearbeitet werden.
Eindeutige Datenpflege-Hoheit. Es gibt jeweils nur genau eine Applikation / ein System, das ein Geschäftsobjekt bzw. eine Sicht darauf in einem Zustand seines Lebenszyklus pflegt bzw. verändert. Es darf nicht zwei pflegende Systeme geben, die bidirektional synchronisiert werden müssen.
Vorwärtsbearbeitung, keine Zirkulärprozesse. Eine Applikation / ein System bearbeitet einen Teilprozess hoheitlich vollständig und eigenständig und übergibt dann die Hoheit an Folgeapplikationen für den nächsten Teilprozess. Es darf nicht vorkommen, dass zwei Applikationen in einem Teilprozess die Verarbeitung iterativ hin- und herschieben, um das Ergebnis zu erreichen.
Konsequente Trennung von Handels- und Logistiksystemwelten. Die Systemlandschaften für die Prozesse von Handelsunternehmen (Vertrieb, Einkauf, etc.) sowie einer mandantenfähigen Logistik werden so konzipiert, dass sie jeweils vollkommen eigenständig funktionsfähig sind. Die Systemwelten sind über Schnittstellen verbunden, haben jedoch keine gemeinsam genutzten Komponenten.
Trennung von Applikationen und Middleware. Middleware-Systeme, die zur Integration zwischen Systemen verwendet werden, dürfen keine Datenhoheit über Geschäftsobjekte haben und originäre Geschäftsobjekte nicht persistent speichern. Lediglich Caching-Mechanismen sind in Middleware-Systemen als Datenhaltung erlaubt. Fachliche Funktionalitäten dürfen nicht in Middleware-Systemen umgesetzt werden, sondern sind in den fachlichen Applikationen zu realisieren.
Entflechtung von Data Marts / BI-Anwendungen. Data Marts / BI-Anwendungen werden jeweils direkt aus einm Data-Warehouse mit Daten beliefert. Ein Data Mart dient nicht als Datenquelle für einen anderen Data Mart.
Wie Ihre Systeme zusammenarbeiten ist entscheidend für den Gesamtnutzen der IT-Landschaft. Es lohnt sich also, die Integrationsmechanismen zu vereinheitlichen.
Dreifache Integrierbarkeit der Applikationen/Systeme. Jede Applikation / System muss auf drei Arten mit anderen Systemen integrierbar sein:
Integrierbarkeit von Applikationen in SSO/IDM Infrastruktur. Alle Applikationen / Systeme müssen in unternehmnesweite Identity Management (IDM) und Single Sign On (SSO) Infrastruktur integrierbar sein.
Trennung von operativen und analytischen Systemen. Operative und analytische Prozesse/Funktionen werden auf sauber getrennten Systemen abgewickelt, die jeweils über eigene Datenhaltung und Verarbeitung verfügen. Benötigt eine Benutzerrolle beide Arten von Funktionen, so werden diese über Workplace-Systemkomponenten integriert.
E-Commerce Integration Services. Die Kommunikation der Backend Systeme/Applikationen mit Systemen/Applikationen im Bereich E-Commerce, Front-End z.B. Außendienst-Software erfolgt nur über eine gemeinsame Integration Services Plattform.
Alles, was ein System selbstverständlich erfüllen muss.
Grundsätzliche Performance-Machbarkeit. Alle Applikationen / Systeme müssen in der Lage sein, das Mengengerüst (Datenvolumen, Vorgänge) des jeweils relevanten Projekt-Scopes mit nachvollziehbar definierten Sicherheitsreserven zu bewältigen.
Compliancefähige Buchhaltung. Alle buchhalterischen Prozesse und Funktionen sind so realisierbar, dass sie durch Prüfer zertifiziert werden können.
Wenn Sie grundsätzliche Architekturprinzipien anwenden und diese auch nachhalten und weiterentwickeln, schaffen Sie die Basis für einen vereinfachten und schnelleren Software-Lieferprozess. Senden Sie uns gerne Ihren Ansatz zu Architektur-Prinzipien, denn auch wir lernen unbedingt noch dazu!
Christoph Lefkes