Architektur und Architekturmanagement. Modellierung von Architekturen und Architekturmanagement in der Software- Organisation

Transkript

1 und management Modellierung von en und management in der Software- Organisation

2 und management Autor Malte Foegen Partner wibas GmbH Otto-Hesse-Str. 19B Darmstadt Tel wibas IT Maturity Services is official Partner of the Software Engineering Institute (SEI) of the Carnegie Mellon University for SCAMPI appraisals and CMMI training Zusammenfassung Zusammenfassung Stichworte Eine definiert die Grundstruktur eines DV-Systems. Sie ist damit einer der Schlüsselfaktoren für eine stabile, wartbare und funktionierende DV. Dieser Artikel umreißt den Begriff der und stellt deren Bedeutung in der Software-Entwicklung dar. Außerdem werden IT- und Unternehmens- gegeneinander abgegrenzt. Der Beitrag gibt eine Übersicht über die konkreten Arbeitsprodukte, mit denen eine definiert werden kann, und er zeigt die Aufgabe des -Managements in einer Organisation auf. DV-, Informationssystem-, Geschäftsarchitektur, management, Metaebene, Modellierung, Software- Engineering, Wartbarkeit 2 Version 1.1 Copyright 2005 wibas GmbH

3 Modellierung von en und management in der Software-Organisation Inhalt Sinn und Zweck von...4 Begriff der 4 Ziele einer 4 Einfluss der auf das System 4 Bedeutung der 5 Abgrenzung... 7 Geschäftsarchitektur und DV- 7 eines Systems und einer Systemfamilie 8 Arbeitsprodukte zur Beschreibung einer DV Funktionale und operationale Sicht 9 Arbeitsprodukte im Überblick 9 management Ziel und Definition des managements 12 Aufgaben des managements 12 Fazit

4 und management 1 Sinn und Zweck von 1.1 Begriff der definiert die Grund-Struktur eines Systems DV- umfasst Hardund Software, und sie kann ein System oder eine System- Familie spezifizieren In diesem Beitrag werden unter die Dinge verstanden, welche die (Grund-)Struktur eines Systems definieren. Mit Struktur sind dabei nicht nur die statischen Aspekte eines Systems wie z.b. Komponenten, ihre Schnittstellen und Beziehungen untereinander gemeint, sondern auch dynamische Aspekte wie etwa die Kommunikation zwischen den Komponenten. Eine wird aus einer Reihe von Sichten d.h. einzelnen Arbeitsprodukten beschrieben, die zusammen die definieren (zu en siehe [1], [2] und [3]). Eine DV-, wie wir Sie in diesem Artikel näher betrachten, beschreibt sowohl Hard- wie auch Software-Strukturen. Eine kann für nur ein System entworfen werden wie auch für eine ganze Systemfamilie (vgl. Abschnitt 2.2). 1.2 Ziele einer Ziel einer : Anforderungen erfüllen (utilitas), Robustheit (firmitas) und Kommunikation der Funktion durch die Form (venustas) Das Ziel einer ist es sicherzustellen, dass das spätere System die Anforderungen erfüllt (utilitas), robust gegenüber Änderungen ist (firmitas) und eine gewisse Schönheit besitzt (venustas). Mit Schönheit ist dabei gemeint, dass ein System seine Funktion durch seine Form kommuniziert. Diese allgemeine Definition von in der Encyclopaedia Britannica [4] ist auch für die Softwaretechnik unverändert gültig. Die Begriffe utilitas, firmitas und venustas fassen die drei wichtigsten Fragen zusammen, der sich eine täglich stellen muss: Wird das System damit die Anforderungen erfüllen? Wird es robust gegenüber möglichen Änderungen sein? Werden die Anwendungsentwickler die und die Anwender das System intuitiv nutzen können? 1.3 Einfluss der auf das System Eine bestimmt die Struktur eines Systems auf zwei Ebenen: sie legt Grundstrukturen fest und sie definiert Regeln, die bei der Entwicklung des Systems einzuhalten sind Eine bestimmt die Struktur eines Systems auf zwei Ebenen. Zum einen legt die das Modell des späteren Systems in einem gewissen Umfang fest und definiert damit die Gegenstandsebene, u.a. durch die Strukturierung des Systems in bestimmte Subsysteme und durch die Entwicklung von Basiskomponenten wie z.b. einer standardisierten Datenhaltungs-Zugriffschnittstelle (Persistenzframework). Zum anderen definiert sie Regeln, die bei der Entwicklung des Systems einzuhalten sind. Damit definiert sie die Metaebene 4 Version 1.1 Copyright 2005 wibas GmbH

5 Modellierung von en und management in der Software-Organisation der Entwicklung, z.b. durch Programmierrichtlinien oder Muster. Diesen Sachverhalt stellt Abbildung 1 näher dar. Modell der Metaebene Modell der Gegenstandsebene bereich Modellierungs- und Gestaltungsregeln keine rekursiv abhängigen Komponenten nicht ok ok wendet an Definition der Komponenten und ihrer Beziehungen (Grey Box) Definition und Implementierung der Basiskomponenten/ Frameworks (White Box) Anwendungsentwicklungsbereich wendet an Anwendung der Modellierungsregeln Spezialisierung Nutzung der Basiskomponenten (als Black Box) Die Anwendungsentwicklung darf die Grundstruktur des Systems (wie durch die definiert) nicht ändern, füllt sie aber weiter aus. Implementierung der Subsysteme (White Box) Abb. 1. Einfluss der auf die Anwendungsentwicklung (die Pfeile lehnen sich an die UML Notation an) 1.4 Bedeutung der Die eines Systems ist einer der zentralen Erfolgsfaktoren für den Projekterfolg. Die definiert die Basis eines Systems: mit ihr steht und fällt seine Qualität. Darüber hinaus wird mit einer erreicht, dass bewährte Lösungen nicht wiederholt neu erfunden werden müssen, dass Komponenten gewissen Strukturregeln folgen und sich in ein gemeinsames größeres Ganzes einfügen und in ihre IT-Umgebung passen (Interoperabilität, Integrierbarkeit, Austauschbarkeit). Schließlich spiegelt sich die Struktur des Systems bei größeren Entwicklungsteams in der Projektorganisation wider. Die kann gezielt das Projektmanagement unterstützen. Nicht zuletzt definiert die die technische Sprache des Projekts und sichert ein gemeinsames technisches Grundverständnis. Die bewusste Erstellung einer für eine ganze Familie von DV-Systemen ist für Unternehmen sinnvoll, die eine Reihe von Anwendungen miteinander interagieren lassen müssen, bzw. die auf einer Plattform eine Reihe von Anwendungen entwicklen. Eine für eine Systemfamilie ist nicht nur aus Synergiegründen sinn- ist einer der zentralen Erfolgsfaktoren für den Projekterfolg für eine Systemfamilie, um Synergien zu nutzen und Wartbarkeit sicherzustellen 5

6 und management voll, sondern für eine Wartbarkeit des Systems notwendig. Ohne eine einheitiche DV- entsteht ein System-Wildwuchs, der nicht nur teuer zu betreiben ist, sondern auch nur unter großem Aufwand weiterentwicklet werden kann. Eine Wiederverwendung von Lösungen und Ressourcen wird damit fast gänzlich unmöglich. Dadurch werden Unternehmen DV-technisch die Hände gebunden, und für das Geschäft benötigte Erweiterungen oder Änderungen können nicht oder nicht in einem akzeptablem Zeitraum durchgeführt werden. 6 Version 1.1 Copyright 2005 wibas GmbH

7 Modellierung von en und management in der Software-Organisation 2 Abgrenzung 2.1 Geschäftsarchitektur und DV- Der Begriff wird für eine Vielzahl von Systemen verwendet. Grundsätzlich können wir zwischen der von DV- Systemen (mit Hard- und Software) und sozialen Systemen (mit Organisationen, Prozessen und Ressourcen) unterscheiden zur Definition von DV- und Unternehmensarchitektur siehe auch [12]. Im Kontext der Entwicklung von DV-Systemen sind vier en von Bedeutung (siehe Abbildung 2): Die Geschäftsarchitektur (auch Unternehmensarchitektur genannt) legt die Grundstrukturen des Geschäfts durch die Definition von Geschäftszielen, Prozessen, Organisationsstrukturen und Ressourcen fest. Für die Erstellung von betrieblichen Informationsund Unterstützungssystemen ist sie eine zentrale Informationsquelle. Die Projektarchitektur definiert die Prozesse, Organisation und Ressourcen des Projekts. Sie ist Voraussetzung für das reibungslose Funktionieren des Projekts. Die Systemarchitektur definiert die Hard- und Software des zukünftigen technischen Systems (das zur Unterstützung der Abläufe im Geschäft beschrieben durch die Geschäftsarchitektur verwendet wird). Die Entwicklungsarchitektur definiert die Hard- und Software der Entwicklungsumgebung, also des Systems, mit dem das Zielsystem erstellt wird. Ggf. tritt hierzu noch die für das Testsystem. von DV-Systemen (mit Hard- und Software) und sozialen Systemen (mit Organisationen, Prozessen und Ressourcen) Organisiert und strukturiert das Geschäft Organisiert und strukturiert das EDV-System en für soziale Systeme definieren: Organisation Prozesse Ressourcen System- Entwicklungs- Unternehmens- Geschäfts- Projekt- en für technische Systeme definieren: Hardware Software Organisiert und strukturiert das Projekt Organisiert und strukturiert das Entwicklungs-EDV-System Abb. 2. Geschäfts-, Projekt-, System- und Entwicklungsarchitektur 7

8 und management Im folgenden geht der Artikel näher auf DV-en ein Die im folgenden vorgestellten Arbeitsprodukte dienen der Beschreibung der eines DV-Systems, d.h. sie können zur Definition der System- und Entwicklungsarchitektur verwendet werden (zur Modellierung der von sozialen Systemen siehe z.b. [7]). 2.2 eines Systems und einer Systemfamilie eines Systems versus einer Systemfamilie en für Systemfamilien können auch in mehreren Stufen aufeinander aufbauen Eine kann für ein System, aber auch für eine Systemfamilie entworfen werden. Während die eines Systems die Grundstrukturen für ein spezielles DV-System definiert, spezifiziert die einer Systemfamilie die Grundstrukturen für eine Familie von DV-Systemen und stellt sicher, dass die Systeme ein gemeinsames Ganzes ergeben. Die en der einzelnen Systeme bauen auf die der Systemfamilie auf. Die für ein System liegt in der Verantwortung des für das System verantwortlichen Projektteams. Die der Systemfamilie ist hingegen eine projektübergreifende Aufgabe. Das Management der en wird im Abschnitt 4 näher betrachtet. en für Systemfamilien können in mehreren aufeinander aufbauenden Schichten erstellt werden. So kann sich z.b. eine für Internetanwendungen auf die allgemeine DV- im Unternehmen stützen, die wiederum auf allgemeine muster bzw. prinzipien aufbaut (siehe Abbildung 3). Systemfamilie 1 System 1 System n... des Systems der Systemfamilie... Unternehmensweite Systemarchitektur... allgemein anerkannte grundlagen Abb. 3. Beispiel für aufeinander aufbauende Schichten von en Gleiche Arten von Arbeitsprodukten für die eines Systems wie einer Systemfamilie Die im folgenden vorgestellten Arten von Arbeitsprodukte zur Definition einer DV- werden sowohl für die eines Systems wie für die einer Systemfamilie verwendet. Je nach Verwendung unterscheiden sich die Arbeitsprodukte jedoch in der Breite und Tiefe. 8 Version 1.1 Copyright 2005 wibas GmbH

9 Modellierung von en und management in der Software-Organisation 3 Arbeitsprodukte zur Beschreibung einer DV- 3.1 Funktionale und operationale Sicht Die beiden zentralen Teile einer eines DV-Systems sind die softwaretechnische und die Infrastrukturarchitektur. Die Infrastrukturarchitektur erfasst die holistische, operationale Sicht auf das System. Hierzu zählen unter anderem das technische System (mit Hardware, Plattformen, Lokationen, Verbindungen), die Platzierung der Softwarekomponenten in Rahmen des technischen Systems, die Konfiguration und das Management des Systems (Kapazitätsplanung, Softwareverteilung, Datensicherung und Wiederanlauf). Die softwaretechnische erfasst die Softwarekomponenten, die auf den Hardwarekomponenten ausgeführt werden, d.h. die funktionale Sicht auf das System. Hierzu gehören unter anderem die Struktur und Aufteilung der Softwarekomponenten, die Schnittstellen der Komponenten, die Beziehungen zwischen den Komponenten und die Zusammenarbeit der Komponenten miteinander. Software- und Infrastrukturarchitektur Infrastrukturarchitektur ist operationale Sicht Softwaretechnische ist funktionale Sicht 3.2 Arbeitsprodukte im Überblick Abbildung 4 stellt die Arbeitsprodukte im Überblick dar, die in den Bereich der Systemarchitektur fallen. Arbeitsprodukte definieren die fassbaren (Zwischen-)Ergebnisse, d.h. was für eine getan werden muss unabhängig vom zeitlichen wann. Die Auswahl dieser Arbeitsprodukte zur Definition einer beruht auf den praktischen Erfahrungen, die wir in vielen Projekten gemacht haben und die sich in mehreren Schritten herauskristallisiert haben (siehe z.b. die Entwicklungsmethoden der IBM in [8], [9] und [10]). Eine ausführliche Darstellung der Arbeitsprodukte findet sich in [6] und [5]. Das in Abbildung 4 mit DV-System (Gegenstandsebene) bezeichnete Paket enthält die Elemente der, welche die Gegenstandsebene betreffen (zur Gegenstandsebene siehe Abbildung 1). Im Wesentlichen sind dies das Komponentenmodell (component model) der Softwaretechnischen und das Operationale Modell (operational model) der Infrastrukturarchitektur. Zum Komponentenmodell gehören auch komponenten, die der Anwendungsentwicklung zur Verfügung gestellt werden z.b. gekaufte Komponenten oder von der gruppe entwickelte (Framework-)Komponenten. Installationseinheiten (deployment units) Überblick über die Arbeitsprodukte zur Definition einer DV- Arbeitsprodukte zur Erfassung der des DV- Systems 9

10 und management sind Komponeten-Pakete, die auf den Knoten des Operationalen Modells platziert werden. Die zeitliche und organisatorische Lösung der Verteilung dieser Installationseinheiten zeigt der Verteilungs- Managementplan (software distribution plan). Die skizze (architecture overview diagram) entspricht dem mit Gegenstandsebene bezeichneten Paket in einem frühen Stadium. muster (architectural templates) stellen die Modellierungs- und Gestaltungsregeln auf der Metaebene dar, also Entwicklungsanleitungen zur Entwicklung der selbst sowie der einzelnen Anwendungssysteme; sie bilden zusammen mit dem inneren Paket Gegenstandsebene die des DV-Systems. Geschäftsarchitektur Organization Design Process Definition System Context Use Case Model Usability Requirements Non- Functional Requirements Anforderungen Change Cases Resource Definition Domain Model Current IT Environment Current IT Standards Reference Architecture Fit/Gap Analysis gesamter Systemarchitekturbereich Architecture Overview Diagram Systemarchitektur (Gegenstands- und Metaebene) Systemarchitektur (Gegenstandsebene) Service Level Characteristic Analysis Architectural Templates Component Model Softwaretechnische (Funktionale Aspekte) Deployment Units Operational Model Software Distribution Plan Infrastruktur- (Operationale Aspekte) Technical Prototype Viability Assessment Architectural Decisions Abb. 4. Arbeitsprodukte zur Definition einer DV-. Die Pfeile zwischen den Arbeitsprodukten (oder Paketen von Arbeitsprodukten) skizzieren die wichtigsten gegenseitigen Einflüsse. Anforderungen und Geschäftsarchitektur Eine muss insgesamt die Anforderungen erfüllen, die durch eine Reihe von Arbeitsprodukten im Paket Anforderungen festgehalten werden (utilitas). Die Anforderungen werden wiederum durch die Geschäftsarchitektur bestimmt, deren Prozesse durch die DV-Systeme unterstützt werden. 10 Version 1.1 Copyright 2005 wibas GmbH

11 Modellierung von en und management in der Software-Organisation Bei der Definition einer ist es sinnvoll, auf bewährte Konzepte zurückzugreifen die gezielte Auswahl von Referenzarchitekturen ist daher ein eigenes Arbeitsprodukt (reference architecture fit/gap analysis). Schließlich muss eine überprüft werden. Einzelne Fragestellungen können ggf. durch Prototypen beantwortet werden. Darüber hinaus ist eine Überprüfung der notwendig hinsichtlich der Erfüllung der qualitativen und quantitativen nichtfunktionalen Anforderungen (service level characteristic analysis), wie auch gegenüber den Anforderungen insgesamt (viability assessment). Nicht alle hier kurz dargestellten Arbeitsprodukte sind immer notwendig, und nicht jedes Arbeitsprodukt muss ein eigenes Dokument darstellen. Die Auswahl der für ein bestimmtes Projekt notwendigen Arbeitsprodukte, die Bestimmung der adäquaten Breite und Tiefe der Bearbeitung und ggf. die Zusammenfassung von Arbeitsprodukten zu einem Dokument ist einer der wichtigsten Aufgaben des Architekten bei der Projektplanung. Dies gilt gleichermaßen für die Auswahl der notwendigen Arbeitsprodukte für die einer Systemfamilie. Referenzarchitekturen Überprüfung der Für eine konkrete müssen die notwendigen Arbeitsprodukte ausgewählt werden 11

12 4 management und management 4.1 Ziel und Definition des managements Unternehmen müssen ihre DV-Strukturen langfristig beherrschen, warten und weiterentwickeln, damit die Systeme die aktuellen Wertschöpfungsketten unterstützen und Kosten für Parallelentwicklungen in Projekten vermieden werden management entwickelt die, so dass die strategischen und fachlichen Anforderungen erfüllt werden Unternehmen müssen ihre DV-Strukturen langfristig beherrschen, warten und weiterentwickeln, damit die Systeme die jeweils aktuellen Wertschöpfungsketten unterstützen. Viele Unternehmen haben in der Vergangenheit festgestellt, dass sie miteinander verknüpfte Projekte nur unzureichend kontrollieren können und dass fachliche und technische Abhängigkeiten unklar sind. Letzteres kann bis zu dem Punkt gehen, dass geschäftliche Anforderungen und die durch die DV- Systeme gegebenen Möglichkeiten so weit auseinanderklaffen, dass Marktchancen nicht realisiert werden können. Dies verursacht Kosten für unzureichend unterstützte Geschäftsabläufe und Opportunitätskosten für nicht realisierte Produkte oder Marktchancen. Ein weiteres Problem ist, dass in Projekten Technologien oder Software-Komponenten doppelt entwickelt werden und dass für Anpassungen oder Schnittstellen ein hoher Entwicklungaufwand notwendig ist beides verursacht ebenfalls erhebliche Kosten. Um dieses Problem zu lösen ist ein management notwendig. Dieses entwickelt und pflegt die, so dass die strategischen und fachlichen Anforderungen kosten- und zeiteffizient erfüllt werden. Außerdem ist das management dafür verantwortlich, dass die im Unternehmen gelebt wird. Während Projekte und die Erstellung der systemspezifischen en zeitlich begrenzte Vorhaben sind, ist management eine dauerhafte Aufgabe. 4.2Aufgaben des managements Aufgaben des managements: Erstellung, Pflege und Weiterentwicklung der DV- Erstellung, Pflege und Weiterentwicklung der Geschäfts- Die obige Definition des managements zeigt die beiden zentralen Aufgaben auf (siehe Abbildung 5): Die DV- für die DV-Systeme des Unternehmens ( für eine Systemfamilie, siehe Abschnitt 2.2) muss erstellt, gepflegt und weiterentwickelt werden. Diese DV- definiert eine einheitliche Basis für die DV-Systeme des Unternehmens. Die Definition der DV- erfolgt mit Hilfe der in Abschnitt 3 dargestellten Arbeitsprodukte. Um die Entwicklung der DV-Systeme und des Unternehmens zu verknüpfen und Klarheit über fachliche und technische Zusammenhänge zu gewinnen, muss eine Geschäftsarchitektur des Unternehmens (siehe Abschnitt 2.1) erstellt, gepflegt und weiterentwickelt werden. Diese Geschäftsarchitektur definiert eine ein- 12 Version 1.1 Copyright 2005 wibas GmbH

13 Modellierung von en und management in der Software-Organisation heitliche Basis für die Art und Weise, wie das Unternehmen funktioniert. Theoretisch könnte die Entwicklung der Unternehmensarchitektur auch bei der Unternehmensführung angesiedelt werden. Die enge Verknüpfung der DV-Systeme und der Geschäftsarchitektur legt aber nahe, beide Aufgaben miteinander zu verbinden. Das Team muss interdisziplinär besetzt sein und Personen mit hohem fachlichen und Personen mit hohem technischen Know-How umfassen. Eine solche Bündelung der Aufgaben trägt auch der strategischen Bedeutung der DV-Systeme für den Unternehmenserfolg Rechnung. Die dauerhafte Aufgabe des managements sollte klar definiert sein, d.h. dessen Organisation, Prozesse und Ressourcen sollten festgelegt sein. Erstellung, Weiterentwicklung und Kommunikation der im Unternehmen wird durch die Prozesse beschrieben. Hierzu gehören auch Prozesse zum Testen der und Ausnahmeregelungen (z.b. Fehlerbehebung, Änderung von Anforderungen). Die Organisation mit Rollen und Verantwortlichkeiten macht die Zuständigkeiten und Kompetenzen im management klar und stellt dar, welche Organisationseinheiten eingebunden werden. Die Definition der Ressourcen legt fest, welche Arbeitsprodukte bzw. Ergebnisse vom management erstellt bzw. benötigt werden. Verbindung von fachlichem und technischem Wissen Definition des managements selbst Strategische Vorgaben Unternehmens-Vision, strategische Unternehmens-Ziele IT-Vision, strategische IT-Ziele Markttrends Wettbewerb management management-prozesse management-organisation (Rollen & Verantwortlichkeiten, Personen, Teamstruktur) management-ressourcen (Informationen, Arbeitsprodukte, Hard- und Software) Geschäfts- Prozesse Organisation (Rollen & Verantwortlichkeiten, Personen, Teamstruktur) Ressourcen (Informationen, Arbeitsprodukte, Hardund Software) DV- Operationales Modell (Hardware-, Middleware, Platzierung der Software) Funktionales Modell (Software-) muster Fachliche Anforderungen Technologische Rahmenbedingungen Existierende DV- Landschaft Neue Technologien Operationalisierung: Projekte Projekt-Organisationen Anwendungen und Anwendungssysteme Abb. 5. Aufgaben und Umfeld des managements (siehe hierzu auch [11]) 13

14 und management als Basis um strategische Ziele, fachliche Anforderungen, technologische Rahmenbedingungen und Projekte in Einklang zu bringen Voraussetzungen für den Erfolg eines managements Das management steht mit seiner Arbeit im täglichen Spannungsfeld zwischen den strategischen Zielen, den konkreten fachlichen Anforderungen, den technologischen Rahmenbedingungen und der in Form von Projekten realisierten Weiterentwicklung der DV-Systeme und Unternehmensstrukturen. Die dokumentierte DVund Geschäftsarchitektur ist hierbei die Basis, um im täglichen Geschäft eine langfristige Ausrichtung und um eine Grundlage für fachliche und technologische Entscheidungen zu haben. Für den Erfolg des managements ist eine langfristige Ausrichtung und eine Management-Unterstützung unabdingbare Voraussetzung. Darüber hinaus ist das Kow-How und die Akzeptanz der im team beteiligten Personen und die enge Verzahnung von Projekten und dem managementteam von hoher Bedeutung. Ebenso ist eine pragmatische und an den Notwendigkeiten der Projekte orientierte Herangehensweise erforderlich. So kann z.b. für ein kleines Unternehmen alleine schon eine bewusste Gestaltung einer systemübergreifenden durch personelle Kontinuität und eine explizite Formulierung von grundsätzen und -entscheidungen erreicht werden. Nicht zuletzt ist eine offene Kommunikation der Schlüssel für eine Akzeptanz. 14 Version 1.1 Copyright 2005 wibas GmbH

15 Modellierung von en und management in der Software-Organisation 5 Fazit Eine bestimmt die Struktur eines Systems. Die explizite Definition einer ist unerlässlich, um die Systemstruktur nicht dem Zufall zu überlassen, sondern um sie gezielt zu gestalten. Aufgabe einer ist es, die Grundlagen für ein System bzw. für eine unternehmensweite Systemfamilie so zu legen, dass es die Anforderungen erfüllt, robust gegenüber Änderungen und verständlich ist. Die in diesem Artikel vorgestellten Arbeitsprodukte sind geeignet, eine Systemarchitektur umfassend bis hinunter auf die Detailebene zu modellieren. Diese Arbeitsprodukte werden von Architekten erstellt und müssen von den Anwendungsentwicklern als Nutzer der verstanden werden. Für ein konkretes Projekt ist es meist nicht erforderlich, alle vorgestellten Arbeitsprodukte als jeweils einzelne Dokumente zu erstellen, aber das Komponentenmodell, das Operationale Modell und die muster sollten auf keinen Fall fehlen. Um die Weiterentwicklung des Unternehmens und die der DV- Systeme miteinander zu verknüpfen und langfristig ausrichten zu können, ist ein management sinnvoll. Dessen Aufgabe ist es, die DV- und die Geschäftsarchitektur zu definieren, zu integrieren und weiterzuentwickeln. Zentrale Bedeutung der Bedeutung des managements 15

16 und management Literaturverzeichnis 1. L. Bass, P. Clements, R. Kazman: Software Architecture in Practice, Addisson-Wesley Publishing Company, Reading, L. Bass, R. Kazman: Architecture-Based Development, Carnegie Mellon University, Software Engineering Institute, Technical Report CMU/SEI- 99-TR-007/ESC-TR , Pittsburgh, P. C. Clements, L. M. Northrop: Software Architecture: An Executive Overview, Carnegie Mellon University, Software Engineering Institute, Technical Report CMU/SEI-96-TR-003/ESC-TR , Pittsburgh, Encyclopaedia Britannica Inc. (Hrsg.): The New Encyclopaedia Britannica, Macropaedia, Volume1, Stichwort Architecture, Seiten: , Encyclopaedia Britannica Inc, Chicago, M. Foegen, J. Battenfeld: Die Rolle der in der Anwendungsentwicklung, Informatik Spektrum, Band 24, Seiten , Springer Verlag, Heidelberg, Download unter 6. M. Foegen, J. Battenfeld, P. Atamaniuk: Modellierung von en, in: T. Spitta, J. Borchers, H. M. Sneed (Hrsg.): Software Management 2002, Progress through Constancy, Seiten , Gesellschaft für Informatik, Bonn, Download unter 7. D. W. McDavid: A standard for business architecture description, IBM Systems Journal, Vol. 38, No. 1, Seiten 12ff, IBM, IBM, Developing Object Oriented Software, An Experience-Based Approach, Prentice Hall, Upper Saddle River, IBM: IBM Global Services Method 3.0, Familie von Vorgehensweisen für Serviceprojekte, IBM internes Dokument, Dokument-Nummer ZZ , R. Youngs, D. Redmond-Pyle, P. Spaas, and E. Kahan: A standard for architecture description, IBM Systems Journal, Vol. 38, No. 1, Seiten 32ff, IBM, M. Werres: Enterprise Architecture Management The IBM Approach, Vortrag für den GI Arbeitskreis Enterprise Architecture, akea.iwi.unisg.ch, K. Hildebrand: Informationsmanagement Wettbewerbsorientierte Informationsverarbeitung mit Standard-Software und Internet, R. Oldenbourg Verlag, München, Version 1.1 Copyright 2005 wibas GmbH

17 Modellierung von en und management in der Software-Organisation Trademarks and Service Marks Capability Maturity Model; Capability Maturity Modeling; Carnegie Mellon; CMM; and CMMI are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University IDEAL; Personal Software Process; PSP; SCAMPI; SCAMPI Lead Assessor; SCAMPI Lead Appraiser; SEI; SEPG; Team Software Process; and TSP are service marks of Carnegie Mellon University IT Maturity Services is a registered trademark by wibas IT Maturity Services GmbH 17

18 IT Maturity Services IT Maturity Services und das wibas Logo sind eingetragende Marken. Copyright 2004 wibas GmbH. Aufeinander abgestimmte Services zur Verbesserung der Fähigkeiten Ihrer Anwendungsentwicklung Management des Software-Risikos Möchten Sie die Fähigkeiten Ihrer Anwendungsentwicklung maximieren? Suchen Sie Unterstützung bei der professionellen Durchführung Ihrer Projekte? wibas bietet Ihnen aufeinander abgestimmten Services, mit denen wir Sie bei der erfolgreichen Projektdurchführung und bei einem erfolgreichen Management der Software-Risiken in Ihrer Organisation unterstützen. Wir setzen Projekte mit Ihnen in einer Woche systematisch auf unterstützen Projekte durch intensive Mitarbeit führen für Sie zugeschnittene Schulungen durch führen Reviews Ihrer Projekte oder Ihrer Zulieferer durch verbessern die Fähigkeiten Ihrer Anwendungsentwicklung und bringen Ihre Software-Organisation zur CMM/CMMI oder SPICE Zertifizierung Bei allen Leistungen kombiniert wibas Projekt-Management- und Software- Engineering-Kenntnisse. wibas bietet Ihnen ein Set von bewährten Lösungsmustern zur Planung und Durchführung von Projekten. Wir arbeiten aktiv in Projekten und bei der Verbesserung der Software- Organisation mit. ProjectExpress Aufsetzen eines Projekts mit Ergebnissen, Rollen und Plänen innerhalb einer Woche ProjectExperts Fachleute, die in Ihrem Projekt mitarbeiten und dabei die kritischen Erfolgsfaktoren im Blick haben IT Encape Verbesserung des Software Engineerings im Unternehmen bis hin zur Zertifizierung nach CMM und ISO Normen ProjectVista Analyse von Projekten und Aufzeigen von Maßnahmen um einen Projekterfolg sicherzustellen IT MasterClass Ausbildung und Weiterentwicklung von IT Fachkräften im Bereich des Software Engineerings wibas IT Maturity Services GmbH Otto-Hesse-Str. 19 B Darmstadt Tel: Fax: