Interview mit Dr. Heinrich Krause

Integration führt zu Koexistenz

Mirko Schrempp

Dr. Heinrich Krause ist unabhängiger Berater für IT- und Enterprise-Architektur. Er ist Betriebswirtschaftler und verfügt über eine langjährige Erfahrung in der Applikationsentwicklung in verschiedenen Branchen. Bei einer Schweizer Großbank hat er als Leiter der Applikationsarchitektur die IT-Architektur und die Einführung der SOA maßgebend geprägt. Mirko Schrempp hat sich mit ihm über die praktischen Herausforderungen von Integrationen im Spannungsfeld zwischen Business und Technologie unterhalten und dabei einen Bogen von der kleinen Applikationsintegration zum großen Merger gespannt.

Wenn man von den vielen möglichen Szenarien absieht – geht es dann bei Integration im Wesentlichen nur um das „Irgendwie-unter-einen-Hut-bringen“ oder soll Integration aus vielen einzelnen Teilen ein großes Ganzes machen?

Dr. Heinrich Krause: Ganz sicher geht es nicht darum, etwas „irgendwie unter einen Hut“ zu bringen. Die Integration sollte eine Koexistenz zum Ergebnis haben, ohne dass die Eigenheiten der einzelnen, integrierten Teile verloren gehen. Ein einfaches Beispiel könnte sein, dass zwei verschiedene Pakete mit Kunden-informationen existieren – das eine Paket aus der Debitoren-Buchhaltung und das andere aus dem Bestellsys-tem. Diese beiden Pakete haben unterschiedliche Kundeninformationen in den Paketen gespeichert. Trotzdem möchte ich jeden Kunden nur einmal im Gesamtsystem haben. In der Debitoren-Buchhaltung ist z. B. die Lie-feraderesse, wo also die Ware physisch hingeht, nicht von großer Bedeutung, aber für die Bestellbuchhaltung ist diese Information wesentlich. Die Fakturierungs¬adresse ist wiederum nur für die Debitoren-Buchhaltung von Bedeutung. Das zwingt mich, für eine Koexistenz dieser beiden Pakete zu sorgen, bei der ihre Eigenheiten nicht verloren gehen dürfen, die aber trotzdem gegenseitig Daten austauschen müssen. Das ist die eigentliche Integra-tionsaufgabe, ich muss festlegen, welchen Überbau ich drüber setze, um die beiden Pakete in eine Koexistenz zu bringen.

Dieses Beispiel veranschaulicht auch eine grundlegende Problematik, wo die Ansichten zwischen Business und IT oft sehr weit auseinander liegen. Am Ausgangspunkt steht meist die folgende oder eine ähnliche Situati-on: Man findet auf dem Markt zwei Pakete, eben eine Debitoren-Buchhaltung und ein Bestellwesen. Beide Pa-kete weisen die erforderliche Funktionalität auf und sind einzeln einsatzbereit. Für die IT beginnt jetzt die Ar-beit, für das Business ist nicht unmittelbar einsichtig, warum jetzt noch viel Aufwand für die Einbindung ge-trieben werden muss.

Debitoren- und die Bestellbuchhaltung sind beide fachliche Aspekte, die auch von der Fachabteilung betreut werden. Aber die Zusammenführung ist eine Aufgabe, die von der Technik gelöst werden soll. Was muss die Technik tun?

Krause: Ich sehe ein Problem darin, wenn man zu sehr darauf abzielt, dass die Technik alles lösen kann. Man darf nicht zu sehr abstrahieren, denn es gibt Nebenbedingungen, die eingehalten werden müs-sen, und zwar von beiden Seiten. Ohne Zweifel ist der Primat der Anforderung beim Business, aber die Tech-nik, respektive die Applikation und deren Prozesse geben gewisse Nebenbedingungen vor, die eingehalten wer-den müssen und ohne die es nicht geht. Das können ein vorgeschriebenes Vier-Augen-Prinzip sein, das berück-sichtigt werden muss, aber auch technische Begrenzungen. Wenn z. B. früher, als die Daten noch in Lochkarten mit maximal 80 Stellen pro Karte gestanzt wurden, einer kam und sagte, er brauche noch zwei Stellen mehr auf der Lochkarte, d. h. zwei mehr als zur Verfügung standen, dann ging das eben nicht. In diesem Fall musste man herausfinden, was er eigentlich mit diesen zwei Stellen machen wollte und wie man das auf andere Weise reali-sieren konnte. Auch heute gibt es noch immer technische Nebenbedingungen, die bestimmte Einschränkungen darstellen. Denken Sie an die Y2K-Problematik. Ohne das zu berücksichtigen, wird man (nicht nur) mit der Integration nicht glücklich.

Wie wirkt sich die Berücksichtigung dieser beiden Seiten im Projekt aus? Das hat doch auch Folgen für die Kommunikation zwischen den Abteilungen. Wenn die eine Partei die Vorstellung hat, das alles so oder so umgesetzt werden kann, und die andere sagt, „Nein, so geht das aber nicht“. Ist nicht die Kommunikation zwi-schen den Abteilungen für sich schon eine Integrationsherausforderung?

Krause: Aber sicher, die erste Herausforderung ist oft, die richtige Mittel-Zweck-Hierarchie zu erkennen. Also das Verhältnis vom „Was“, das vom Business vorgegeben wird, und dem „Wie“, das durch die IT gelöst werden soll. Dann geht es darum, beim „Was“ die Bedürfnisse zu erkennen und nicht eine vorge-fertigte Lösung anzubieten. Bei sämtlichen Analyseverfahren wird immer Wert darauf gelegt, zuerst die fachli-chen Anforderungen umfassend aufzunehmen. Danach ist es die Kunst des Architekten oder des IT-Verantwortlichen, diese fachlichen Anforderungen so zu präzisieren, dass nur das „Was“ und nicht schon ein Teil vom „Wie“ in den Anforderungen aufgeführt ist.

Wenn mir einer sagt, „Ich muss von Frankfurt nach Basel“, dann frage ich, „Warum müssen Sie nach Basel“ und er antwortet, weil dort eine Veranstaltung stattfindet, die er besuchen möchte. Dann ist das Bedürfnis, also das „Was“, die Veranstaltung zu besuchen und nicht nach Basel zu fahren. Denn wenn eine parallele Veranstal-tung in München oder Karlsruhe stattfindet, wäre es unter Umständen einfacher und billiger, dorthin zu fahren. Diese Trennung vom „Was“ der Anforderung und dem „Wie“ der Umsetzung ist wichtig und muss klar aufge-zeigt werden.

Die Herausforderung für den Architekten ist es, die richtigen Fragen zu stellen, um herauszufinden, was der Auftraggeber wirklich will. Sagt er, „Ich muss meinen Kunden kennen“, dann muss ich wissen, was er vom Kunden kennen muss, z. B. wo sitzt der Kunde, was betreibt er für ein Geschäft usw. Was er im Normalfall nicht wissen muss, ist die Augenfarbe des Kunden – es sei denn, er ist Verkäufer von Glasaugen, dann ist das auch eine wichtige Information. Auch solche Besonderheiten sprechen gegen vorgefertigte Lösungen.

Geschrieben von
Mirko Schrempp
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.