Der Begriff Informationssystem-Architektur in einer ... · ISA-Konzepts wird im Schrifttum bemerkt, jedoch kaum vertiefend themati-siert. Zachman äußert beispielsweise, ... Kommunikation.“

Der Begriff Informationssystem-Architektur in einer Untersuchung zu supra-adaptiven

Logistiksystemen

Gefördert durch die

Autoren: Felix Müller

Menno Hooites Meursing

Lehrstuhl für Controlling und Logistik

Universität Regensburg

Universitätsstraße 31

D-93053 Regensburg

© ForLog – Bayerischer Forschungsverbund Supra-adaptive Logistiksysteme

Regensburg, München, Erlangen-Nürnberg 2006

Alle Rechte vorbehalten. Insbesondere ist die Überführung in maschinen-lesbare Form sowie das Speichern in Informationssystemen auch auszugsweise nur mit schriftlicher Genehmigung von ForLog gestattet.

Inhaltsverzeichnis

I

Inhaltsverzeichnis

1 Hintergrund 1

2 Klärungsbedarf 2

3 Abgrenzung von Informationssystem- Architektur 5 3.1 Abgrenzung von Begriffen mit kleinerem

Bezugsobjekt 5 3.1.1 Software-Architektur 5 3.2 Abgrenzung von Begriffen mit größerem

Bezugsobjekt 7 3.3 Implikationen aus der Abgrenzung nach dem

Bezugsobjekt 8

4 Klassifizierung von ISA-Begriffen 9 4.1 Unterscheidung nach Systemumfang 12 4.2 Unterscheidung nach Architekturumfang 14 4.2.1 ISA als Beschreibung eines Informationssystems 14 4.2.2 ISA als Vorgehensmodell zur Gestaltung eines IS 15 4.2.3 ISA als Ergebnis der Planung eines IS 16

5 Problemspezifische Abgrenzung des ISA-Begriffs 19

6 Zusammenfassung und Ausblick 24

7 Literatur 25

Executive Summary

1

1 Hintergrund Im Rahmen des Forschungsverbunds „Supra-adaptive Logistiksysteme“ (ForLog) soll unter anderem untersucht werden, wie die Informationssys-tem-Architektur (ISA) von Akteuren in der Automobilindustrie, d. h. Herstel-lern, (1st-Tier-) Zulieferunternehmen sowie Logistikdienstleistern, beschaf-fen sein sollte, um Supra-Adaptivität1 zu ermöglichen.

Zu diesem Zweck wurden Anpassungsbedarfe in Zusammenarbeit mit be-teiligten Industrieunternehmen identifiziert. In einem nächsten Schritt wurde über Experten-Interviews erhoben, mit welchen sog. Anpassungsstrategien Unternehmen auf diese Bedarfe reagieren bzw. reagieren sollten. Eine durch eine Umfrage gestützte Auswahl wurde schließlich in weiteren Inter-views und Workshops in Form von Anwendungsfällen und prototypischen Prozessen beschrieben.

Um eine Bewertung verschiedener ISA-Alternativen, die für die Realisie-rung dieser Anpassungsstrategien zur Verfügung stehen, durchführen und damit normative Aussagen treffen zu können, sind verschiedene ISA-Ausprägungen zu unterscheiden. Es ist dafür zu klären, was unter dem Begriff ISA verstanden wird und welches Begriffsverständnis für das weite-re Vorgehen sinnvollerweise zu Grunde gelegt werden sollte. Die Bearbei-tung dieser Fragen ist Gegenstand der vorliegenden Arbeit. Unberücksich-tigt bleibt zunächst die Anpassungsfähigkeit des Informationssystems selbst.

1 „Ein System ist dann adaptiv, wenn sich Systemeigenschaften an die Benutzer oder eine veränderte externe Situation effizient anpassen lassen. Supra-Adaptivität liegt dann vor, wenn die Anpassung über Unternehmensgrenzen hinweg durchgeführt wird, so dass das gesamte Netzwerk eine effiziente Anpassung vornimmt.“[Baye05, 12]

Klärungsbedarf

2

2 Klärungsbedarf Das Wort Informationssystem-Architektur (engl. information systems archi-tecture) wird nicht einheitlich verwendet. Das Fehlen eines einheitlichen ISA-Konzepts wird im Schrifttum bemerkt, jedoch kaum vertiefend themati-siert. Zachman äußert beispielsweise, dass insbesondere Unklarheit über den Wortbestandteil „Architektur“ herrsche und bezweifelt, dass sich in der Praxis ein gemeinsames Begriffsverständnis durchsetzen werde [Zach87, 277], der Begriff (ISA) somit zu einer bedeutungslosen Hülle zu verfallen drohe.2 Jedoch unterliegt auch die Abgrenzung des Objekts, auf das sich die Architektur bezieht – des Informationssystems also – unter-schiedlichen Vorstellungen: Beispielsweise beinhaltet das Krcmar’sche ISA-Kreiselmodell Elemente der Geschäftsstrategie [Krcm90], während sich andere Darstellungen auf die DV-technische Umsetzung betrieblicher Informationsverarbeitungsbedarfe konzentrieren.

Die Aussagen über ISA sind somit nicht universell gültig: Wird beispiels-weise festgestellt, dass eine ISA Grundlage für Planung und Priorisierung der Entwicklung von Datenbanken und Anwendungssystemen sei, da mit ihrer Hilfe bestimmt werden könne, welche Informationsbedarfe aktuell befriedigt und welche für das Unternehmen besonders kritisch sind[KiEv94, 8], so trifft diese Aussage nur für ein Architekturkonzept zu, das eben diese Objekte (Informationsbedarfe, deren Bedeutung für die Zielerreichung eines Unternehmens sowie den aktuellen Stand der Befrie-digung dieser Bedarfe) oder zumindest Werkzeuge zu deren Ableitung beinhaltet. Wie die Eigenschaft „Kritikalität des Informationsbedarfs“ ermit-telt werden kann, ist z. B. im Zachman-Rahmenwerk nicht angegeben [Zach87].

2 „Unfortunately, among the proponents of information systems architecture, there seems to be little consistency in concepts or in specifications of ’architecture’, to the extent that the words ’information systems architecture’ are already losing their meaning!“[Zach87, 277]

Klärungsbedarf

3

Hildebrand stellt ein ISA-Metamodell vor, in dem er die Komponenten einer ISA benennt sowie Teilbereiche abgrenzt (z. B. „Informationssystemkern“ oder „DV-technische Architektur“) [Hild92, Hild93]. Diese Vereinigung be-stehender ISA-Konzepte stellt zwar eine umfassende Gesamtschau dar und erleichtert den Zugang zum Thema, erschwert jedoch eine Operationa-lisierung des Begriffs, da die verwendete Definition entsprechend weit ge-fasst ist: „Die Informationssystem-Architektur ist die informationsbezogene Darstellung eines Unternehmens, die von den Unternehmenszielen bis zur technischen Basis reicht; im Mittelpunkt stehen Daten, Funktionen und Kommunikation.“ [Hild93, 75]

Erschwert wird die Begriffsbestimmung dadurch, dass für Teilbereiche ei-nes sehr umfangreichen ISA-Verständnis’ eigene Begriffe belegt sind, die inhaltlich jedoch mit einem weniger umfassenden ISA-Konzept überein-stimmen können. Ein Beispiel hierfür ist die Anwendungsarchitektur (AwA, engl. application architecture): Mertens definiert diese als „eine stark ver-dichtete Sicht auf die Anordnung von Vorgängen bzw. Prozessen und An-wendungssystemen“ [Mert04, 20].3 Im Gegensatz dazu umfasst ein „klassi-sches“ ISA-Verständnis bisweilen nur Daten und Abläu-fe[HaKa88, 206][Kari88, 8].

Das Begriffsverständnis wird in vielen Beiträgen nicht explizit dargelegt: Entweder es ist keine Definition angegeben oder diese ist sehr vage gehal-ten.4 In diesen Fällen wurde versucht, das zu Grunde gelegte ISA-Konzept aus dem restlichen Inhalt des Aufsatzes zu erschließen.

3 Hier Teil einer „Informationsarchitektur“, Begriff AwA ist jedoch auch als Teil von ISA belegt (z. B.[Krcm90, 399 f.]). 4 Z. B.[DiWe85, 122]: „the term ’information systems architecture’ refers to the overall structu-re of the information system“ oder[Hild01]: „[Die Informationssystemarchitektur] beschreibt und enthält die Gestaltungsvariablen und wird für die Analyse und Konzeption der Informationssys-teme genutzt“.

Klärungsbedarf

4

Earl führt die Begriffsverwirrung darauf zurück, dass das Wort „Architektur“ zunächst in der Praxis weite Verbreitung gefunden hat und von Herstellern und Beratern für viele Probleme in proprietärer Weise gebraucht wurde [Earl89, 97]. Als Beispiel sei auf die von der IBM Corporation im Rahmen des Business Systems Planning (BSP) vermarktete „information architectu-re“ verwiesen (s. bspw. [IBM 84, 39–45]).

Abgrenzung von Informationssystem-Architektur

5

3 Abgrenzung von Informationssystem- Architektur

Um den Geltungsbereich des ISA-Begriffs einzuschränken, soll in diesem Abschnitt dargestellt werden, welche vermeintlich angrenzenden Phäno-mene dem Schrifttum nach definitiv nicht Gegenstand einer ISA sind.

Den weiteren Ausführungen liegt folgende Arbeitsdefinition für ISA zu Grunde, die aus einer Zusammenfassung verschiedener Definitionen ge-bildet wurde: Eine ISA ist ein Plan eines Informationssystems, in dem In-formationsverarbeitungsbedarfe in einem Unternehmen und IuK-Systeme, die diese befriedigen und Kommunikationsbeziehungen miteinander unter-halten, abgebildet sind.

3.1 Abgrenzung von Begriffen mit kleinerem Bezugsobjekt

3.1.1 Software-Architektur

Zwar lässt sich auch für den Bereich Software-Architektur (engl. software architecture) feststellen, dass eine konkrete, allgemein anerkannte Definiti-on nicht existiert5 , dennoch lässt sich dieser Begriff von der ISA mit dem Hinweis auf das Bezugsobjekt der Architektur intuitiv abgrenzen: In einer ISA wird Software als ein abstraktes Bündel aus Programmen und Daten betrachtet, während Software-Architektur sich mit der (Mikro-) Struktur dieser Pakete beschäftigt. Problematisch für eine genauere Abgrenzung ist die mangelnde Präzision vorhandener Software-Architektur-Definitionen. So definieren bspw. Garlan und Perry Software-Architektur als „the struc-ture of the components of a program/system, their interrelationships, and principles and guidelines governing their design and evolution over time“ [GaPe95]. Ohne eine weitere Angabe der Systemgrenzen bzw. eine Spezi-fikation der Komponenten und deren Beziehungen untereinander ist diese 5 Vgl. hierzu die häufig aktualisierte und kommentierte Sammlung des Carnegie Mellon Soft-ware Engineering Institute[Carn06].


6

Begriffsbestimmung für viele Zwecke wenig hilfreich, da sie auf beliebig abstrakte Bezugsobjekte angewendet werden kann. Ein sehr generisches Begriffsverständnis liegt dem ANSI/IEEE 1471-2000-Standard zu Grunde, der zwar ursprünglich nicht auf Software-Architektur im Speziellen abstellt6 , allerdings in diesem Zusammenhang weite Verbreitung gefunden hat: „[architecture is] the fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution“.7 Diese sehr allgemein ge-haltene Definition erlaubt es den Autoren, den Geltungsbereich des Stan-dards entsprechend offen zu lassen; der Inhalt beschränkt sich auf die Vereinheitlichung der Sichten auf die Architektur eines Systems im weites-ten Sinne.

Es ist also schwierig, aus gängigen Definitionen allein das intuitive Ver-ständnis (s. o.) zu untermauern. Es ist deshalb erforderlich, den Hinter-grund des Begriffs zu untersuchen. Software-Architektur wird von frühen Autoren als ein neues Konzept im Rahmen des Software Engineering vor-gestellt [PeWo92, GaAO94]. Software Engineering beschäftigt sich mit der Anwendung wissenschaftlicher Methoden und Mathematik für den sinnvol-len Einsatz von Rechneranlagen mit Hilfe von Programmen, Abläufen und Dokumentation [Boeh79]. Es lässt sich also argumentieren, dass die Kom-ponenten, die in den Definitionen zur Software-Architektur genannt werden, als Teile eines Software-Produkts betrachtet werden können8 , wohinge-gen in den verbreiteten ISA-Definitionen vorrangig – im Rahmen der AwA (s. u.) – ein Ensemble aus mehreren Software-Produkten beschrieben wird. Eine Rechnerarchitektur (engl. computer architecture) beschreibt die Ei-

6 „software-intensive systems – any system in which software development and/or integration are dominant considerations“[MaEH02] 7 Zur Entwicklung dieses Begriffsverständnis’ vgl. auch[EIS+96]. 8 vgl. auch[PeWo92, 42 f.].


7

genschaften eines Hardware-Systems aus Anwendersicht [AmBF64]. An-wender sind in diesem Fall die Entwickler von Betriebssystem-Software. Zwar beinhalten einige ISA-Definitionen auch Hardware-Einheiten als Ele-mente (z. B. „Informationstechnikarchitektur“ [Mert04, 20]), jedoch wird die interne Struktur der Rechneranlagen i. d. R. nicht betrachtet (s. u.).

3.2 Abgrenzung von Begriffen mit größerem Bezugsobjekt Eine Abgrenzung zu angrenzenden Architekturbegriffen, die ein größeres Bezugsobjekt aufweisen, fällt schwerer als die zuvor behandelte Unter-scheidung. Dies liegt zum einen daran, dass weder für ISA noch für Kandi-daten, die es nach oben abzugrenzen gelten könnte, ein Kanon existiert, der die Elemente des jeweiligen Systems und deren Beziehungen jeweils genau spezifiziert. Zum anderen sind bestehende ISA-Begriffe bereits so umfassend, dass ein größerer Geltungsbereich innerhalb der Betriebswirt-schaftslehre kaum zu finden ist.

Ein Kandidat für eine Abgrenzung ist der Begriff „Unternehmensarchitektur“ (UA, engl. enterprise architecture), der neben dem Informationssystem auch andere Teile eines Unternehmens beinhalten könnte. Diese Unter-scheidung ist jedoch kaum möglich, da ISA und UA weitestgehend syn-onym verwendet werden. Zwar stellt Sinz fest, dass ISA und Anwendungs-system-Architektur Teile einer UA seien [Sinz04, 315], viele Beiträgen zu Unternehmensarchitekturen fokussieren jedoch ausschließlich auf die Ges-taltung des Informationssystems eines Unternehmens (z. B. [PeSo04, IyGo04, BrWi05, Pulk06]).9 Im Gegensatz dazu sind im Referenzmodell zu ISA von Hildebrand technische Zusammenhänge nicht Teil der Unterneh-mensarchitektur; diese setzt sich aus den Elementen „Geschäftsstrategie“,

9 In den Frequently Asked Questions zum „The Open Group Architecture Framework“ verweist ein Hyperlink mit dem Titel „Why do I need an IT architecture?“ auf einen Abschnitt, der mit „Why do I need an enterprise architecture?“ überschrieben ist[TOGA02].


8

„Prozesse“ und „Organisation“ zusammen [Hild92, 11]. Es lässt sich also feststellen, dass sich die Bezugsobjekte von ISA und UA überschneiden.

3.3 Implikationen aus der Abgrenzung nach dem Bezugsobjekt

Für die weitere Begriffsklärung kann festgehalten werden, dass die Be-trachtung der inneren Struktur technischer Systeme, genauer von Soft-ware-Produkten und Hardware, nicht Bestandteil einer ISA sind. Freilich lassen sich die Systemgrenzen eines Software-Produkts und damit die im Rahmen einer ISA „erlaubte“ Sicht nur schwer ermitteln; deshalb sei zu-nächst angenommen, dass es sich bei einer Menge von ausführbarem Code und Daten um ein Software-Produkt handle, wenn diese eine betrieb-liche Aufgabe zumindest teilweise erfüllt.

Die Abgrenzung zu dem vermeintlich umfassenderen Begriff UA ist ge-scheitert. Daher sind Aussagen, die sich auf UA beziehen, daraufhin zu prüfen, ob sie auch auf ISA anwendbar sein könnten.

Klassifizierung von ISA-Begriffen

9

4 Klassifizierung von ISA-Begriffen Wie im Abschnitt 2 bereits motiviert, finden sich im Schrifttum verschiedene Konzepte, die unter dem Wort ISA (engl. information systems architecture) firmieren. Teilweise werden andere Begriffe synonym verwendet, z. B. In-formationsarchitektur [Mert04, 20] oder IT-Architektur [Dern03]. Wall stellt fest, dass ISA – unabhängig vom Umfang des Systems – eine abstrahie-rende Funktion hat sowie auf strukturelle Merkmale des betrachteten Ob-jekts abzielt [Wall96, 29–30].

Eine grobe Verortung der Konzepte sowie verwendeter Termini ist in Abbil-dung 1 gegeben. Die Größe des Aufgabengebiets, also des Systems, auf das sich die Definition bezieht10 sowie der Umfang des Architekturver-ständnis’ dienen als Dimensionen. In einigen Fällen ist keine Einordnung möglich; diese werden deshalb in der Abbildung nicht aufgeführt.11 Diese Einteilung ist insofern hilfreich, als dass neben der Betrachtungsebene eines ISA-Konzepts auch der Anspruch, der dem Begriffsverständnis zu Grunde liegt, transparent wird.

10 Es werden nur Ausprägungen dargestellt, die für ISA oder einen verwandten Begriff belegt sind. 11 z. B. in Fällen, in denen die Definition der Architekturdimension das Bezugsob jekt be-schreibt: „In this paper, architecture is defined as any socio-technical system.“[BrWi05, 65]


10

Abbildung 1: Begriffsverständnis Informationssystem-Architektur


11

Hardw

are

Softw

are

RZ

Anw

endungen

Unternehm

en

Schicht

Rechner

Anw

endungssoft-w

are, B

etriebssys-tem

software,

Da-

tenbankverwal-

tungssoftware

Mitarbeiter, O

rgani-sationseinheiten, S

tellen

Aktivitäten, betrieb-

liche Aufgaben

Unternehm

en in

strategischen R

ol-len

Elem

ente

Kom

munikationseinrich-

tungen Anwendungen

Integrationsbeziehungen, A

bhängigkeiten

Organisation

Ablauflogik

Leistungsverflechtungen

Beziehungen

Dezentral

vs. Zentral,

Cluster vs. M

ainframe

EA

I-Problem

e, D

aten-haltung

IT-Abteilung

als S

tabs-abteilung

vs. R

ech-nungsw

esen unterstellt;

interner Aufbau

Gestaltung

betrieblicher A

bläufe

Unternehm

ensstrategie

Typische Problem

e

Tabelle 1: Charakterisierung der Ebenen betrachteter Systemmodelle


12

4.1 Unterscheidung nach Systemumfang Bei der Unterscheidung nach dem Umfang des IS, das Bezugsobjekt einer ISA ist, wurden Teilsysteme abgegrenzt, die Gegenstand eines ISA-Begriffs sein können. Die Unterteilung ist sinnvoll, da sich die betrachteten Konzepte dieser unterwerfen lassen und da eine zusätzliche Ebene keinen Beitrag zur Begriffsklärung leisten würde. Wall unterscheidet drei IS-Konzepte in ihrer ISA-Begriffsbildung [Wall96, 25]: IS als technisches Sys-tem, IS als sozio-technisches System, das z. B. das Personal in einem Re-chenzentrum beinhaltet, sowie IS als sozio-technisches System, das zu-sätzlich die Anwender umfasst. Da viele ISA-Konzeptionen jedoch explizit nur Teile der jeweiligen Systeme erwähnen, soll hier weiter differenziert werden, um Unterschiede besser erkennen zu können. Das Zachman-Framework sieht eine feinere Gliederung vor: Insbesondere dort, wo sich Schnittstellen zur Softwareentwicklung ergeben, werden zusätzliche Ebe-nen unterschieden („Technology Model“, „Components“) [Zach87]. Verbrei-tete ISA-Definitionen beschränken sich jedoch auf eine Makrosicht auf das Informationssystem, in der die Struktur der Programme keine Berücksichti-gung findet. Für diesen umsetzungsnahen Bereich werden üblicherweise andere Begriffe verwendet.12 Eine kurze Charakterisierung der jeweiligen Gruppen ist in Tabelle 1 zusammengefasst. Die Anordnung der Gruppen in Schichten erfolgt intuitiv. Jede Schicht ist optionaler Bestandteil eines ISA-Begriffs; es gilt jedoch, dass höhere Schichten jeweils auf den direkt be-nachbarten niedrigeren Schichten aufbauen.

Die unterste Schicht beinhaltet Hardware-Elemente, also Computer sowie Peripheriegeräte und Kommunikationseinrichtungen (z. B. Ethernet-Verkabelung). Ein klassisches Problem in dieser Schicht ist die Entschei-dung über den Grad der Zentralisierung der Datenverarbeitung, also dar-

12 Z. B. „Software-Architektur“, s. o.


13

über, ob die benötigte Rechen- und Speicherkapazität konzentriert an we-nigen Orten oder „verteilt“ an mehreren Orten vorgehalten wird (vgl. z. B. [Kore87]). Diese Ebene wird in einigen ISA-Definitionen ausgeblendet; vielmehr sind vor allem in Verbindung mit der nächsthöheren Ebene ande-re Begriffe belegt (z. B. „DV-technische Architektur“ [Hild92], „IT architectu-re“ [ArFP04, 234], „IT infrastructure“ [Dunc95, 39 f.]). Allerdings kann die Architektur der Hardwareschicht – nicht im Sinne von Rechnerarchitektur, sondern als Beschreibung verschiedener Hardwaresysteme und deren Beziehungen untereinander – als eine Komponente der ISA aufgefasst werden [Wall96, Mert04].

Auf der zweiten Schicht befinden sich Softwaresysteme, die (auf dieser Ebene nicht weiter betrachtete) Funktionen ausführen und miteinander kommunizieren. Mitunter werden betriebliche Anwendungssysteme und Softwaresysteme, die anderen Zwecken dienen bzw. Infrastrukturaufgaben erfüllen – also eine Grundlage für gegenwärtige und zukünftige betriebliche Anwendungssystem darstellen, unterschieden [GePf04, SMFS02, MES+04, Dunc95]. Diese Ebene wird auch als IT-Architektur [Wint03] oder Enterprise information system architecture [Ande02] bezeichnet.

Die dritte Schicht des „Versorgungssystems“ [Wall96, 25] können Mitarbei-ter eines Unternehmens bilden, die dafür verantwortlich sind, die Funkti-onsfähigkeit des technischen Systems (Schichten 1 und 2) zu erhalten oder zu verbessern (in Abbildung 1 mit „RZ“ abgekürzt). Architekturüberle-gungen betreffen hier die Organisation der Informationsverarbeitung im Unternehmen (s. hierzu bspw. [MeKn98]).

Während die oben genannten Schichten ausschließlich auf die Informati-onsversorgung abzielen, stellen die Schichten 4 und 5 auf die Verwendung dieser Information im Unternehmen ab. Dabei können der konkrete Einsatz von Anwendungssoftware (Schicht 4) sowie weiter gehende betriebliche Zusammenhänge Gegenstand der ISA sein (Schicht 5). Innerhalb der vier-ten Schicht wird beschrieben, welche Funktionen Anwendungssoftware


14

bereit stellen sollte (vgl. „Aufgabenebene“ [FeSi01, 2–4]). Weitere Ele-mente, die zunächst nicht unmittelbar mit der computergestützten Informa-tionsverarbeitung zusammenhängen, sind in Schicht 5 zusammengefasst (vgl. UA [Hild92], „Geschäftsarchitektur“ [Wint03]).

4.2 Unterscheidung nach Architekturumfang Als zweites Merkmal zur Verortung existierender ISA-Begriffe lässt sich das zu Grunde gelegte Architekturverständnis verwenden. Die drei Klassen, die im folgenden betrachtet werden, unterscheiden sich im Anspruch, den die enthaltenen Konzepte zu erfüllen suchen: Während Beiträge aus der ersten Klasse darauf abstellen, Instrumente zur Beschreibung von IS zur Verfü-gung zu stellen, sind in der zweiten Kategorie Konzepte zusammengefasst, in denen ISA Teil eines Ablaufmodells zur strategischen IS-Planung ist. Schließlich werden Beiträge gruppiert, in denen ISA explizit als Ergebnis einer Gestaltungsprozesses beschrieben wird.

4.2.1 ISA als Beschreibung eines Informationssystems

Die Beiträge, die hier genannt werden, schränken die Anwendung einer ISA (für Analyse oder Gestaltung) nicht im Voraus ein. Gemeinsam ist ih-nen, dass in einer ISA bzw. einer Informationsarchitektur die (nicht not-wendigerweise vollständige) Beschreibung eines Informationssystems auf einem aggregierten Niveau festgehalten wird.

Strunz stellt zunächst fest, dass sich die Architektur eines IS aus einer Gesamtschau auf eine Menge von sog. Architekturmerkmalen ergebe, die je nach Analyse- oder Entwurfsziel andere Elemente enthalte. Dadurch erlaubt die Definition ein pragmatisches Vorgehen bei der Bewertung eines IS, indem für eine zu beurteilende Eigenschaft jeweils ein Katalog von zu prüfenden Merkmalen aufgestellt und bearbeitet wird [Stru90, 444]. Wall kritisiert die von Strunz formulierte Anforderung an die Auswahl der Archi-tektur, hinreichend für eine Unterscheidung betrachteter Informati-


15

onssysteme zu sein, da durch diesen Anspruch die abstrahierende Funkti-on einer Architektur verletzt würde [Wall96, 32].

Andersson, der auch Systeme beschreibt, die sich aus Softwarepaketen und deren Verbindungen untereinander zusammensetzen, verwendet für derartige Systemmodelle die Begriffe Enterprise Software System Infrastructure (ESSI) [AnJo00] und Enterprise Information System Archi-tecture (EISA) [Ande02].

4.2.2 ISA als Vorgehensmodell zur Gestaltung eines IS

Neben Definitionen, die – ohne eine bestimmte Anwendung vorwegzuneh-men – auf eine Architekturbeschreibung des (über-) betrieblichen IS abzie-len, existieren Ansätze, in denen ISA Bestandteil eines Vorgehensmodells zur Gestaltung eines IS ist. Ein Vorgehensmodell ist in diesem Zusammen-hang ein Ablaufmodell, das mindestens eine Aktivität zur IS-Planung, Werkzeuge bzw. Vorlagen oder Muster, die zu diesem Zweck eingesetzt werden, und ggfs. Artefakte beschreibt, die im Rahmen des Prozesses erstellt werden.

Wall motiviert die Berücksichtigung der Tätigkeit in ihrer Definition durch den Verweis auf die Etymologie des Architekturbegriffs [Wall96, 34] (darauf aufbauend [BeSc98, 2]). Ferner finden sich darin sog. Konstruktions-prinzipien, die dem Architekturprozess zu Grunde gelegt werden.13 Diese Konstruktionsprinzipien sind von Metamodellen zu unterscheiden, die zu erstellende Modelle spezifizieren (vgl. „Konstruktionsregeln“ [Sinz97, 2]), da letztgenannte sich eben auf die „Baupläne“ beziehen, während erstge-nannte den Herstellungsprozess leiten sollen.

13 „Die Architektur eines Informationssystems ist das Ergebnis der Planung der Struktur eines Informationssystems sowie die Tätigkeit zum Erreichen dieses Ergebnisses im Sinne eines Konstruktionsvorgangs auf der Basis begründeter Konstruktionsprinzipien.“[Wall96, 37]


16

Vail stellt ein Vorgehensmodell vor, dessen Anwendung einen sinnvollen Einsatz des Zachman-Frameworks erleichtern soll, in dem zwar unter-schiedliche Sichten auf ein Informationssystem aber keinerlei Anwen-dungshinweise beschrieben sind [Vail02]. Die Argumentation zielt darauf ab, die Abhängigkeiten zwischen wichtigen Stellgrößen14 im Unternehmen zu identifizieren und diese zu „Regionen“ zusammenzufassen, welche an-schließend auf Zellen im Zachman-Framework abgebildet werden. Die Definition zur UA beinhaltet explizit zentrale Abläufe zur Gestaltung und zum Einsatz von Unternehmensmodellen („busines and IT models of an enterprise“) [Vail02, 8].

Allen und Boynton beschreiben, wie sich Änderungen der Geschäftsstrate-gie bei dezentraler bzw. zentraler Organisation der strategischen IS-Planung auswirken; sie bezeichnen diese Modelle als „architektonische Lösungen“, wobei ISA definiert ist als „set of policies and rules that govern an organization’s actual and planned arrangement of computers, data, human resources, communication facilities, software, and management responsibilities“ [AlBo91, 435]. Während die Definition lediglich dynamische Komponenten beinhaltet, lässt der weitere Inhalt des Aufsatzes den Schluss zu, dass ISA auch Teil eines Vorgehensmodells ist.

4.2.3 ISA als Ergebnis der Planung eines IS

Im Unterschied zu den Beiträgen aus dem vorigen Abschnitt ist im Folgen-den nur das Ergebnis der Planung – also ein Artefakt als Resultat eines nicht weiter spezifizierten (strategischen IS-) Planungsprozesses – rele-vant. Diese Beiträge sind z. T. schwer abzugrenzen, da mitunter beide Klassen behandelt werden.15 Dieses Verständnis liegt den Ausführungen

14 „the enterprise’s high-leverage, actionable value-stream generating variables“[Vail02, 10]. 15 Z. B. „architecture (. . . ) stands for (. . . ) the design rules for developing and structuring the system“ und „architecture is thus the result of planning the structure.“[LeZe06, 1546]


17

von Hildebrandt zu Grunde, der eine ISA als Bezugsobjekt der „Strategi-schen Informationssystemplanung“ beschreibt [Hild01, 83,169–171]. ISA selbst beinhaltet also keinerlei Angaben zum Vorgehensmodell, das für ihre Erstellung verwendet wird (analog dazu [HaNe01, 194]).

Krcmar definiert ISA als „Generalbebauungsplan“, der bei der „sorgfälti-ge[n] Planung des gesamten Informationssystems des Unternehmens“ entsteht [Krcm90, 395] (analog [AiSc04, 44]) und betont die Bedeutung der Abstimmung verschiedener Elemente eines IS. Diese Idee wird in einigen Beiträgen aufgegriffen (z. B. „Softwarestadt“ [SiKu03, 26], „Anwendungs-landschaft“ [Dern03, 16]), allerdings wurde der Begriff ISA beibehalten und nicht z. B. durch „IS-Stadtplanung“ ersetzt. Ross argumentiert, dass diese Metapher zwar helfe, die technologische Perspektive auf die Anwenungs-landschaft darzustellen, jedoch keinen Beitrag dazu leiste, das strategische Potenzial einer Unternehmens-IT-Architektur festzuhalten [Ross03, 32].

Nach Hirschheim et al. ist ISA Gegenstand von IS-Planungsprozessen („IS Planning“) in einem Unternehmen, deren Aufgabe es ist, jene zu erstellen und zu warten [HiKL95, 106]. Die ISA dient in diesem Zusammenhang als Bezugsrahmen für künftige Anwendungssystementwicklung, in dem Infor-mationsverarbeitungsbedarfe und deren Beziehungen zu Funktionen und Organisationskomponenten im Unternehmen beschrieben werden.16 Ähn-lich beschreiben Dickson und Wetherbe eine ISA, deren Gestaltung sie zu den häufigsten Problemen im „MIS planning“ zählen [DiWe85]. Neben den eigentlichen Informationsver-arbeitungsbedarfen finden sich in beiden Dar-stellungen auch mögliche Realisierungen derer in Form von Softwaresys-temen („application portfolio“ [HiKL95, 106], „applications“ [DiWe85, 122]).

16 „An ISA is a high level map of the information needs of an organization relating them to the principal business functions and components of the organizational structure.“[HiKL95, 106]


18

Dern gliedert ISA in fünf hierarchisch angeordnete Ebenen und verwendet für deren Planung bzw. Ausgestaltung den Begriff „Architekturmanage-ment“ [Dern03, 32].

Problemspezifische Abgrenzung des ISA-Begriffs

19

5 Problemspezifische Abgrenzung des ISA-Begriffs Um ein für das weitere Vorgehen sinnvolles ISA-Verständnis auswählen zu können, müssen zunächst die Anforderung dargestellt werden, die der Begriff erfüllen muss.

Um schließlich konkrete Handlungsempfehlungen für Unternehmen zur Gestaltung ihrer ISA ableiten zu können, sollte der Begriff Aussagen über Softwaresysteme, deren Kommunikationsbeziehungen untereinander so-wie über deren Einsatz im Wertschöpfungsnetzwerk zulassen. Gerhäuser und Pflaum betrachten zusätzlich eine Hardwareschicht als Bestandteil einer logistischen Informationssystem-Architektur [GePf04]. Dies ist dann sinnvoll, wenn – wie im dort beschriebenen Fall für Radio Frequency Iden-tification (RFID) – die Auswirkungen des Einsatzes neuer technischer Sys-teme auf Materialflussebene auf Gestaltungsprinzipien dieser ISA unter-sucht werden sollen. Derartige Anwendungen sind im Rahmen der Anpas-sungsstrategien, die über Experten-Interviews im Laufe des For-schungsprojekts erhoben wurden, nicht genannt worden [Baye05]; es kann im folgenden also von einer abstrakten Hardware-Infrastruktur-Schicht ausgegangen werden, die ausreichend Rechen-, Speicher- und Kommuni-kationskapazität bereitstellt, um die Anwendungssysteme im Rahmen ihres Anforderungsprofils nutzen zu können. Diese Überlegung erfolgt analog zur Schnittstelle zwischen betrieblichen Anforderungen und deren Umsetzung in einer AwA: Die Anforderungen der höher gelegenen Ebene können mit allen architektonischen Mustern umgesetzt werden; welche Realisierung vorteilhaft ist, hängt von Kriterien ab, die der „Auftraggeber-Schicht“ nicht bekannt sind.

Da Empfehlungen für generische Anpassungsstrategien getroffen und nicht spezifische Anwendungslandschaften in einzelnen Unternehmen betrachtet werden sollen, muss der Begriff außerdem eine Typisierung erlauben: Dies ist umso schwieriger, je umfassender das Konzept ist. Deshalb ist es im vorliegenden Fall nicht sinnvoll, Unternehmensstrategien als Teil der Archi-


20

tektur zu betrachten. Zwar ließe sich unterstellen, dass diese einen ent-scheidenden Einfluss auf die Gestaltung (innerhalb) der ISA habe, doch nimmt die Erhebung der Anpassungsstrategien in Form von Anwen-dungsfällen bereits einen Teil der Deduktion „strategischer Gestaltungszie-le“ für die betrachteten Abläufe vorweg. Ferner ist es denkbar, dass die Organisation der Datenverarbeitung unabhängig von der jeweils verfolgten Anpassungsstrategie wirtschaftlich gestaltet wird; Überlegungen zu deren Ausprägung sollen deshalb zunächst ausgeblendet werden. Der Umfang des ISA-Bezugsobjekts ist somit auf Softwaresysteme und deren Einsatz in Unternehmen (Schichten 2 und 4) beschränkt. Dieser Bereich wird in ei-nigen Darstellungen mit dem Begriff „Anwendungsarchitektur“ belegt.17

Überbetriebliche Zusammenhänge sollen im Rahmen des Forschungspro-jekts nicht ausgeschlossen werden; deshalb darf ein betriebliches IS nicht als Subsystem eines Unternehmens abgegrenzt werden. Es gelte: Ein be-triebliches computergestütztes Informationssystem ist ein Teilsystem einer Menge von Unternehmen, in dem Information von menschlichen oder ma-schinellen Aufgabenträgern verarbeitet wird, um (über-) betriebliche Abläu-fe zu steuern. Ohne grundlegende Überlegungen zu den Einheiten wirt-schaftlichen Handelns und damit einhergehend zur korrespondierenden Systemabgrenzung anzustellen, lässt sich festhalten, dass eine solche Verwendung beispielsweise in Beiträgen zur Unternehmensmodellierung nicht unüblich ist (s. z. B. [FeSi95]), es lässt sich jedoch argumentieren, dass die Gliederung des ISA-Begriffs, wie sie oben vorgestellt wurde, damit hinfällig sei: Das Bezugsobjekt ist durch die neue Definition ein anderes als in den rezipierten Beiträgen. Insbesondere wenn der Anspruch vertreten wird, dass eine ISA dem Zweck diene, Unternehmensziele und -strategien ins Informationssystem zu übertragen, entsteht ein Konflikt dadurch, dass die Ziele und Strategien der betrachteten Unternehmen nicht zwangsläufig

17 Zur Definition s. Abschnitt 2.


21

kongruent sind. Erkenntnisse, die für den Planungsaspekt von ISA in einem Unternehmen gelten, lassen sich zudem nicht problemlos auf überbetriebli-che Koordination anwenden. Es gilt also, den Geltungsbereich und An-spruch des ISA-Begriffs auf Felder zu beschränken, in denen diese Ver-wendung des IS-Begriffs weniger problematisch ist. Wie gesehen, kann dies nur für die Beschreibungs-Perspektive auf den unteren Schichten be-hauptet werden, da andernfalls Ziele und Organisation zunächst differen-ziert behandelt werden müssten. Sind in der Anwendungsschicht jedoch Informationen über Unternehmenssphären enthalten („1-n betriebliche Auf-gaben sind einem Unternehmen zugeordnet“), so lassen sich mögliche Probleme auf den niedrigeren Schichten zumindest reduzieren. Es lassen sich immer noch Fälle konstruieren, in denen eine solche Betrachtung nicht zielführend ist: Beispielsweise könnten bestimmte Leistungen von einem ASP-Dienstleister erbracht werden, der auf der Ebene betrieblicher Aufga-ben gar nicht auftaucht.

Betrachtungen zum Vorgehensmodell innerhalb der ISA werden für das vorliegende Problem zunächst vernachlässigt, da derartige Vorgehensmo-delle unabhängig von den ermittelten Anpassungsstrategien in Unterneh-men installiert werden können. Wie im vorigen Absatz dargestellt, erscheint es nicht sinnvoll, den Architekturanspruch innerhalb des ISA-Verständnis für das weitere Vorgehen weiter einzuschränken: Für die anschließende Anwendung würde eine Beschränkung auf den Bereich Beschreibung ge-nügen. Andererseits ließe sich argumentieren, dass das Vorgehen, das hier für einen generischen Fall gewählt wird, in einen Plan mündet, da nor-mative Aussagen zur Gestaltung des IS getroffen werden. Für beide Fälle ist der Begriff AwA belegt [Mert04, Dern03], so dass auch der verfolgte Architekturumfang einer Verwendung dieses Begriffs nicht entgegensteht.

Der Begriff „Anwendungsarchitektur“ soll für die weitere Untersuchung als ein Strukturmodell eines Systems verstanden werden, das eine Menge von


22

(Anwendungs-) Softwaresystemen18 und betrieblichen Aufgaben als Ele-mente hat; Anwendungssysteme können für betriebliche Aufgaben einge-setzt werden und Integrationsbeziehungen mit anderen Anwendungssys-temen unterhalten. Dabei wird unter einem Anwendungssystem eine abge-schlossene Zusammenfassung von ausführbarem Code und Daten ver-standen, die dem Zweck dienen kann, mindestens eine betriebliche Aufga-be in einem Industriebetrieb oder Logistikdienstleistungsunternehmen zu erledigen. Dass dieses Begriffsverständnis bereits einen möglichen Einsatz beinhaltet, ist ein Manko, schließlich soll die Übertragung betrieblicher Auf-gaben gerade erst durch die Gestaltung der AwA erfolgen. Andererseits handelt es sich dabei wohl um ein theoretisches Problem, weil diejenigen Anwendungssysteme, die hier betrachtet werden, bereits von Anfang an dazu entwickelt werden, einen bestimmten betrieblichen Zweck zu erfüllen. Die Definition folgt somit dem Begriffsverständnis von AwA im Großen, also als „umfassende Beschreibung von Merkmalen der IV-Anwendungen eines Unternehmens in seiner Gesamtheit“ [Stru97, 35].19 Da Aussagen über Wertschöpfungsketten in der Automobilindustrie getroffen werden sollen, beinhaltet die Definition eine Einschränkung auf produzierende Unterneh-men sowie auf das Transportgewerbe. Die Instanzen der zweiten Soft-warekategorie, die in die Definition aufgenommen wird, realisieren Integra-tionsbeziehungen zwischen den Anwendungssystemen (vgl. „Kopplungs-Teilsystem-Funktionskomponente“ [MES+04, 28]). Die Begriffe Anwen-dungssystem-Architektur und Applikationsarchitektur werden z. T. synonym verwendet, wobei Anwendungssysteme bzw. Applikationen, die die Ele-mente des Bezugsystems bilden, als „aggregierte Zusammenfassung be-stimmter Funktionalitäten“ („[clusters of] business functions which can be

18 Im Folgenden als Anwendungssystem bezeichnet. 19 Allerdings entspricht dieses Verständnis nicht dem Vorschlag von Tulowitzki, nach dem Anwendungssystemarchitekturen bzw. Anwendungssystem-Architekturen als Zellen in einem modifizierten Zachman-Framework eine AwA konstituieren[Tulo91, 96].


23

supported by IT“ [ScSc05, 1334]) betrachtet werden, die in einem engen fachlichen Zusammenhang stehen [Wint06, ScWi05]. Diese Sicht korres-pondiert mit der AwS-Kernebene sowie der Funktionen-Ebene des Kopp-lungssystems in der OASYS20 -Systematik [MES+04].

Schließlich müssen sich die ermittelten ISA-Typen einer Beurteilung unter-werfen lassen, da schließlich pro Anpassungsstrategie herausgearbeitet werden soll, welche ISA sich am besten für die Umsetzung der Anforde-rungen, die aus jener abgeleitet werden, eignet. Hier könnte es insbe-sondere interessant sein, bestehende Erkenntnisse zur Beurteilung von Software-Architektur für „größere Zusammenhänge“ zu adaptieren (vgl. hierzu auch [AnJo00, Ande02]); es ist also darauf zu achten, dass die In-strumente, die für den Bereich Software-Architektur definiert sind, für ISA in gleicher Form anwendbar und gültig sind („Homomorphie“). Grundlage hierfür ist zunächst eine einheitliche Architekturbeschreibung. Für viele ISA-Teilgebiete stehen bereits Modellierungssprachen zur Verfügung, auf die zurückgegriffen werden kann (für einen Überblick s. [BeMS98], für An-wendungslandschaften im Speziellen s. z. B. „Softwarekartographie“ [LaMW05]).

20 Offene Anwendungssystem-Architekturen in überbetrieblichen Wertschöpfungsketten


24

6 Zusammenfassung und Ausblick Verschiedene ISA-Konzepte wurden nach Bezugsobjekt und Architektur-anspruch gruppiert. Anschließend wurde geprüft, welche Anforderungen der weitere Gang der Untersuchung an einen ISA-Begriff stellen würde. Schließlich konnte mit dem Begriff „Anwendungsarchitektur“ ein Begriff gefunden werden, der diese Anforderungen erfüllt und weniger missver-ständlich erscheint.

Vielversprechend erscheint die Berücksichtigung von Konstruktionsregeln, die charakteristisch für „Stilrichtungen“ in der Architektur von Informations-systemen sind (vgl. [Stru90, 444 f.]).21 Neben Konstruktionsregeln beinhal-ten derartige Stilrichtungen ein Vokabular an Anwendungssystemen und Integrationsbeziehungen, die als Stilelemente bezeichnet werden können. Im Rahmen eines Stils haben die beschriebenen Komponenten, Integrati-onsbeziehungen und Konstruktionsregeln zudem eine spezifische Seman-tik (vgl. für Software-Architektur [AbAG93, GaAO94]). Über solche Stilrich-tungen könnten die oben angesprochenen Typen abgebildet und einer Beurteilung zugeführt werden. Es ist jedoch zu prüfen, ob eine Beurteilung architektonischer Stile Rückschlüsse auf die zu erwartende Qualität der jeweiligen Instanzen erlaubt.

21 Beispielsweise könnte für eine Stilrichtung „Spezialisierte Individualsoftware mit Daten-drehscheibe“ eine derartige Regel festlegen, dass jedwede Kommunikation zwischen den Anwendungssystemen über den Softwarebaustein Datendrehscheibe abgewickelt wird.

Literatur

25

7 Literatur [AbAG93] Abowd, Gregory; Allen, Robert; Garlan, David:

Using style to understand descriptions of software architecture. In: ACM Software Engineering Notes 18 (1993) 5, S. 9–20.

[AiSc04] Aier, Stephan; Schönherr, Marten: Flexibilisierung von Organisations- und IT-Architekturen durch EAI. In: Aier, Stephan; Schönherr, Marten (Hrsg.): Enterprise Application Integration – Flexibilisie-rung komplexer Unternehmensarchitekturen. GI-TO-Verlag, Berlin 2004, S. 1–59.

[AlBo91] Allen, Brandt R.; Boynton, Andrew C.: Information Architecture – In Search of Efficient Flexibility. In: MIS Quarterly 15 (1991) 4, S. 435–445.

[AmBF64] Amdahl, Gene M.; Blaauw, Gerrit A.; Frederick P. Brooks, Jr.: Architecture of the IBM Sys-tem/360. In: IBM Journal of Research and De-velopment 8 (1964) 2, S. 87–101.

[Ande02] Andersson, Jonas: Enterprise Information Sys-tems Management: An Engineering Perspective Focusing on the Aspects of Time and Modifiabil-ity. Dissertation, Industrial Information and Con-trol Systems Department of Electrical Engneering, KTH, Royal Institute of Technology,Stockholm (Schweden),2002. http://urn.kb.se/resolve?urn=urn:nbn:se:kth:diva-3372.

[AnJo00] Andersson, Jonas; Johnson, Pontus: IT Infra-structure Architectures for Electric Utilities – A Comparative Analysis of Description Techniques. In: Proceedings of the 33rd Annual Hawaii Inter-national Conference on System Sciences 4-7 Jan. 2000. IEEE Computer Society, Los Alamitos (USA) 2000. cD-ROM edition.

Literatur

26

[ArFP04] Ardagna, Danilo; Francalanci, Chiara; Piuri, Vin-cenzo: Designing and Rightsizing the Information System Architecture. In: Information Systems Frontiers 6 (2004) 3, S. 229–243.

[Baye05] Bayerischer Forschungsverbund Supra-adaptive Logistiksysteme: Zwischenbericht. Techn. Ber., ForLog, München, 2005.

[BeMS98] Bernus, Peter; Mertins, Kai; Schmidt, Günter (Hrsg.):: Handbook on Architectures of Infor-mation Systems, Springer, Berlin 1998.

[BeSc98] Bernus, Peter; Schmidt, Günter: Architectures of Information Systems. In: Bernus, Peter; Mertins, Kai; Schmidt, Günter (Hrsg.): Handbook on Archi-tectures of Information Systems. Springer, Berlin 1998, S. 1–9.

[Boeh79] Boehm, Barry W.: Software engineering – as it is. In: Bauer, Friedrich L.; Stucki, Leon G.; Lehman, Meir M. (Hrsg.): Proceedings of the 4th interna-tional conference on Software engineering. IEEE, Piscataway (USA) 1979, S. 11–21.

[BrWi05] Braun, Christian; Winter, Robert: A Comprehen-sive Enterprise Architecture Metamodel and Its Implementation Using a Metamodeling Platform. In: Desel, Jörg; Frank, Ulrich (Hrsg.): Enterprise Modelling and Information Systems Architectures. Gesellschaft für Informatik, Bonn 2005, S. 64–79.

[Carn06] Carnegie Mellon Software Engineering Institute: How Do You Define Software Architecture? http://www.sei.cmu.edu/architec-ture/definitions.html, Abruf 2006-02-15.

[Dern03] Dern, Gernot: Management von IT-Architekturen, Vieweg, Wiesbaden 2003.

Literatur

27

[DiWe85] Dickson, Gary W.; Wetherbe, James C.: The Ma-nagement of Information Systems, McGraw-Hill, New York (USA) 1985.

[Dunc95] Duncan, Nancy Bogucki: Capturing Flexibility of Information Technology Infrastructure: A Study of Resource Characteristics and their Measure. In: Journal of Management Information Systems 12 (1995) 2, S. 37–57.

[Earl89] Earl, Michael J.: Management Strategies for In-formation Technology, Prentice Hall, Hampstead (UK) 1989.

[EIS+96] Ellis, Walter J.; II, Richard F. Hilliard; Saunders, Thomas F.; Poon, Peter T.; Rayford, David; Sher-lund, B.; Wade, Ronald L.: Toward a Re-commended Practice for Architectural Descrip-tion. In: Stoyenko, Alex (Hrsg.): 2nd IEEE In-ternational Conference on Engineering of Com-plex Computer Systems (ICECCS ’96), 21-25 Oc-tober 1996, Montreal, Canada. IEEE Computer Society, Los Alamitos (USA) 1996, S. 408–413.

[FeSi95] Ferstl, Otto K.; Sinz, Elmar J.: Der Ansatz des Semantischen Objektmodells (SOM) zur Mo-dellierung von Geschäftsprozessen. In: Wirt-schaftsinformatik 37 (1995) 3, S. 209–220. [Fe-Si01] Ferstl, Otto K.; Sinz, Elmar J.: Grundlagen der Wirtschaftsinformatik. 4. Aufl., Oldenbourg, Mün-chen 2001.

Literatur

28

[FSEI05] Ferstl, Otto K.; Sinz, Elmar J.; Eckert, Sven; Is-selhorst, Tilman (Hrsg.):: Wirtschaftsinformatik 2005: eEconomy, eGovernment, eSociety, 7. In-ternationale Tagung Wirtschaftsinformatik 2005, Bamberg, 23.2.2005 - 25.2.2005. Physica-Verlag, Heidelberg 2005, 2005.

[GaAO94] Garlan, David; Allen, Robert; Ockerbloom, John: Exploiting Style in Architectural Design Environ-ments. In: ACM Software Engineering Notes 19 (1994) 5, S. 175–188.

[GaPe95] Garlan, David; Perry, Dewayne E.: Introduction to the Special Issue on Software Architecture. In: IEEE Trans. Softw. Eng. 21 (1995) 4, S. 269–274.

[GePf04] Gerhäuser, Heinz; Pflaum, Alexander: RFID ver-ändert die Architektur logistischer Informati-onssysteme – Vom Identifikationsmedium zu selbststeuernden Transportobjekten. In: Prockl, Günter; Bauer, Angela; Pflaum, Alexander; Mül-ler-Steinfahrt, Ulrich (Hrsg.): Entwicklungspfade und Meilensteine moderner Logistik – Skizzen ei-ner Roadmap. Gabler, Wiesbaden 2004, S. 269–294.

[HaKa88] Hackathorn, Richard D.; Karimi, Jahangir: A Fra-mework for Comparing Information Engineering Methods. In: MIS Quarterly 12 (1988) 2, S. 202–220.

[HaNe01] Hansen, Hans Robert; Neumann, Gustaf : Wirt-schaftsinformatik I – Grundlagen betrieblicher In-formationsverarbeitung, Lucius & Lucius, Stuttgart 2001.

Literatur

29

[HiKL95] Hirschheim, Rudy; Klein, Heinz K.; Lyytinen, Kal-le: Information Systems Development and Data Modeling – Conceptual and Philosophical Foun-dations, Cambridge University Press, Cambridge (UK) 1995.

[Hild92] Hildebrand, Knut: Ein Referenzmodell für Infor-mationsssystem-Architekturen. In: Information Management 7 (1992) 3, S. 6–12.

[Hild93] Hildebrand, Knut: Zur Begriffsvielfalt bei Informa-tionssystem-Architekturen: Ein Vorschlag für eine einheitiche Terminologie. In: Reichel, Horst (Hrsg.): Informatik – Wirtschaft – Gesellschaft. Springer, Berlin 1993, S. 74–80.

[Hild01] Hildebrand, Knut: Informationsmanagement. 2. Aufl., Oldenbourg, München 2001.

[IBM 84] IBM (Hrsg.): Business Systems Planning – Infor-mation Systems Planning Guide (GE20-0527-4). 4. Aufl., IBM, Armonk (USA) 1984.

[IyGo04] Iyer, Bala; Gottlieb, Richard M.: The Four-Domain Architecture: An approach to support enterprise architecture. In: IBM Systems Journal 43 (2004) 3, S. 587–597.

[Kari88] Karimi, Jahangir: Strategic Planning for Informa-tion Systems: Requirements and Information En-gineering Methods. In: JMIS 4 (1988) 4, S. 5–24.

[KiEv94] Kim, Young-Gul; Everest, Gordon C.: Building an IS architecture – Collective wisdom from the field. In: Information & Management 26 (1994) 1, S. 1–11.

[Kore87] Koreimann, Dieter S.: Das Zusammenspiel von zentraler und dezentraler Datenverarbeitung, ex-pert, Sindelfingen 1987.

Literatur

30

[Krcm90] Krcmar, Helmut: Bedeutung und Ziele von Infor-mationsystem-Architekturen. In: Wirt-schaftsinformatik 32 (1990) 5, S. 395–402.

[LaMW05] Lankes, Josef; Matthes, Florian; Wittenburg, And-ré: Softwarekartographie: Systematische Darstel-lung von Anwendungslandschaften. In: Ferstl et al. [FSEI05], S. 1443–1462.

[LeZe06] Leist, Susanne; Zellner, Gregor: Evaluation of current architecture frameworks. In: Haddad, His-ham (Hrsg.): Proceedings of the 2006 ACM Sym-posium on Applied Computing (SAC). ACM Press, New York (USA) 2006, S. 1546–1553.

[MaEH02] Maier, Mark; Emery, Dave; Hilliard, Rich: IEEE Std 1471 Frequently Asked Questions (FAQ) Version 3.1. http://www.pithecanthro-pus.com/~awg/public_html/ieee-1471-faq.html, Abruf 2006-02-15.

[MeKn98] Mertens, Peter; Knolmayer, Gerhard: Organisa-tion der Informationsverarbeitung. 3. Aufl., Gabler, Wiesbaden 1998.

[Mert04] Mertens, Peter: Integrierte Informationsverarbei-tung, Bd. 1. 14. Aufl., Gabler, Wiesbaden 2004.

[MES+04] Mantel, Stephan; Eckert, Sven; Schissler, Martin; Schäffner, Claus; Ferstl, Otto K.; Sinz, Elmar J.: Eine Entwicklungsmethodik für die überbetriebli-che Integration von Anwendungssystemen. In: Bartmann, Dieter; Mertens, Peter; Sinz, Elmar J. (Hrsg.): Überbetriebliche Integration von Anwen-dungssystemen (FORWIN-Tagung 2004). Sha-ker, Aachen 2004, S. 21–39.

Literatur

31

[PeSo04] Pereira, Carla Marques; Sousa, Pedro: A method to define an Enterprise Architecture using the Zachman Framework. In: Haddad, Hisham; Omicini, Andrea; Wainwright, Roger L.; Liebrock, Lorie M. (Hrsg.): Proceedings of the 2004 ACM Symposium on Applied Computing (SAC), Nico-sia, Cyprus, March 14-17, 2004. ACM Press, New York (USA) 2004, S. 1366–1371.

[PeWo92] Perry, Dewayne E.; Wolf, Alexander L.: Founda-tions for the Study of Software Architecture. In: ACM Software Engineering Notes 17 (1992) 4, S. 40–51.

[Pulk06] Pulkkinen, Mirja: Systemic Management of Archi-tectural Decisions in Enterprise Architecture Planning. Four Dimensions and Three Abstraction Levels. In: Proceedings of the 39th Hawaii Inter-national International Conference on Systems Science. IEEE Computer Society, Los Alamitos (USA) 2006, S. 9 pages. cD-ROM edition.

[Ross03] Ross, Jeanne W.: Creating a Strategic IT Archi-tecture Competency: Learning in Stages. In: MIS Quarterly Executive 2 (2003) 1, S. 31–43.

[ScSc05] Schelp, Joachim; Schwinn, Alexander: Extending the Business Engineering Framework for Applica-tion Integration Purposes. In: Liebrock, Lorie M. (Hrsg.): SAC ’05: Proceedings of the 2005 ACM symposium on Applied computing. ACM Press, New York (USA) 2005, S. 1333–1337.

[ScWi05] Schwinn, Alexander; Winter, Robert: Entwicklung von Zielen und Messgrößen zur Steuerung der Applikationsintegration. In: Ferstl et al. [FSEI05], S. 587–606.

Literatur

32

[SiKu03] Siedersleben, Johannes; Kurpjuweit, Stephan: Systemübegreifende Software-Architektur: Er-fahrungen und Thesen. In: Sinz, Elmar J.; Plaha, Markus; Neckel, Peter (Hrsg.): Modellierung be-trieblicher Informationssysteme – MobIS 2003. Gesellschaft für Informatik, Bonn 2003, S. 25–29.

[Sinz97] Sinz, Elmar J.: Architektur betrieblicher Informa-tionssysteme. Techn. Ber. 40, Universität Bam-berg, 1997.

[Sinz04] Sinz, Elmar J.: Unternehmensarchitekturen in der Praxis – Architekturdesign am Reißbrett vs. situa-tionsbedingte Realisierung von Informati-onssystemen. In: Wirtschaftsinformatik 46 (2004) 4, S. 315–316.

[SMFS02] Schissler, Martin; Mantel, Stephan; Ferstl, Ot-to K.; Sinz, Elmar J.: Kopplungsarchitekturen zur überbetrieblichen Integration von Anwen-dungssystemen und ihre Realisierung mit SAP R/3. In: Wirtschaftsinformatik 44 (2002) 5, S. 459–468.

[Stru90] Strunz, Horst: Zur Begründung einer Lehre von der Architektur informationstechnikgestützter In-formations- und Kommunikationssysteme. In: Wirtschaftsinformatik 32 (1990) 5, S. 439–445.

[Stru97] Strunz, Horst: Anwendungsarchitektur. In: Mer-tens, Peter; Back, Andrea; Becker, Jörg; König, Wolfgang; Krallmann, Hermann; Rieger, Bodo; Scheer, August-Wilhelm; Seibt, Dietrich; Stahl-knecht, Peter; Strunz, Horst; Thome, Rainer; We-dekind, Hartmut (Hrsg.): Lexikon der Wirt-schaftsinformatik. Springer, Berlin 1997, S. 35–37. 3. Aufl.

Literatur

33

[TOGA02] The Open Group (Hrsg.): TOGAF – Frequently Asked Questions. http://www.opengroup.org/architecture/togaf8-doc/arch/p1/togaf_faq.htm, Abruf 2006-03-07.

[Tulo91] Tulowitzki, Ulrich: Anwendungssystemarchitektu-ren im strategischen Informationsmanagement. In: Wirtschaftsinformatik 33 (1991) 2, S. 94–99.

[Vail02] Vail, Edmund F. III: Causal Architecture: Bringing the Zachman Framework to Life. In: Information Systems Management 19 (2002) 3, S. 8–19.

[Wall96] Wall, Friederike: Organisation und betriebliche Informationssysteme, Gabler, Wiesbaden 1996

[Wint03] Winter, Robert: Modelle, Techniken und Werk-zeuge im Business Engineering. In: Business En-gineering – Auf dem Weg zum Unternehmen des Informationszeitalters. Springer, Berlin 2003, S. 87–118. 2. Aufl.

[Wint06] Winter, Robert: Ein Modell zur Visualisierung der Anwendungslandschaft als Grundlage der Infor-mationssystem-Architekturplanung. In: Schelp, Joachim; Winter, Robert (Hrsg.): Integ-rationsmanagement. Springer, Berlin 2006, S. 1–30.

[Zach87] Zachman, John A.: A framework for information systems architecture. In: IBM Systems Journal 26 (1987) 3, S. 276–292.

Documents

Der Begriff Informationssystem-Architektur in einer ... · ISA-Konzepts wird im Schrifttum bemerkt, jedoch kaum vertiefend themati-siert. Zachman äußert beispielsweise, ... Kommunikation.“