IBM Presseinformation
ARBURG optimiert seine IT-Umgebung durch
neue IBM zEnterprise Server und DS8800-Speichersysteme
Mainframe-Infrastruktur sorgt für hohe
Sicherheit, Verfügbarkeit und Skalierbarkeit
Loßburg/Ehningen, 18.12.2012 – Der Spritzgießmaschinenhersteller
ARBURG GmbH + Co KG setzt im Rahmen der Erneuerung seiner IT-Infrastruktur
wiederholt auf die Mainframe-Plattform und nutzt IBM zEnterprise Großrechner-Technologie
und IBM DB2, um eine umfassende SAP Infrastruktur zu betreiben. Für seine
Datenbank-Anforderungen und eine bessere Performance hat ARBURG zwei IBM
zEnterprise 114 Server und ein IBM System DS8800 Speichersystem im Einsatz.
Optimierung der IT-Umgebung
Um die SAP Lösungen und weitere IT-Systeme
zu betreiben, vertraut ARBURG seit mehr als 40 Jahren auf IBM Technologien.
Die Kernaufgabe des SAP ERP Systems ist die effiziente Datenverwaltung
sowie die rechtzeitige Bereitstellung von Management- und operationalen
Daten an die Entscheidungsträger. In Zusammenarbeit mit IBM startete ARBURG
eine Initiative, um die bestehenden ERP Systeme zu aktualisieren und eine
neue Generation von IBM zEnterprise-Servern einzusetzen. Die existierenden
Lösungen basierten weitgehend auf historisch gewachsenen Anwendungen, die
durch Schnittstellen verbunden wurden und nur mit hohem Aufwand zu pflegen
waren.
Marktführerschaft dauerhaft sichern
Die Kombination aus „IBM DB2 for z/OS“
basierenden Datenbanken und den beiden zEnterprise 114 Servern verbessert
die Skalierbarkeit und Effizienz der IT-Systeme. Als weitere Elemente der
SAP Hardware Infrastruktur werden IBM System x-Server als Anwendungsserver
und für den Speicherbereich der IBM System Storage SAN Volume Controller
sowie IBM Storwize V7000-Systeme eingesetzt. Bestehende Anwendungen wurden
in die SAP Lösung integriert und der IT-Betrieb durch zusätzliche Automatisierung
noch produktiver gestaltet. Die implementierte Lösung entspricht den Anforderungen
von ARBURG und zeichnet sich im Vergleich zur vorherigen Infrastruktur
durch höhere Effizienz, Flexibilitätt und Zuverlässigkeit aus. Durch die
Vereinheitlichung der Geschäftsprozesse und der IT-Plattform konnten die
Gesamtkosten für den IT-Betrieb reduziert werden.
Effizienz und Kostenreduzierung durch
IBM Lösung
„Durch die Migration auf die neuesten
IBM zEnterprise 114 Server ist es uns gelungen, den Energieverbrauch um
80 Prozent zu senken. Dank der Implementierung einer IBM System Storage
DS8800 Speicherlösung konnten wir außerdem den Stromverbrauch der Festplattenspeicher
für die IBM zEnterprise Server um 25 Prozent reduzieren,“bemerkt der
ARBURG Bereichsleiter für Informationssysteme, Andreas Dümmler.
"IBM DB2 for z / OS ist unserer Meinung
nach die beste Datenbank-Lösung für unsere SAP-Systeme", sagt Stefan
Ridinger, DB / DC-Spezialist bei ARBURG. "Diese Lösung ist hoch skalierbar
und sehr zuverlässig und wir brauchen keine neuen Betriebs- oder Disaster
Recovery-Prozesse zu etablieren. Wir können einfach die vorhandenen Ansätze
und Workflows, die wir über viele Jahre entwickelt haben, mit IBM zEnterprise
verfeinern."
Über ARBURG
ARBURG GmbH + Co KG ist einer der weltweit
führenden Hersteller von Spritzgießmaschinen für die Kunststoffverarbeitung.
Im Einklang mit dem Gütezeichen "Made in ARBURG", produziert
das Unternehmen 60 Prozent aller Komponenten im eigenen Haus und alle seine
High-End-Spritzgießmaschinen für die Kunststoffverarbeitung sind am Hauptsitz
des Unternehmens in Loßburg gebaut. Dank ihres modularen Aufbaus können
die Maschinen sehr flexibel auf die relevanten Kunden-und branchenspezifische
Anforderungen angepasst werden.
Dienstag, 18. Dezember 2012
Donnerstag, 29. November 2012
1992 GIGAsteps Classics: Insourcing (Teil 7 und Ende)
„Die Sprache besteht in der Sprachgemeinschaft in Gestalt einer Summe von Eindrücken, die in jedem Gehirn niedergelegt sind, ungefähr so wie ein Wörterbuch, von dem alle Exemplare, unter sich völlig gleich, unter den Individuen verteilt wären. Sie ist also etwas, das in jedem Einzelnen von ihnen vorhanden, zugleich aber auch allen gemeinsam ist und unabhängig von dem Willen der Aufbewahrer."
Ferdinand de Saussure, Linguist, 1857 bis 1913[1]
6.0 Primat der Modelle
6.1 Chens Ansatz: Entity Relationship
Trennungsschmerz. Ein Paradigmenwechsel bahnt sich an: „Wir müssen
uns von der Vorstellung trennen, dass wir Daten managen, nur um einer Anwendung
zu dienen oder einer bestimmten Benutzergruppe", fordert Robert M. Curtice
von Arthur D. Little [2]Stattdessen müssen die
Daten ‑ losgelöst von den Anwendungen ‑ dem ganzen Unternehmen dienen. „Das
Managen von Daten heißt das Managen dessen, was Daten wirklich meinen",
befindet der Datenbank‑Experte Daniel S. Appleton, Präsident der
Beratungsfirma D. Appleton Inc. in Manhattan Beach (Kalifornien).[3] Subjektive und
objektivierte Vorstellungen über das, was Begriffe meinen, müssen
übereinstimmen. Die Datenmodellierung
nähert sich damit einem zutiefst philosophischen und schwierigen Thema: der
Klärung von Begriffen. Deshalb müssen diese Begriffswelten aus den bestehenden
Anwendungen herausgetrennt werden. Ein mitunter schmerzlicher Prozeß, denn
damit verbunden ist ein tiefer Blick in die Abgründe so mancher Altanwendung.
Seit mehr als anderthalb Jahrzehnten, seitdem Peter S.
Chen von der Louisiana State University 1976 mit seinem Vorschlag eines Entity
Relationship Modelling (ERM) die ersten Grundlagen für eine gemeinsame
Sicht der Daten geschaffen hatte, wurde die Datenmodellierung in Fachkreisen immer wieder
gefordert.[4] Aber sie wurde lange Zeit
aus der Perspektive der Technik und nicht der Begriffe betrachtet.
Wer aber sorgt mit seiner ganzen Expertise für die neue,
allgemein‑gültige Sicht? „Die meisten Organisationen haben auch heute noch
keine echte Datenadministration", warnt Vaughan Meryl, Chairman der
CASE Research Corp.. Die großen Firmen hätten zwar Datenbankverwalter,
aber die würden „sich in erster Linie um die technischen Funktionen kümmern.
Doch der Datenbank‑Administrator ist der Hüter der Information, der
sicherstellen muss, dass die Firma insgesamt eine gemeinsame Sicht der Daten
besitzt".[5]
Um das zu erreichen, empfiehlt der Schweizer Datenmodell‑Experte Vetter „eine strikte Trennung zwischen
Datenbank‑Administrator und Daten‑Administrator", gesteht aber ein, dass
aus Kostengründen für viele kleinere Unternehmen nur eine Personalunion in
Frage kommt.
Doch dieser Ansatz sollte „nach Möglichkeit vermieden
werden", empfiehlt Harald Huber, Datenbankexperte bei der USU
Softwarehaus Unternehmensberatung GmbH. Denn man würde „an den Namenkonventionen
ziemlich schnell erkennen, ob ein Datenmodell
von einem Datenbanker oder einem Daten‑Administrator gestaltet wird." Der
Datenbanker würde „physikalisch orientierte Namen" vergeben. Aber genau
das darf nicht der Fall sein, wenn man dem Vorschlag von Chen folgt.
Chens Ansatz war es, die
vielen Strömungen der Datenbankmodelle zusammenzufassen ‑ von den
hierarchischen bis hin zu den damals gerade erst aufkeimenden relationalen
Vertretern. Die Anwender sollten sich über den Inhalt ihrer Daten klar werden,
ohne sie gleich wieder aus der funktionalen Sicht der Anwendung zu betrachten.
Doch Chen heizte mit seinem Modell nur den internen Wettstreit der Datenbank‑Anbieter
an. Sie maßen sich zwar an der vorgeschlagenen „Common View" der Daten.
Die Diskussion blieb dabei auf die Fachzirkel beschränkt. Da muss sie nun raus.
Und die Zeichen dafür stehen gut.
Entitäten. Was die Ketten sprengt, macht Mallach
deutlich: „Zwischen dem Datenmodell und
dem Datenbank‑Design gibt es einen entscheidenden Unterschied. Datenmodellierung hat etwas mit dem Geschäftszweck
zu tun ‑ und nicht mit Computern. Sie verfährt mit Entities und Attributen, die
jene Entities definieren. Datenbanken hingegen kommen in verschiedenen Formen.
Das Datenmodell bleibt immer das
Gleiche."[6]
Es ist also eine Aufgabe, die sich wegen ihrer Dauerhaftigkeit lohnt, ohne dass
die Beteiligten zuerst Informatiker
werden müssen.
Der entscheidende Begriff bei der Datenmodellierung ist die Entität, sie
definiert „etwas Ganzes", erklärt Huber. Gemeint sind damit reale „Wesenseinheiten".
Dies kann zum Beispiel ein Angestellter sein oder ein Kunde. Ihnen können
Attribute zugeordnet werden wie zum Beispiel „Angestellter arbeitet zu X
Prozent an einm Projekt mit".
Aber Entities, Rhefus nennt sie auch Informationsobjekte,
sind nicht für jede Branche gleich. „Entities, die zum Beispiel für eine
Bank wichtig sind, interessieren Fertigungsunternehmen überhaupt nicht",
meint Mike Galivan, beim kanadischen Stahlgiganten Stelco Inc. in
Hamilton (Ontario) für die Systementwicklung verantwortlich.[7] Ergebnis: Letztlich muss
sich jedes Unternehmen sein eigenes Datenmodell
schaffen. Es kann allerdings dabei auf branchenspezifischen Konzeptionen zurückgreifen,
wie es etwa IBM mit dem COPICS‑Nachfolger CIM APPS für die Fertigungsindustrie
vorhält.
Auf der Basis eines Datenmodells haben die Entwickler die Chance,
sich endlich auf das Wesen der Dinge zu konzentrieren: „Die Entwicklung von
Datenkonzepten ‑ den sogenannten Entities ‑ ist der wirkliche
Schlüsselschritt", formuliert Curtice. „Entities geben eine
Terminologie vor, mit der sowohl der Benutzer als auch die Datenbank operieren
kann."
Im Idealfall werden damit nicht nur gegenwärtige, sondern
auch zukünftige Anwendungen erfaßt. Sicherlich der technische Aspekt ist immer
noch da, aber er ist losgelöst von den Anwendungen. Curtice: „Es ist das
Design der Datenbank, das Datenmodell,
das uns ein einheitliches Rahmenwerk beschert. Es sorgt dafür, dass alles
zusammenpaßt."[8]
Der deutsche Datenbankexperte Michael Bauer, Geschäftsführer der Informatik
Training GmbH, meint in der Computerwoche: „Der Nutzen eines neuen DBMS ‑
gleichgültig, ob relational oder objektorientiert ‑ erschließt sich erst bei einem
sauberen Datenmodell richtig. Und das zu schaffen, kostet Zeit."[9]
Damit setze sich die Erkenntnis durch, dass das Datenmodell eine ausgezeichnete Schnittstelle
zwischen der Fachwelt und der technischen Datenbankwelt bildet, zwischen den
Anwendern und der Datenverarbeitung. „Die Entwickler lernen dabei, dass es
weitaus wichtiger ist, die Entitäten eines Benutzers zu verstehen als dessen
Prozeduren", will Frank Sweet, Präsident der amerikanischen
Datenbank‑Beratung Boxes & Arrows in Jacksonville (Florida), der
Funktionsorientierung ein Ende setzen.[10] Indes sind in den
Prozeduren der Benutzer zumeist die Entitäten begraben. Sie müssen also
freigelegt werden. Das ist keine leichte Aufgabe.
6.2 Das Grob‑Grob‑Grob‑Konzept
Kulturrevolution. Vetter
empfiehlt deshalb zuerst die Entwicklung eines „Grob‑Grob‑Grob‑Konzeptes",
einer ersten Annäherung an das Unternehmensdatenmodell, in die auch das Top‑Management
involviert ist. „Es muss Druck von oben kommen", heißt der kritische
Erfolgsfaktor. Nach wenigen Wochen ist ein solcher erster Entwurf zumeist
fertiggestellt. In ihm sind die wichtigsten „Objekte" ( Vetter)
definiert, die ‑ wie zum Beispiel die Entität „Partner" ‑ auf den ersten
Blick „trivial erscheinen", doch hinter denen in Wirklichkeit komplexe
Klärungsprozesse stehen. „Ich habe in den zwölf Projekten, die ich mitbegleitet
habe, kein Unternehmen gesehen, bei dem die Zahl solcher Objekte höher als acht
war."
Bei der DG‑Bank ‑ so bestätigt Brandhofe ‑
waren es zum Beispiel sechs Objekte. Bei der Ausgestaltung zum 1990
fertiggestellten Unternehmensdatenmodell kristallisierten sich dann 160
Entitäten mit insgesamt 2.000 Attributen heraus.
Big Business. Es sind natürlich die großen Anwender, die
hier mit gutem Beispiel vorangehen. Die Hoechst AG etwa hat über 15
Fachbereiche hinweg ein hochverdichtetes ERM erarbeitet, das aus rund „70 Entitäten
besteht", berichtet Hoechst‑Manager Schmidt. Nach rund neun Monaten
war das konzernweit akzeptierte Unternehmensdatenmodell fertig.
Rhefus berichtet, dass innerhalb einer Arbeitsgruppe
der Benutzervereinigung GUIDE zum Thema Datenemodelle festgestellt
wurde, dass auf Unternehmensebene zwischen 60 und 120 Informationsobjekten
definiert würden. Auf Bereichsebene summiert es sich dann bereits zwischen 250
und 400 Informationsobjekte. Zieht man es noch weiter runter, auf die fachliche
Detailebene, dann addiert sich das auf bis zu 2.000 Informationsobjekte, die in
dem unternehmensweiten Datenmodell
zusammengefaßt werden.
Es steckt also eine Menge
Detailarbeit dahinter. Desto wünschenswerter ist es, wenn Hersteller mit Datenmodellen Hilfestellung geben können. Die
DG‑Bank ist zum Beispiel in ein Projekt der IBM Deutschland involviert, bei dem
für den Markt der Geldinstitute eine generisches Datenmodell entwickelt wurde. Es ist das
bereits erwähnte Financial Services Industry Data Model (FSI DM), Bestandteil
von IBMs Financial Application Architecture (FAA), die wiederum auf der System
Anwendungs‑Architektur (SAA) basiert. Und mit dem Entwurf ihres Information
Warehouse versucht IBM sogar einen Ansatz, heterogene Welten in dieses Thema
miteinzubeziehen.
An solchen Kooperationen und Entwürfen wird deutlich, dass
die Datenmodellierung eine intensive
Abstimmung zwischen Herstellern und Anwendern erforderlich macht. „Für IBM ist
es ein Feld, bei dem sie ihre Rolle als Systemarchitekt herausstellen kann und muss",
erklärt IBM Geschäftsführer Dorn. Dabei sind solche Datenmodelle aus der Perspektive des
Herstellers IBM in mehreren Kontexten zu sehen:
-
in einem internationalen Umfeld. IBM
qualifiziert sich hier als transnationaler Hersteller mit SAA.
-
in einem Branchenbezug: IBM erstellt Datenmodelle gemeinsam mit Kunden und Partnern
z.B für Branchen wie Finanzwirtschaft oder Fertigungsindustrie.
-
in einem heterogenen Systemumfeld. Darauf ist
letzten Endes der Entwurf des Information Warehouse ausgerichtet.
-
in einer CASE‑Umgebung. Darauf zielt zum
Beispiel das ERM im Repository Manager von AD/CYCLE.
Ade, AD/Cycle?
Ende der Superprojekte. Dass dies keineswegs triviale Unterfangen
sind, macht die Geschichte rund um den IBMs Repository Manager deutlich. Nach
nahezu zehn Jahren der Entwicklung musste IBM im Sommer 1992 verkünden, dass
es den RM wie geplant nicht mehr geben wird. Das Entstehen von LAN‑gebundenen
Workgroup‑Technologien, der Trend zu objektorientierten Programmier‑Systemen
und die Ausweitung der Unix‑Szene torpedieren die heile Welt von AD/Cycle.
Das Realitätsprinzip hatte voll
zugeschlagen. Große Softwaresysteme wollen der IBM offenbar nicht mehr
gelingen. Nachdem bereits OfficeVision auf eine Odyssee nach Nirgendwo &
Überall geschickt wurde, drohte AD/Cycle mit dieser Ankündigung ein ähnliches
Schicksal. Mit der Verheißung, eine schöne, neue Welt für die Software‑Entwicklung
zu errichten, war die auf die SAA‑Welt ausgerichtete CASE‑Familie im
September 1989 angekündigt worden. Gestellt unter das Patriat des IBM
Repository Managers (RM) sollte AD/Cycle unternehmensweit den Weg in die
seit 30 Jahren ersehnte Wiederverwendbarkeit von Code führen. Doch das
Zentralgestirn entwickelte nie jene Leuchtkraft, die sich ihre Entwickler von
ihm erhofft haben. Das harte aber kurze Urteil: zu spät, zu komplex und zu
teuer.
Hinzu kam, dass die Zeit der Superprojekte bei den Anwendern
schon lange zu Ende war, als IBM noch darauf setzte. Hinter dem Erfolg von SAP,
so haben Insider längst ausgemacht, steht nämlich bei vielen Anwendern das
Scheitern eigener Riesenprojekte im Bereich Individualsoftware. Auch IBMs Line
of Business Application Solutions rückt seit 1990 immer weiter von der
Entwicklung großer monolithischer Softwaresysteme ab und paßt sich dem neuen
Trend zu Composite Applications (zusammengesetzte Anwendungen) an.
Workgroups. Damit
wandelt sich die Anwendungswelt von der zentralgewaltigen Software‑Entwicklung
hin zu LAN‑gebunden Workgroup‑Umgebungen. In diesem neuen Paradigma arbeiten
viele Entwicklungsteams, mehr oder weniger losgelöst voneinander, an verschiedenen
Projekten oder Teilen davon, bei denen der Zugriff auf ein dediziertes Repositorium
genügt. Jenes Zentralsystem, in dem alle Entwicklungsarbeiten global und
synchron zusammenströmen, brauchen sie nicht mehr oder wenn in einer anderen
Form ‑ als Hort von vorgefertigen und wiederverwendbaren Softwarekomponenten,
die beliebig miteinander verknüpft werden können.
Homogeneität durch Heterogenität. Das bedeutet auch, dass
die Systemgrenzen, die AD/Cycle definierte, gesprengt werden. Entwicklungsumgebungen,
die im Unix‑Spektrum stehen, können nicht ausgesperrt werden ‑ zumal sie einen
nicht unerheblichen und wachsenden Teil der Anwendungswirklichkeit
repräsentieren. Merkmal eines Repositorium des neunziger Jahre kann es nur
sein, dass ein solcher Manager heterogene Welten zusammenbringt ‑ als composite
applications, die der RM in eine homogene Form bringt.
Das wäre dann in der Tat eine überragende Rolle, die einem
solchen Repositorium zukäme. Versteht man seinen Begriff als einen Ort, in dem
etwas abgelegt, genauer: zurückgestellt, wird, dann fungiert es eigentlich als ein
Legokasten, dessen Elemente dazu dienen, die reale Welt als Modell abzubilden.
Doch die Softwarewelt der Superprojekte scheiterte bislang immer wieder bei
dem Versuch, sich der realen Welt informationstechnisch zu bemächtigen.
Selbst ein Datenmodell
auf der Basis des Entity Relationship Modell (ERM), auch wenn es Daten und
Funktionen zusammenbringt, stößt dabei als Orientierung oder Bauanleitung an
seine Grenzen. Denn es ist darauf ausgerichtet, die relationale Welt (DB2) auszubeuten,
die mehr der Logik der Mathematik als der Spontaneität der ereignisgetriebenen
realen Welt folgt. Diese mathematisierte Modellwelt, obwohl gerade deshalb von
der verwissenschaftlichten Informatik
höchst anerkannt, ist nicht sonderlich gut geeignet Datentypen aus der
realen Welt wie etwa Geschäftsvorgänge und ‑regeln, Grafik, Bewegtbilder,
Sprache oder Text zu unterstützen. Ein Repositorium, das indes diese Elemente
nicht in seiner Ablage vorhält, kann nur eine höchst befristete Bedeutung
haben. Sie hilft dabei, überhaupt das Denken in Modellen einzugewöhnen.
Die Frage ist nun: Kann es den Transfer eines relationalen
Repositoriums zu einer objektorientierten Welt, in der Denken in beliebig
konfigurierbaren Modellen möglich und verlangt wird, tatsächlich leisten?
Hier gibt es inzwischen die stärksten Zweifel.
Objektorientierung. Schon technisch gesehen kann dies nur
mit einem Höchstmaß an Performance‑Verlusten geleistet werden. Deshalb wird
die Forderung immer lauter, dass einem solchen vielgestaltigen Informationsmodell
eine reinrassig objektorientierte Datenbank unterlegt sein muss. Sie bringt
nach dem heutigen Stand der Technik zumindest in Workgroup‑Umgebungen die
erforderliche Leistung. Sie reicht indes noch nicht aus, um ein zentrales Repositorium
zu stützen, um das AD/Cycle kreisen kann. Deshalb wird sich die SAA‑CASE‑Welt
wohl dezentralisieren müssen. Ade heile Welt! Willkommen reale Welt!
Fazit: wenn IBM ihr Allerheiligstes, den Repository Manager
retten will, dann muss sie ihn killen. Eine bittere Entscheidung, bei der
viele (reale) Manager bei IBM und einige bei ihren Kunden ihr Gesicht verlieren
werden. Nur mit einem objektorientierten Ansatz läßt sich die alte und nach
wie vor richtige Grundidee überliefern. Fünf Jahre gilt es dabei zu
überbrücken, bis ein zentrales Objekt‑RM steht.
In der Zwischenzeit aber bleibt IBM nichts anderes übrig,
als die objektorientierten Workgroup‑Angebote Dritter zu akzeptieren und
schnell unter Vertrag zu nehmen. Keiner von ihnen wird ernsthaft der Grundidee
widersprechen, dass ein solcher zentraler ORM vonnöten ist. Jeder von ihnen
wird gerne daran mitwirken, dessen Implementierung vorzubereiten. Denn er
gibt ihren eigenen Produkten die richtige Perspektive. IBM aber gewinnt Zeit, ohne
Zeit zu verlieren.
Alleinstellungsmerkmal. Mit diesen Anstrengungen, die
dann in einem Hintergrund‑Repositorium auf ein Metamodell konsolidiert werden,
kann es IBM nach Meinung von USU‑Geschäftsführer Udo Strehl gelingen, „ihr
Alleinstellungsmerkmal als Systemarchitekt" wieder herauszuarbeiten. „IBMs
Philosophie dahinter besteht darin, dass sie nicht länger diktieren will,
welche Anwendungssoftware ein Kunde installieren sollte", meint Judith
Fischer, Managerin bei The Huntington National Bank in Columbus (Ohio).[11] Indes gibt sie mit der
Definition des Datenmodells eine Menge
Kriterien vor, die für die Entwicklung oder Auswahl einer Anwendung wichtig und
verpflichtend sind.
6.3 Die zusammengesetzte Welt
IBMs Software‑Vision. Doch das ist ein Anspruch, die
einem Architekten, der verantwortlich wirken will, zuerkannt werden muss. Vor allem
dann, wenn er praktisch die gesamte Software‑Industrie aufrufen möchte, auf der
Basis von Datenmodellen Produkte zu
entwickeln. Das neue Schlagwort dabei heißt composite applications.
In einem vertraulich gehandelten Papier verbreitet IBM die
Vision, die hinter diesem Begriff steht. Sie klingt auf den ersten Blick
trivial: auf der Basis von IBM‑Architekturen soll sich eine Software‑Gemeinde
konstituieren, die Rahmenwerke wie AD/Cycle, Information Warehouse,
SystemView etc. mit Anwendungen füllt, die je nach Wunsch des Kunden
individuell zusammengesetzt (composite) werden.
Ein kompletter und offener Softwarekorb soll also entstehen,
aus dem der Kunde sich nach Herzenslust bedienen kann. Für jedes Problem soll
es dabei mehrere Lösungen geben. Manche wurden in IBM‑Labors entwickelt, andere
bei Softwarepartnern ‑ und natürlich werden sich auch Kunden daran beteiligen
können. Eine Softwaregemeinde auf Gegenseitigkeit soll entstehen, eine community
of mutual interests, eine workgroup. Ein prominenter Vorläufer dieses
Konzeptes ist bereits aus der AS/400‑Gemeinde bekannt: das MAS 90.
Bei den composite applications werden in den
Rahmenwerken der IBM sogenannte boxes definiert, in die nun Dritte ihre
Anwendungen hineinentwickeln können. Es wird dabei konkurrierende Angebote für
diese boxes geben. Denn Exklusivität ist der Tod des Wettbewerbs und der
Kontrapunkt zu jener Offenheit und Reichhaltigkeit des Angebots, die IBM
anstrebt. Ihre eigene Aufgabe sieht sie vor allem als Hüter der Architekturen,
der Betriebssystemumgebungen, der Datenmodelle
und Schnittstellen, ohne die der Integrationseffekt, auf den diese nach individuellen
Gesichtspunkten funktional „zusammengesetzten Anwendungen" zielen,
ausbleiben muss.
Systemplattformen wie SAA oder AIX werden von IBM aus einer
horizontalen Sicht betrachtet und miteinander vom Betriebsysstem bis hin zum Networking
konsistent gehalten. Damit will sie rund 20 Prozent der Ausgaben, die Kunden
für Softwaresysteme ausgeben, vornehmlich auf sich lenken. Darüber wölbt sich
ein Markt von Querschnittsdiensten, die weitere 20 Prozent des Geschäftes
adressieren. Dazu gehören
-
Anwendungstools (z.B. AD/Cycle). Hier, beim application
enabling befinden wir uns bereits in einer ersten Sphäre intensiver
Kooperationen.
-
die core application services (wie zum
Beispiel bei den Datenbanken). Hier wird sich IBM kaum die Butter vom Brot
nehmen lassen wollen. Doch sieht man zum Beispiel die Kooperationen, die im
Umfeld des Information Warehouse oder SystemView entstehen, dann gewinnt man
den Eindruck, dass auch hier die Zeit der monolithischen Gebilde vorbei ist.
Und auch bei den
-
die cross systems applications wie
Büroanwendungen oder Personalwesen. Hier wird IBM sich kooperativ wie nie zuvor
zeigen.
Branchenanwendungen. Doch das Hauptfeld des Marktes
und der Zusammenarbeit mit Dritten bilden die branchenspezifischen, vertikalen
Anwendungen, die 60 Prozent der Sofwareausgaben von Kunden ansprechen. Das ist
der wahre Tummelplatz der Kooperationen, mit denen Nischen und Marktritzen
gefüllt werden sollen ‑ von der breitgestreuten Fertigungsindustrie bis hin zu
Behörden und Geldinstituten.
Das entscheidende Paradigma, das
hinter composite applications steht, liegt in der Neuausrichtung des
Geschäftsfocus.
Im Brennpunkt stehten nicht mehr die Produkte, sondern
(endlich) die Probleme der Kunden. Nicht
einzelne, monolithisch gestaltete Softwarepakte sollen gepusht werden, sondern
die individuellen Wünsche der Anwender sollen aus einem reichgefüllten Korb an
(anonymen?) Lösungen bedient werden. Auch das hört sich trivial an, weist aber
daraufhin, dass IBM etwas anderes im Sinn hat als die Etablierung von weiteren,
ohnehin schon inflationär gehandhabten Markenzeichen.
Deren Bedeutung reduziert sich auf wenige Rahmenwerke wie
AD/Cycle oder CIM APPS. Diese Markenzeichen werden aber erst durch die Angebote
Dritter, die sich damit identifizieren, zum Leben erweckt. Sie materialisieren
sich in der individuellen Situation des Kunden.
Die Reduktion auf wenige Markenbegriffe wird den
Softwarehäusern bei ihren eigenen Marketinstrategien wesentlich helfen. Denn
die dafür erforderlichen Aufwendungen übersteigen inzwischen die Entwicklungskosten
erheblich. Die Softwarekrise wurde für viele Anbieter zu einer Marketingkrise.
Viele kleine Anbieter gehen nicht an den Entwicklungsaufwendungen zugrunde,
sondern sie brechen unter der Marketinglast zusammen.
Composite applications ist ein Stück Industriepolitik à la
IBM. Diese hat allemall bessere Chancen als staatliche Fördermittel oder
sonstige Erleichterungen. Was jetzt noch fehlt, ist die Formulierung von Integritätsregeln
für die Marketingpraxis. An ihnen muss sich beweisen, wie ernst es der IBM mit
der Gründung einer Softwaregemeinde auf Gegenseitigkeit tatsächlich ist. Das
wird nicht leicht sein, aber daran wird man den Unterschied zwischen Alter und
Neuer IBM messen können. Doch mit der Hinwendung zu objektorientierten
Ansätzen, die vielleicht endgültig die Softwarekrise bannen wird, bleibt den
Anbietern gar nichts anderes übrig als sich miteinander zu arrangieren.
Die Neue IBM sieht dabei natürlich ihre große Chance. Sie
positioniert sich auf diese Weise als ein Dirigent mit Weltgeltung, der das Software‑Orchester
durch die Partituren führt. Es sind dabei die Datenmodelle, die einen entscheidenden Anteil
an diesen Partituren haben. Denn sie sind die Grundlage, mit der die Solisten,
also die Softwarehäuser, ihre Qualitäten entfalten können.
Von IBM gemeinsam mit Kunden entwickelte und verfeinerte Datenmodelle sind aber auch ein Beweis dafür, dass
es dem Hersteller tatsächlich um Kundennähe geht. Denn IBM gibt mit ihren
Entwürfen den Kunden eine profunde Vergleichsbasis für eigene Schöpfungen. So
ist in Großbritannien die National Westminster Bank (NatWest) derzeit
dabei, ihr eigenes Datenmodell mit dem
von FAA zu vergleichen.[12] Der Hintergedanke: je
größer die Schnittmenge zwischen den beiden, desto sicherer ist die Bank, dass
ihr eigener Entwurf stimmig ist mit den Anforderungen ihres Marktes, der
zunehmend von unternehmensübergreifenden Aktivitäten geprägt ist.
Umstellung auf DB2 als Anlass.
Auch wenn Datenmodelle unabhängig
von der Datenbanktechnologie betrachtet werden können, so hat dennoch die
Technik an deren zunehmender Bedeutung einen entscheidenden Anteil. Als sich
Mitte der achtziger Jahre die relationalen Datenbanksysteme durchsetzten, war
der Ideologie‑Streit der Experten untereinander beigelegt. Zumindest konnten
nun die Daten losgelöst von den Anwendungen betrachtet werden, eine riesige
Hilfestellung bei der Überwindung der Altlasten.
Bei der DG‑Bank entstand zum
Beispiel 1986 auf der Basis von DB2das
unternehmensweite DG Informations‑ und Auskunftssystem, das auf einem Datenmodell basiert. Dass es indes noch nicht
die Integrationsfähigkeit eines zukünftigen Information Warehouse hatte,
zeigte sich nach der Not‑Aufnahme der Bayerischen Raiffeisen Zentralbank AG
Anfang 1986. Deren gewachsene IMS‑Basis mit ihren eng verwobenen COBOL‑Anwendungen
ließ sich nicht ohne weiteres in das neue Auskunftssystem integrieren. Es
fehlte das gemeinsame Datenmodell als
Brückenkopf, das auch im Information Warehouse eine Schlüsselbedeutung
besitzt.
6.4 Die Kulturrevolution
Höchste Priorität. *]
Heute weiß man das alles besser. „Jede wichtige Anwendung muss auf einem Datenmodell basieren", urteilt Mallach.
Aber: „Das Fundament, auf dem das Datenmodell
aufbaut, ist die Datenbank selbst" ‑ und es sind eben nicht die
Anwendungen. Diese „können nicht eher stehen, als bis die anderen beiden fest
plaziert sind" ‑ die Datenbank und das Datenmodell.[13]
In dieselbe Richtung denkt wohl
auch Harald Huber, Datenmodellexperte bei der USU in Möglingen: „Natürlich ist
es Ziel der Datenmodellierung, ein den
Anwendungen gegenüber neutrales Begriffssystem zu schaffen. Nur so kann es die
Basis für eine Entwicklung von integrierten Anwendungssystemen
darstellen". Doch dann kann ein solches Datenmodell „automatisch in ein konkretes
Datenbankschema transferiert werden. Damit wird es eine entscheidende Grundlage
für die Anwendungsprogramme" ‑ und IBM ist nolens, aber noch mehr volens
mit ihrem Datenbankangebot im Spiel.
Doch dies ist ein Effekt, es ist
nicht Ursache. „Der Einzug von DB2hat
die Diskussion um die Schaffung eines Datenmodells
zwar gefördert, aber dies war nicht der Grund, sondern unser Bemühen, die
Software‑Entwicklung zu verbessern", berichtet Münzenberger über sein Unternehmen. Bei
einer Luftlinie sind viele Produkte nicht nur informationsgetrieben, sondern
sie sind auch eingebettet in komplexe Vorgänge, die durchaus
unternehmensübergreifend wirken. Nehmen wir als Beispiel nur die Reservierung
oder die Erstellung der Flugpläne. Das Datenmodell
hilft die Begriffe zu klären und die Abhängigkeiten zu analysieren.
Anstoß für die Datenmodellierung
gab auch bei NatWest die Umstellung auf DB2. Unter dem Namen Customer
Relationship Database wurde hier nach Aussage von Ike Richards, Chef der
Bankensysteme für die Zweigstellen, „das größte Anwendungs‑Projekt der Welt für
IBM DB2-Datenbank" realisiert, dass
vergleichbare Unterfangen an Größe um „den Faktor 4" übertrifft.[14]
Widerstandsbewegung. Na
gut. Wichtig ist zu erkennen, dass solche feingeschliffenen Datenmodelle, die sich dann in Projekten
bewähren, nicht über Nacht gedeihen, sondern sie materialisieren sich bei
großen Unternehmen über einen Zeitraum von bis zu zehn Jahren. Dabei gilt es
mitunter gewaltige mentale Widerstände zu brechen, die vor allen Dingen von den
Entwicklern selbst aufgebaut werden. Denn für sie bedeutet es der Umstieg auf das
Denken in Modellen.
„Dort, wo es um globalen Modelle
geht, können Erfolge erzielt werden", berichtet Werra. „Aber in der Programmierung sind
die Widerstände da. Denn verbunden ist dieser Ansatz mit der Einführung von
CASE‑Konzepten. Bei der Gewinnung der Mitarbeiter bedarf es oftmals enormer
Anstrengungen".
Damit markiert er die Bruchstelle
in der Datenmodellierung. Bei der
Festlegung eines unternehmensweiten
Datenmodells geht es zuerst einmal ja „nur" um ein Grobkonzept, in
dem ‑ so Vetter ‑ „typenmäßige aber keine exemplarspezifischen Aussagen über
einen zu modellierenden Realitätsausschnitt" getroffen werden. „Es ist
neutral gegenüber den Einzelanwendungen und deren lokaler Sicht auf die
Daten". Und weiter: „Es stellt das Informationsangebot der Gesamtunternehmung
auf begrifflicher (typenmäßiger) Ebene dar und fungiert als Schnittstelle
zwischen Anwendungen und Anwender als Informationsnachfrager einerseits sowie
Datenorganisation und Datenverwaltung als Informationsanbieter
andererseits".[15] Diese Sicht von oben wird
indes ergänzt durch die von unten ‑ aus den Projekten. Die hier gewonnenen
Erfahrungen müssen in das Grobmodell einfließen. Das heißt: die
Datenmodellierung tangiert im hohen Maße die Anwendungs‑Entwicklung. Hier regen
sich aber auch die meisten Widerstände.
Richtige Leute. Unbestritten ist, dass Datenmodelle letztlich zum Nutzen und Frommen
aller Benutzer wirken. Es kommt nun vor allem darauf an, dass auch die
Entwickler erkennen, dass sie sich nur so aus einer unlösbar scheinenden Pattsituation
befreien können. Diese Aufklärung kann durchaus in eine „Kulturrevolution"
münden. Es gilt die Widerstände zu brechen. „Mit Saboteuren haben Sie es immer
zu tun", warnt Vetter.
„Systementwicklung auf der Basis eines Datenmodells ist wie eine Kulturrevolution.
Man kann sie nur dann erfolgreich praktizieren, wenn die Projektmitarbeiter
diese Kulturrevolution auch wollen", fordert der frühere MBB‑Datenmodellierer Mistelbauer. Um deshalb so ein Thema wie Datenmodellierung innerhalb des IS‑Bereichs
durchzusetzen, braucht man indes „auch ein bißchen Glück. Es geht darum, die
richtigen Leute zu finden." Da gibt es seiner Einschätzung nach
Mitarbeiter, die „reden über jene Realität", die sie im funktionalen
Blickwinkel haben. Und hier ist die Gefahr groß, dass es „beim Reden
bleibt", ergänzt Lufthansa‑Experte Münzenberger.
In Modellen denken. Was stärker gebraucht wird, sind
Fachleute, die „in Modellen denken können, die Erkenntnisse aus der praktischen
Arbeit als Regeln und Strukturen formulieren können" (Mistelbauer).
Solche Streitgefährten zu finden, ist nicht einfach. Deshalb vielleicht seine
Beschwörung des Erfolgsfaktors „Glück".
Indes wird immer deutlicher, dass der angeblich so
realitätsverhaftete Funktionalismus in eine Pattsituation driftet.
Hervorgerufen wird sie durch den existierenden Anwendungsbestand, der allein in
der Bundesrepublik einen Wert von mehr als 120 Milliarden Mark darstellt. Wie
stark dieses Patt wirkt, macht eine Untersuchung der Beratungsfirma CSC Index
Inc. in Cambridge (Massachusetts) deutlich. 142 amerikanischen Top‑Anwender
befragte das Institut. Ergebnis: rund 60 Prozent der Anwender gaben zu, dass
sie allmählich unter ihrer COBOL‑Altlast zusammenbrechen. Gleichzeitig ist es
ihnen unmöglich, überhaupt noch auf neue Anforderungen der Benutzer einzugehen.
Nichts geht mehr.
In der Tat: Wurde bislang angenommen, dass 80 Prozent des
Software‑Budgets in die lästige Wartung investiert wird, so erscheint diese
Angabe inzwischen als eher konservativ. „Wir waren es bislang gewohnt von einem
Verhältnis von 80:20 zwischen Wartung und Neuentwicklung zu sprechen. Doch
heute ist diese Relation eher 90:10", befindet Hugh Ryan, Direktor für
neue Systeme bei Andersen Consulting in Chicago, dem Informatikzweig der
Wirtschaftsprüfungsgesellschaft. Entsprechend ist das Stimmungsbild bei den
Anwendern. Ryan: „Es herrscht allgemein der Eindruck, dass es immer schwieriger
wird, neue Anwendungen herauszubringen".[16]
Modellklemme. Das bringt nun ausgerechnet die Datenmodellierer in eine Klemme. Denn bislang
gehen sie davon aus, dass der Segen ihrer Arbeit nur bei neuen Projekten so
richtig wirken kann. Mehr noch: Die Altanwendungen sollen sich „allmählich
ausleben, wenngleich dies über einen längeren Zeitraum geschehen wird",
weiß Werra von der R+V keinen
anderen Rat. „Ein altes Projekt läßt sich auf Datenmodelle nicht umstellen",
komplettiert Henkel‑Experte Rhefus das Dilemma. Die Situation
scheint fatal. „Das Datenchaos wird erst aufgedeckt, wenn es um die Integration
geht", konstatiert Breutmann von der Fachhochschule Würzburg. Dann ist der
Punkt erreicht, wo das Datenmodell
helfen soll, aber es läßt sich nicht aktiv an dem Integrationsgegenstand
anwenden!
Sind die bestehenden Applikationen also doch als „Altlasten"
stigmatisiert? Mistelbauer mag es nicht glauben. „In den alten
Anwendungen steckt implizit das Datenmodell",
hält er dagegen. Es muss aus ihnen herausdestilliert und in das globale.
konzeptionelle Datenmodell überführt
werden. Aber geht der Weg auch zurück?
Ein Beispiel dafür mag der aus COPICS bei IBM entwickelte
Nachfolger CIM‑PPS liefern. Hier wurde aus den alten Anwendungen das Datenmodell herausgefiltert, um schließlich in
das auf DB2 umgestellte CIM‑PPS, das im ersten Anlauf den Funktionsumfang
beibehält, einzufließen. Doch auch hier wurde deutlich: es ist und bleibt eine
Umstellung, die Zeit und Geld kostet.
Es sind Investitionen, die keiner sieht.
[1]
Kuno Lorenz: „Die Höhepunkte der
sprachlichanalytischen Philosophie ‑ Ludwig Wittgensteins Vermittlung von
logischem Empirismus und linguistischem Phänomenalismus" in „Linguistik
und Sprachphilosophie, München, 1974, ISBN 3 472 6 1427 3
[2] Datamation,
1/86, Robert M. Curtice: “Getting the database right"
[3] Datamation,
1.5.86, Daniel S. Appleton: „Rule based data resource management"
[4] Datamation, 1.5.86, Daniel S.
Appleton: „Rule based data resource management"
[5] Computerworld, 2.7.90, Rosemary Hamilton: „CASE veterans say: lool
before you leap">]
[6] Computerworld,
20.8.90, Efrem Mallach: „Without a data model, everything falls down"
[8] Datamation, 1/86, Robert M.
Curtice: „Getting the database right"
[9]
Computerwoche, 21.8.92, Michael Bauer: „Kaum eingesetzt und beinahe schon
veraltet"
[10] Computerworld,
28.11.88, Frank Sweet: „Database directions"
[11] Computerworld,
27.4.92, Thomas Hoffmann: „IBM shows its flexibility to
financial users"
[12] Financial
Times, 17.12.91, Dave Madden: „Bankig on a database"
[14] Financial Times, 17.12.91, Dave Madden: „Bankig on a database"
[15]
Institut '90, IBM Deutschland GmbH, Stuttgart, 12.‑13.9.90, Vortragsunterlagen,
Dr. Max Vetter: „Die globale Datenmodellierung zur Lösung des `Jahrhundertproblems
der Informatik'"
Mittwoch, 28. November 2012
1992 GIGAsteps Classics: Insourcing (Teil 6)
„An dieser Stelle möchte ich hervorheben, dass jede gesellschaftliche Institution, wenn sie bei der Bewältigung von Informationen wirklich funktionieren soll, ein theoretisches Konzept vom Zweck und von der Bedeutung von Information haben muss, dass sie über Mittel verfügen muss, diesem Konzept einen klaren Ausdruck zu geben, und zwar vor allem, indem sie bestimmte Informationen unterdrückt."
Neil Postman, amerikanischer Sozialkritiker in seinem Buch „Das Technopol"
5.0 Gegen den Egoismus
5.1 In Erwartung des Unerwarteten
Ko‑Ordination. Ungeduld ist das, was sich in den
neunziger Jahren kein Unternehmen mehr leisten kann. „Das größte Problem, das
wir in den neunziger Jahren haben ist nicht technischer Natur, sondern das der
Koordination von Menschen", befindet Laszlo Belady, Direktor des
Software Research Programms bei dem Forschungs‑Konsortium Microelectronics
& Computer Technology Corp. (MCC) in Austin (Texas). „Koordination von
Leuten ist das Geschäftsproblem schlechthin, das Manager lösen wollen",
bestätigt auch Benn Konsynsky, Professor für Management Informations‑Systeme an
der Harvard Business School. Denn von den Menschen geht stets das Unerwartete
aus.
Das Datenmodell kann
hier enorm helfen, das Unerwartete zu erwarten, klärt es doch zumindest die
gemeinsam verwendeten Begriffe. Sie müssen eindeutig sein, wenn das
funktionieren soll, was Thomas Malone, Professor am Massachusetts Institute of
Technology (MIT), den „Stoffwechsel der Informationen" nennt, der nicht
nur zwischen den Benutzern und dem Computer, sondern zwischen verschiedenen
unternehmensweit verteilten Datenbanken ‑ und damit zwischen Menschen aus
unterschiedlichen Abteilungen und Bereichen ‑ stattfindet. [1]Engstirniger
Abteilungsegoismus läßt sich in den neunziger Jahren nicht mehr durchhalten. Es
muss unternehmensweite Klarheit herrschen über die verwendeten Begriffe, wenn
sich so etwas wie die vorgangsorientierter Arbeitsweise durchsetzen soll. Und
damit sind auch die Topmanager im Boot, die allzu gerne der DV die Schuld
zuweisen für organisatorische Mißstände. „Dabei waren sie es, die es
versäumten, den Technologen die richtigen Fragen zu stellen", dreht Colin
Lesson von der Managementberatung PA Computers and Telecommunications den Spieß
um.[2] Das Thema, das damit
adressiert wird, ist die Prozeßmodellierung, die gleichsam neben der Datenmodellierung aufsetzt. Mit ihr kann der
Informationsfluß vorgangsorientiert gesteuert werden und somit einen Puffer
gegen den größten Störfaktor, das Unerwartete, bilden.
Dieses Unerwartete wird vor allem dann offenbar, wenn
Systemwechsel anstehen ‑ und zwei Softwarewelten aufeinander stoßen:
Außer Kontrolle. So wurde im September 1991 das
Auswärtige Amt Großbritanniens vom Rechnungshof, dem House of Commons Public
Accounts Committee, „stark kritisiert", weil es sein Rechnungswesen
softwaretechnisch miserabel unterstützte. Der Übergang von einer alten zu einer
neuen Anwendung, der mit einem Jahr Verspätung im November 1989 vollzogen
wurde, erwies sich als eine Katastrophe. Die neue Software produzierte einmal
ganz andere Ergebnisse als die alte Anwendung, die parallel für eine
Übergangszeit noch gefahren wurde. Zum anderen nutzte der Kassierer des
Auswärtigen Amtes die mangelhaften Kontrollmechanismen und bereicherte sich um
31.000 Pfund. Kleinmütig musste das Außenministerium zugeben, dass es nicht in
der Lage war, solch ein Projekt zu managen. „Wir waren konsterniert darüber, dass
es so lange gedauert hat, bis dies erkannt wurde und ein besseres Projekt‑Management
installiert wurde", schrieben die britischen Rechnungsprüfer.[3] Das Informationschaos wird
zumeist in dem Augenblick offenbar, in dem Daten unternehmensweit erschlossen
und integriert werden sollen. Der egoistisch angelegte Funktionalismus begrenzte
den Sinn der Informationen zu stark auf Abteilungs‑ oder Fachbereichsebene.
Damit zerstörte er nachhaltig den Zugang zum Rohstoff, zu den Daten, die dem
Gesamtunternehmen gehören und auch von ihm erschlossen werden sollen. Das
Datenchaos ist das Ergebnis. Der den Benutzeranforderungen hinterherhetzende
Funktionalismus, der der Softwareentwicklung oktroyiert wurde, erstickt mit der
Zeit jeden Versuch, die Daten unternehmensweit zu öffnen. Er produzierte nur
spezielle Informationen, die routinemäßig einem genau definierten, eingeengten Insider‑Kreis
vorbehalten waren.
5.2 Gegen die Abteilungsgrenzen
Prozeßmodellierung. Den kaum zu befriedigenden Druck
in Richtung Funktionalismus erzeugen immer wieder die Abteilungsmanager, die
nach höherer Produktivität strebten ‑ nicht des Gesamtunternehmens, sondern des
einzelnen Mitarbeiters, für den sie Verantwortung tragen. Terrence R. Ozan, der
bei der Wirtschaftsprüfung Ernst & Young in den USA den Fertigungsmarkt
betreut, ermittelte aber, dass die „Arbeitskosten bislang zwar einen
bedeutenden Faktor bei den Investitionsentscheidungen spielten. Doch in einigen
Fällen haben wir inzwischen herausgefunden, dass die Arbeitskosten so
unbedeutend sind für das gefertigte Produkt, dass es sich noch nicht einmal
lohnt, sie zu messen."[4]
Nicht durch Erbsenzählen wird Produktivität erzielt, sondern
durch Straffung und Ordnung der unternehmensweiten Geschäftsprozesse und
Berichtswege. So folgt denn auch der Datenmodellierung
die Prozeßmodellierung auf dem Fuß. Und diese Annäherung weist deutlich über
die bisherige Anwendungswirklichkeit hinaus, die sich am Egoismus von
Abteilungen und Mitarbeiter orientiert. „Die Fachbereiche glaubten in der
Vergangenheit, dass sie ihre Daten für sich allein gepachtet hätten. Dieses
Besitzstandsdenken läßt sich heute nicht mehr aufrecht erhalten", meint
CAP‑debis‑Berater Mistelbauer. „Daten müssen heute im Unternehmen
optimal genutzt werden. Sie müssen deshalb entlang der neuen Prozeßketten allen
verfügbar sein."
Noch verharren indes zuviele Unternehmen in diesem
Abteilungsegoismus. Dies bestätigt eine amerikanische Untersuchung, die von den
Wissenschaftlern Thomas Davenport, Robert Eccles und Lawrence Prussack an der Sloan
Management School bei 25 US‑Firmen durchgeführt wurde. Danach grassierte in
der Hälfte der Unternehmen das, was die Experten ironisch „Informations‑Feudalismus"
nennen, ein Drittel der Firmen schwelgte in einer „Informations‑Utopie"
und der Rest litt unter „Informations‑Anarchie". Aussage der
Wissenschaftler: „In den meisten informationsorientierten Unternehmen, die wir
analysierten, waren die Mitarbeiter am wenigsten dazu bereit, Informationen
untereinander zu teilen.[...] Wenn Information die primäre Währungseinheit
sind, dann sollten wir nicht erwarten, dass deren Eigentümer auch bereit sind,
sie einfach zu verschenken."[5]
Um diese Zustände zu durchbrechen, unter denen die Firmen
offensichtlich kräftig litten, empfehlen sie den „Informations‑Föderalismus".
Und wenn Information eine Währung ist, dann müßte es auch so etwas wie eine
Bundesbank geben, die darüber wacht. Vorsitzender einer solchen Institution
wäre dann der Chief Information Officer sein. Er sollte darüber wachen, dass
„die mächtigen Barone bereit sind, Informationen mit anderen zu teilen."
Firmen, die diese Strategie beherzigen, sind nach Aussage der Wissenschaftler
IBM, Xerox, Kodak und Merrill Lynch. Hier stünden an der Spitze der betrieblichen Informatik Manager, die sich weniger durch
technische background auszeichneten, sondern vielmehr durch Führungsqualitäten.
„Kein noch so hoher Aufwand an
Datenmodellierung, keine noch so große Zahl an relationalen Datenbanken
und keine noch so große Beschwörung der `informationsbasierenden Firma' kann
eine neue Informationspolitik herbeizaubern. Was man dazu benötigt, ist das,
was einen Politiker auszeichnet: Verhandlungsgeschick, Ausübung von Einfluss,
Arbeit im Hintergrund, Bildung von Koalitionen und gelegentlich sogar das
Heraufbeschwören eines Krieges." Der Information Manager ist also eminent
gefordert. Letztlich muss er mithelfen, die gesamte Unternehmensorganisation zu
erneuern, damit die „Währung Information" endlich in Fluß gerät.
Drei Beispiele. Dort, wo die Macht der Barone
gebrochen wurde, da wurden auch überraschende Ergebnisse erzielt:
-
Die Trustee Savings Bank (TSB) in
Großbritannien hatte seit 1988 das Netzwerk ihrer 1.400 Zweigstellen völlig
reorganisiert. 25 Prozent der Arbeit, die bislang vor Ort erledigt wurde, aber
nichts mit einem direkten Kundenkontakt zu tun hatten, wurden zentralisiert.
Gleichzeitig wurden die Zweigstellenleiter mit mehr Kompetenz ausgestattet. Mit
wenigen Tastengriffen stehen den Mitarbeitern alle Informationen zur Verfügung.[6] So können sich die
Mitarbeiter mit dem gesamten Unternehmenswissen dem Unerwarteten stellen.
-
Eine Versicherungsgesellschaft ermittelte, dass
eine neue Police durchschnittliche 22 Tage brauchte, bis sie von allen Instanzen
bestätigt war. Die tatsächliche Bearbeitungszeit aber betrug nur 17 Minuten.
Der Rest der Zeit ging dafür drauf, die Police zwischen den Experten hin und
her zu bewegen. Nun bearbeitet ein einziger Mitarbeiter den Vorgang, der nach
eigenem Gutdünken die Experten einschaltet. Der amerikanische Versicherer Mutual
Benefit Life schaltete um auf diese vorgangsorientierte Arbeitsweise und
registrierte einen Produktivitätsanstieg von 60 Prozent.
-
Die IBM Credit Corp. (ICC), die für das
Leasing‑Geschäft des Computerherstellers in den USA und anderen Ländern verantwortlich
ist, reduzierte durch ähnliche Maßnahmen die Bearbeitungszeit von Spezial‑Verträgen
von sechs Tagen auf vier Stunden. Gleichzeitig erhöhte sie den Durchsatz an
Verträgen um den Faktor 10. Es werden zudem weniger Mitarbeiter gebraucht.
Der Erfolg liegt nicht so sehr in den
Produktivitätsgewinnen, die diese Beispiele dokumentieren, sondern dass sich
der Mensch so dem Unerwarteten viel besser stellen kann. Er kontrolliert den „technologischen
Impetus" ‑ wie es der Philosoph Hans Jonas nennt. Der Mitarbeiter koordiniert
die Vorgänge so, dass deren möglicherweise überraschenden Implikationen ihre
zerstörerischen Wirkungen verlieren. Und die Technologie unterstützt ihn dabei.
Sprache als Schlüssel. Das alles verlangt, dass ‑ wie
bereits gesagt ‑ unternehmensweit Klarheit und Verbindlichkeit über die
verwendeten Begriffe besteht. Die Worthorizonte müssen genau abgestimmt sein.
Was ein „Kunde" ist, muss in seiner Bedeutung ebenso eingegrenzt sein wie
der Begriff „Auftrag". So bequem es ist, Begriffe aus freiem Gutdünken mit
eigenen Bedeutungen einzuführen, im Zusammenspiel eines vorgangsorientiert
arbeitenden Unternehmens können sie den Sinnzusammenhalt zerstören. Dann
entsteht erneut Informationschaos.
Es ist nunmal höchste Zeit, dass eine einheitliche Sicht der
Daten angepackt wird. Denn die Glaubwürdigkeit der Datenverarbeitung wird
längst in der Wirtschaftspresse diskutiert. So berichtete die Londoner Financial
Times von folgendem Fall.
Die ganze Person...
In ein Desaster geriet die Sozialversicherung in Großbritannien, die in
den sechziger Jahren noch zu den Pionieren auf dem Gebiet des DV‑Einsatzes
gehörte. In den frühen achtziger Jahren war das System indes völlig verrottet.
In den Außenstellen der staatliche Rentenversicherung mussten die Zahlungen an
20 Millionen manuell ausgerechnet werden. Versuche, das System dann 1983 zu
erneuern, scheiterten zuerst einmal kläglich im Kompetenzstreit der einzelnen
Behörden. Das Sozialministerium schaltete schließlich die Beratungsfirma
Andersen Consulting ein, um das Projekt neu aufzusetzen. Sieben Jahre später
hatten die Berater und Mitarbeiter das 1,5 Milliarden Pfund teure Superprojekt
dann gemeistert.
Managebar wurde es, weil Andersen Consulting dahinter eine
Vision gesetzt hatte, die von jedem verstanden werden konnte. Es war die Idee
von der whole person. Über jeden Empfänger sollte ein genau modelliertes
Datenbild angelegt werden, in das all seine Bezüge eingebracht werden konnten.
... der ganze Vorgang.
Im Hintergrund dieses Datenmodells stand
aber auch eine ganz andere Arbeitsweise für die rund 34.000 Mitarbeiter. Das
heißt: die Prozesse wurden neu modelliert. Obwohl durchaus hervorragend
ausgebildet, mussten die Sachbearbeiter bislang stupide Fließbandarbeit im Büro
erledigen. Mit der Computerisierung sollte das in vorgangsorientierte
Arbeitsweisen umgestaltet werden. Ein richtiger, wengleich auch sehr
ehrgeiziger Ansatz, zumal viele Mitarbeiter noch nie in ihrem Leben mit einer
Tastatur gearbeitet hatten.
Die Entwickler, die an dem Projekt beteiligt waren, wußten
genau, dass „ihre persönliche Karriere auf dem Spiel stand, falls es schief
lief", berichtet Keith Burgess, Managing Partner bei Andersen Consulting.
Genau das schreckte so manchen ab. Dennoch ‑ das Projekt wurde gemeistert, denn
die meisten erkannten, dass ihnen eine Chance geboten worden war, die man nur
einmal in seinem Leben bekommt.
Auf seinem Höhepunkt waren 2.000 Mitarbeiter an der
Implementierung des komplexen Software‑Systems beteiligt, das 70 Mainframes an
sechs Lokationen umfaßte. „Es ist ohnegleichen in der kommerziellen Welt und
vielleicht sogar auch gegenüber dem Verteidigungsbereich" (Burgess),
obwohl hier bereits große Erfahrungen auf dem Gebiet langjähriger Superprojekte
gesammelt wurden. Doch nach Meinung von Burgess gab es bislang kein Projekt „dieser
Größenordnung und Komplexität".[7] Na gut.
Das Beispiel zeigt, dass von einem einzigen Begriff, dem der
whole person, Wohl & Wehe eines ganzen Projektes abhängig sein kann.
Der Chemiekonzern Hoechst AG in Frankfurt, der kräftig in die Datenmodellierung investiert, hat aus diesem
Grund sogar ein „Genehmigungsgremium für Unternehmensbegriffe" gegründet.
Geleitet wird es übrigens von einem Vorstandsmitglied. So wird die Flut von
Synonymen, Homonymen etc. eingedämmt. Über die Sprache erschließt sich ein Unternehmen
dann seine neuen und seine in den alten Infrastrukturen verborgenen Potentiale.
5.3 Der Methodenstreit
Rückendeckung vom Topmanagement. Es ist in der Tat ein Thema,
das unbedingt die Rückendeckung durch das Topmanagement benötigt. Für Henkel‑Manager
Rhefus beginnt sogar alles „beim
Topmanagement, das für die zentralen Unternehmensbegriffe verantwortlich sein
sollte und gleichzeitig durch Grundsatzentscheidungen die Voraussetzung für ein
einheitliches Vorgehen schaffen muss." So geschehen bei Henkel. Und
bei der Lufthansa genießt die Datenmodellierung
ebenfalls die „erforderliche Aufmerksamkeit des Topmanagements", berichtet
Münzenberger. Hier wird auch von
den Fachbereichen akzeptiert, „dass die Datenmodellierung
ein ausgezeichnetes Kommunikationsmittel zwischen ihnen und der
Datenverarbeitung darstellt". Bereits Mitte der achtziger Jahre hat die
Luftlinie damit begonnen, das Vettersche
`Jahrhundert‑Problem' anzugehen. Empfiehlt Münzenberger: „Wichtig ist dabei, dass
vor allem die organisatorischen Voraussetzungen geschaffen wurden, um dem
Datenchaos zu Leibe zu rücken. Wir gehen nach der Reihenfolge vor: Mensch,
Methoden, Tools. Also zuerst die Information, dann die Schulung und schließlich
die technischen Hilfsmittel ‑ inklusive eines umfassenden Projektsupports. Das
hat sich bewährt."
Die Richtigkeit dieser Vorgehensweise bestätigt auch Howard
Fosdick, Präsident der Fosdick Consulting Inc. in Villa Park (Illinois): „Zum
ersten Mal seit 30 Jahren entfernen wir uns von dem Codieren" als dem
vorherrschende Organisationsprinzip für Anwendungsentwickler. Statt des
Funktionalismus rücken Training und Methodologie an die erste Stelle.[8]
Philosophiestreit. Bei der Vorgehensweise zum Thema Datenmodellierung stoßen natürlich immer
wieder zwei Denkansätze aufeinander: top‑down oder bottom‑up. Henkel‑Manager
Rhefus stellt die beiden Methoden
so vor:
„Beim top‑down‑Ansatz [...] wird zunächst der
Informationsbedarf des Unternehmens in einem groben Unternehmensdatenmodell
(UDM) abgebildet. Das UDM dient dann als Basis für die Erstellung detaillierter
Projektdatenmodelle."
„Beim bottom‑up‑Ansatz werden die nacheinander
entstehenden Projektdatenmodelle zunächst zu einem Basisdatenmodell integriert.
Dieser wird dann jeweils zu einer aus mehreren Ebenen bestehenden Unternehmens‑Datenarchitektur
verdichtet, deren oberste Ebene dem UDM des top‑down‑Ansatzes
vergleichbar ist."
Gleichgültig, für welche Methode man sich entscheidet ‑
Pragmatismus ist bei alldem gefragt und gefordert, weshalb viele das „bottom‑up"‑Verfahren
zuerst einmal bevorzugen. Denn dort, wo Datenmodellierung
im „Top‑down"‑Verfahren von einem globalen Ansatz angegangen wird, wird
sie schnell „als eine theoretische Sicht" stigmatisiert, wie Alan Bignall,
Vice President für Informationssysteme beim Finanzdienstleister IDS, diese
Vorgehensweise bezeichnet.[9] Mit ihr können sich vor
allem die Benutzer nicht identifizieren, aber auch nicht das Topmanagement, die
dieser Form der Grundlagenforschung unwillig gegenüber steht. Es ist ihm
suspekt und bestätigt einmal mehr die leidvollen Erfahrungen der Vergangenheit
mit der Datenverarbeitung. Deshalb hat das „bottom‑up"‑Verfahren mehr
Freunde. So auch bei der Lufthansa. Hier wurde zuerst eine klassische bottom‑up‑Philosophie
gefahren. Das heißt aus den einzelnen, bestehenden Anwendungen wurde das Datenmodell herausdestilliert. Münzenberger: „Diese wird künftig
vermehrt durch Top‑down‑Betrachtungen überlagert. So wurde zuerst für
das Vorstandsressort Technik über projektbezogene Datenmodelle auch ein Ressort‑ Datenmodell
erstellt. Dies wiederum dient als Input für das Lufthansa‑ Datenmodell".
Insgesamt besitzt die Lufthansa etwa ein gutes Dutzend
Experten auf dem Gebiet der Datenmodellierung.
Mitte der neunziger Jahre wird die Airline soweit sein, dass alle Modelle zu
einem einzigen globalen Gebilde zusammenfließen.
Ein rechtzeitiges Umschalten von „Bottom‑Up" auf „Top‑Down"
empfiehlt auch Adam Crescenzi, Berater bei der der amerikanische Index Group.
Denn nur so kann seiner Meinung nach das mehr experimentelle Vortasten in
konsistente Prinzipien umschlagen kann. Seine Sorge ist, dass mit dem reinen Bottom‑Up‑Verfahren
nur die bestehende Abteilungs‑Bürokratie abgearbeitet wird, aber nicht der in
den neunziger Jahren viel wichtigere Entscheidungsfindungsprozeß abgedeckt
wird, der ja unternehmensübergreifende Bedeutung hat.[10]
Die Plus‑Methode. Weil indes beide Verfahren eindeutige
Vorteile auf ihrer Seite haben, ist man im Rahmen einer Arbeitsgruppe der Benutzervereinigung
GUIDE, die das Thema Enterprise Modelling analysiert und
bewertet, zu der Überzeugung gekommen, sie miteinander zu kombinieren. Daraus
entstand ein bottom‑up plus‑Verfahren und eine top‑down‑plus‑Methode.
So kann man bei der bottom‑up‑plus‑Methode, wie Rhefus erläutert, „die Erstellung des
Fundaments beschleunigen, indem man neben dem Tagesgeschäft Basissysteme
modelliert (Kunde, Produkt, Anlage), deren Daten für viele Anwendungen von
Bedeutung sind." Und bei deren Gegenstück, dem top‑down‑plus‑Verfahren
wird zuerst ein Unternehmensdatenmodell entwickelt, deren Informationsobjekte
dann unentwegt mit Projektdatenmodellen abgeglichen wird. Auf diese Weise entsteht
am Ende ein unternehmensweites Datenmodell.
Datenmodellierung verlangt aber auch, dass die Autorität der
Datenverarbeitung gestärkt werden muss. Doch das gelingt nur, wenn sie sich in
Übereinstimmung mit der Unternehmens‑Vision befindet. Wie das geht, macht ein
Beispiel aus den USA deutlich. Bei der IDS Financial Services in Minneapolis,
einer 1984 von American Express übernommenen Versicherungsgesellschaft,
wird seit 1987 kein Projekt gestartet, „bevor nicht der Datenadministrator das Datenmodell für diese Anwendung kreiert hat,
das dann Eingang findet in die unternehmensweite Datenarchitektur",
berichtet der verantwortliche Manager Alan Bignall. Hintergrund dieser
Entscheidung war ein radikaler Strategiewechsel.
Der Finanzdienstleister hatte sich 1984 eine neue Vision
gegeben. Das Topmanagement beschloß, dass das Unternehmen nicht mehr versuchen
sollte, die beste Versicherung, sondern der beste Finanz‑ und Vermögensplaner
am US‑Markt zu sein. Das bedeutete, dass es seine Kunden nur dann optimal
bedienen konnte, wenn es über die beste Datenbasis verfügte. Und die war
verteilt über funktionale Datenhäfen wie VSAM, DL/1, uralte CICS‑gebundene
Assembler‑Dateien und modernes DB2. Eine Gruppe von 14 Datenmodellierern wurde 1984 aufgebaut, die bottom‑up
die Datenarchitektur schuf. „Das erste Datenmodell,
das wir schufen, war der `Kunde'. Denn wir sahen ihn als das Herzstück an. Es
stellte sich heraus, dass dies die richtige Vermutung war. Dann wechselten wir
über zum Marketing‑Modell und diese beiden paßten dann sehr gut zusammen."
Nach drei Jahren etwa stand dieser Kern. Doch so richtig komplett wird das
globale Datenmodell erst 1993 sein. Eine
lange Zeit, die viel Geduld von den Beteiligten abverlangt. Dennoch ‑ die
Anstrengung lohnt sich: „Solange sich unsere Vision nicht ändert, garantieren
wir dafür, dass sich die Architektur nicht ändern muss", erklärt IDS‑Manager
Bignall.[11]
Redundanz. Schon aus eigenem Antrieb heraus werfen deshalb die
höchsten Führungskräfte ein Auge auf das gestalterische Wirken im Bereich der Informatik. Denn: „Fast jeder Vorstand kann
eine Story darüber erzählen, was passiert, wenn er zu einem Thema konsolidierte
Zahlen haben möchte", berichtet Peter <$IPersonen; Kirn, Peter>Kirn,
Leiter Softwaremarketing bei der IBM Deutschland GmbH in Stuttgart. In manchem
Betrieb wurden schon fünf unterschiedliche Berichte erstellt, wenn zum Beispiel
ein Executive nach den Kosten pro Mitarbeiter verlangt ‑ nur weil es
unterschiedliche Auffassungen darüber gab, was ein Mitarbeiter ist.[12]
Hinzu kommt der Datensalat:
Funktional völlig mit den Anwendungen verquickt, werden Kirns Meinung
nach in vielen Unternehmen mehr als 50 Prozent der Daten redundant gehalten ‑
mit dem Problem, die Konsistenz dieser Informationen zu bewahren.
Das steigert zwar die
Plattenverkäufe der Hersteller, was angesichts sinkender Preise noch zu
verschmerzen wäre. Aber weitaus schwerwiegender ist, dass die
Entwicklungsarbeit mit einer kaum noch beherrschbaren Komplexität überfrachtet
wird, die durch den Wunsch nach Integration heterogener Systeme drastisch
verschärft wird.
„Den Preis bezahlen heute die
Entwickler, für die immer mehr Anwendungen immer weniger beherrschbar sind. Und
die Benutzer bekommen nicht die Anwendungen, die sie sich vorgestellt
haben", analysiert IBM Geschäftsführer Dorn. Radikales Umdenken
wird verlangt ‑ hin zu Investitionen, die keiner sieht...
[1] Fortune, 8.6.87, Louis S. Richman: „Software catches the team spirit“
[2] Financial Times, 30.4.87: „The case
for IT as a matter of life and death"
[3] Financial Times, 5.9.91, Robert
Mauthner: „Foreign Office is criticised for inadequate controls" >]
[4] Datamation, 1.2.90: „Updating U.S.
manufacturers bean counting" >]
[5] Financial Times, 19.10.92, Christpher Lorenz: „From feudalism to
federalism"
[6] The Economist, 15.10.91: „Reinventing
companies"
[7] Financial Times, 11.12.91, Alan Pike: „Benefits of a seven‑year
itch"
[9] Computerworld, 18.5.87, Amy Fiore: „It
hurt, but IDS built an architecture"
[10] The Economist, 15.10.91: „Reinventing companies"
Abonnieren
Posts (Atom)