Untersuchung der Auswirkungen des strategischen IT-Business-Alignment auf die Gestaltung der IT-Architektur

Das Thema IT-Business-Alignment zählt seit Jahren zu den Top-Aufgabenstellungen für die Verantwortlichen auf IT- und Fachbereichseite. Die Frage, die sich dabei stellt: In wie weit wirkt sich die Zusammenarbeit und die strategische Abstimmung der Unternehmensbereiche auf die konkrete Architektur der IT-Landschaft aus? Mit den Daten aus einer Befragung von Deutschlands größten Dienstleistungsunternehmen wird gezeigt, welche Gestaltungsmerkmale der IT-Architektur sich mit hohen Alignment beeinflussen und verbessern lassen. Darüber hinaus wird gezeigt, wie der Stand einer service-orientierten Architektur (SOA) in diesen Unternehmen ist und welche Standards sie davon bereits einsetzen.

Autorentext

Alexander Kaden, B.Sc., wurde 1987 in Marktredwitz geboren. Sein Studium der Wirtschaftinformatik an der Otto-Friedrich-Universität Bamberg schloss er im Jahre 2011 erfolgreich ab. Im Laufe des Studiums entwickelte sich sein Interesse für Softwareentwicklung und dem Wertbeitrag der IT für Unternehmen. Der Autor sammelte neben dem Studium auch praktische Erfahrungen in einem kleinen IT-Systemhaus, das sich u.a. mit Lösungen zur Unterstützung und Beschleunigung von Geschäftsprozessen beschäftigte. Nach Abschluss des Studiums begann der Autor als Entwicklungskoordinator für ein Produktinformationssystem bei einem mittelständischen Unternehmen zu arbeiten.

Klappentext

Das Thema IT-Business-Alignment zählt seit Jahren zu den Top-Aufgabenstellungen für die Verantwortlichen auf IT- und Fachbereichseite. Die Frage, die sich dabei stellt: In wie weit wirkt sich die Zusammenarbeit und die strategische Abstimmung der Unternehmensbereiche auf die konkrete Architektur der IT-Landschaft aus? Mit den Daten aus einer Befragung von Deutschlands größten Dienstleistungsunternehmen wird gezeigt, welche Gestaltungsmerkmale der IT-Architektur sich mit hohen Alignment beeinflussen und verbessern lassen. Darüber hinaus wird gezeigt, wie der Stand einer service-orientierten Architektur (SOA) in diesen Unternehmen ist und welche Standards sie davon bereits einsetzen.

Leseprobe
Textprobe:
Kapitel 2.1.3.1, Standards und ihre Entwicklung:
Der Standard Extensible Markup Language (XML) von 1998 hat seine Wurzeln in der Standard Generalized Markup Language (SGML) aus dem Jahr 1986. Auszeichnungssprachen wie XML und SGML dienen zur Anreicherung von reinen Textdokumenten um benötigte Strukturen und Semantik. Die benötigten Auszeichner werden auch Tags genannt. Somit lassen sich zum Beispiel mit XML-Dokumenten Daten automatisiert maschinell einlesen, wobei der Inhalt der Datei dennoch für den menschlichen Benutzer lesbar bleibt. XML-Dokumente sollen dem Standard nach zunächst einmal wohlgeformt sein, das heißt unter anderem, dass es ausschließlich ein Wurzelelement gibt und jeder Tag auch wieder geschlossen wird. Zudem ist es für den Datenaustausch von Vorteil, wenn mittels eines XML-Schemas, zusätzlich zur Wohlgeformtheit, auch ein explizites Format definiert werden kann. Standardgemäß gilt ein XML-Dokument als gültig, wenn es wohlgeformt ist und das im Schema beschriebene Format einhält. Der XML-Standard bildet die Grundlage für alle der folgenden für SOA relevanten Standards.
Aus dem Versuch, nicht nur den Datenaustausch, sondern auch RPC s in einem verteilten System auf der Basis von XML zu standardisieren, entstand 1999 der Standard Simple Object Access Protocol (SOAP). Aufgrund der Tatsache, dass der Standard sich nicht sehr simple gestaltete, wurde die Langform im Laufe der Zeit verworfen und durch das Akronym ersetzt. Ziel des Standards ist eine einheitliche Form für die Nachrichten, die innerhalb von verteilten Systemen verschickt werden. Demnach soll durch den standardisierten Aufbau aus Header und Body die Verarbeitung optimiert werden, da hierbei lediglich der Header ausgelesen werden muss, um an die Metainformationen für Ziel der Nachricht oder zur Weiterverarbeitung zu gelangen. Der eigentliche Nachrichteninhalt, der Body, braucht daher beim Transport nicht ausgelesen werden und kann verschlüsselt übermittelt werden. Dies dient letztendlich auch der Systemsicherheit.
Der Standard Web Service Description Language (WSDL) folgte dann kurz darauf im Jahr 2000 und dient dazu, wie der Name schon sagt, Web Service einheitlich zu beschreiben, um unter anderem eine automatisierte Verarbeitung zu ermöglichen. WSDL baut wie SOAP auf dem XML-Standard auf, was bedeutet, dass ein WSDL-Dokument in XML geschrieben ist. Eine weitere Absicht bei der Entwicklung des Standards ist neben der einheitlichen Beschreibung, wie der Service zu nutzen ist, auch die Beschreibung, wo genau sich der Service befindet und angesprochen werden kann.
Mit dem Ziel eine unabhängige Plattform zu schaffen, auf der Web Services beschrieben und über das Internet gesucht und gefunden werden können, wurde im Jahr 2000 der Standard Universal Description, Discovery and Integration (UDDI) eingeführt. Dabei bildet UDDI einen einheitlichen Verzeichnisdienst oder Servicebroker , in dem Provider ihre Web Service Beschreibungen ablegen können. Diese Beschreibungen werden in WSDL verfasst und bei Bedarf an den suchenden Nutzer übermittelt. Die Kommunikation mit dem Verzeichnis erfolgt dabei über SOAP-Nachrichten. Dieser Standard erleichtert potentiellen Servicekonsumenten die Suche und ggf. Nutzung des passenden Providers. Jedoch kündigten Ende 2005 die größten Unterstützer von UDDI, darunter IBM und Microsoft, an, die UDDI Business Registry nach nur fünf Jahren abzuschalten. Und von da an wurde dieser Standard nicht mehr weiter verfolgt und weiterentwickelt.
Die Webservice Business Process Execution Language (WS-BPEL) ist ebenfalls eine XML-basierte Sprache zur Abbildung von Geschäftsprozessen, deren einzelne Aktivitäten unter anderem durch Webservices implementiert sind. Der im Jahr 2002 von IBM, BEA Systems und Microsoft eingeführte Standard wird dabei zu so genannten Orchestrierungen von Webservices verwendet. Diese Beschreibung selbst wird ebenfalls in Form eines Webservice bereitgestellt und kann als