Methoden zur Kontextmodellierung (Quasar Enterprise)

Transkript

1 Fakultät für Informatik Lehrstuhl Software & Systems Engineering Methoden zur Kontextmodellierung (Quasar Enterprise) Tobias Weigl

2 Inhalt Vorwort: Quasar Enterprise und Kontextmodellierung Geschäftsarchitektur Erhebung der Anwendungslandschaften (AL) Erhebung der Ist- AL Festlegung der Ideal- AL und die Soll- AL Systematisches Design einer AL RE, QE und Environmental Sustainability Fazit zum Buch Quasar Enterprise und zu QE selbst Case Study: DriveNow Ein Car Sharing System

3 Vorwort Quasar Enterprise Ein von sd&m vorgeschlagener Baukasten zur Kontextmodellierung (Qualitätssoftwarearchitektur für betriebliche Informationssysteme) sd&m ist seit 25 Jahren erfolgreiches Softwarehaus und Beratungsunternehmen mit mehr als 1400 Mitarbeitern in München (Stand 2011) ging nun allerdings vollständig in Capgemini auf Focus auf Serviceorientierung: Serviceorientierte Vorgehensweise für serviceorientierte Anwendungslandschaften Enterprise orientiert, also für größere Unternehmen und Organisationen UML basierte Modellierung

4 Vorwort Einschub: Serviceorientierung was ist das? Begriff der SOA: Serviceorientierte Architektur Orientierung an Geschäftsprozessen denen beteiligte IT-Prozesse zugeordnet werden Einteilung in Domänen mit verschiedenen Komponenten Strukturierung und Definition von Verantwortlichkeiten Warum das? Betonung des Prozess- und Abstraktionsgedankens in der IT Stärkere Kapselung und klarere Struktur der Projektbestandteile Widerverwendungspotential, Flexibilität Bei geeigneter Umsetzung also: schnelle Reaktion auf veränderte Anforderungen ( Time to Market ), langfristig sinkende Kosten

5 Vorwort Betrachte Software nicht als hermetisch isoliertes System Einbettung in verflochtene Unternehmenslandschaften Sowohl im Zuge von Neuerstellung als auch bei Erweiterungen ist eine gesamtheitlichere Betrachtung und Erhebung notwendig (Scope) Daher: Kontextmodellierung + Anwendungslandschaften Flexibilität/Agilität Kosteneffizienz Nachhaltigkeit Hohe Qualität des Software-Systems im Sinne einer längerfristigen Investition Beherrschung der Komplexität

6 Geschäftsarchitektur [Quelle: Quasar Enterprise]

7 Geschäftsarchitektur [Quelle: Quasar Enterprise]

8 Geschäftsarchitektur - Fazit Kann extrem hohe Komplexität erreichen Ungewohntes Design, entspricht aber letztlich gutem RE, wie es auch an der TUM gelehrt wird: Anforderungen leiten sich aus Zielen ab Dies ist zu dokumentieren auf eine Art, die Nachverfolgung erlaubt in beide Richtungen Allerdings sieht QE hier keinen all zu detailierten Zielbaum vor und ist Methoden wie KAOS hierin damit unterlegen Aus der Geschäftsarchitektur werden wesentliche Elemente der Anwendungslandschaft abgeleitet

9 Erhebung der Anwendungslandschaften Erhebung des Ist-Zustands Verhinderung der Entstehung von Legacy Systemen Schaffung von Agilität durch Transparenz und Wohldefiniertheit?! QE Vorhandenes System Modellierter Ist-Zustand

10 Erhebung der Anwendungslandschaften Definieren des Ideal-Zustands Orientierung an langfristigen, strategischen Geschäftszielen Grundlage für den späteren Soll-Zustand ( Leuchtturm ) Überideale Zielvorgabe, ohne Bezugnahme auf den Ist-Zustand Parallele Erhebung Ist-Zustand Ideal-Zustand

11 Erhebung der Anwendungslandschaften Einführung des Soll-Zustands mit gesteuerter Evolution Schrittweise Umstellung vom Ist-Zustand Vor Umsetzung: Wirtschaftlichkeitsprüfung der idealen Vorgaben Das Erreichen kann viele Jahre dauern Ist-Zustand Ideal-Zustand als Roadmap Soll-Zustand

12 Erhebung der Ist-AL Ableitung aus der aktuellen Geschäftsarchitektur und der IT-Architektur Informationssystem-Architektur Technische Infrastruktur Suche nach den Experten und Architekten des Altsystems möglicherweise sind diese aber nicht (mehr) verfügbar! Die Erhebung kann dann schwierig und langwierig werden Das Ergebnis ist insbesondere wichtig, um zu entscheiden, welche (Alt-)Komponenten und Prozesse beibehalten werden und welche durch neue zu ersetzen sind!

13 Festlegung der Ideal-AL Ebenfalls Ableitung aus der Geschäftsarchitektur bzw. der Ideal-Geschäftsarchitektur Konzeptionell, logisch (d.h. nicht physisch) Die Soll-AL Tatsächlich angepeiltes Zwischenziel zwischen Ist und Ideal Hilfreich: Roadmap mit Planung der Schritte Aus den Geschäftszielen mit aktuell höchster Priorität wird ein Szenario, bzw. eine AL entworfen Ableitungssystem anhand der Zielpyramide Trockenste Folie des Vortrags!

14 Systematisches Design einer AL Wird benötigt für Ist-, Ideal- und Soll-AL Sind jeweils iterative Prozesse die mit den Methoden der QE modelliert werden Hierbei gilt die Hierarchie / Abfolge: Domänen Services Komponenten

15 Systematisches Design einer AL Zentrale Fragen Wie wird abgeleitet Woraus wird abgeleitet Wie wird verfeinert Feinere Granularität Geschäftsziele Geschäftsanforderungen Architekturleitlinien

16 Systematisches Design einer AL DOMÄNEN / Services / Komponenten Domänen gruppieren Komponenten nach fachlichen Gesichtspunkten. Identifizierung: Kerngeschäftsservices, Geschäftsobjekte Domänen sind die gröbste Gliederung der AL Zuteilung eines (hoch)qualifizierten Fachbereichsleiters Domänen sind an den Geschäftsprozessen orientiert Datenhaltung oder Java-Systeme sind schlecht gewählte Domänen warum?

17 Systematisches Design einer AL DOMÄNEN / Services / Komponenten Markt Kundenkontakt Beispiel-Modellierung Image Geschäftsdimensionen Produkte

18 Systematisches Design einer AL DOMÄNEN / Services / Komponenten Beispiel-Modellierung (Geschäftsdimension)

19 Systematisches Design einer AL DOMÄNEN / Services / Komponenten Services im Sinne von Anwendungsservices sind Prozesse, die mittels IT erbracht werden. Identifizierung: Aus Geschäftsservices Nicht alle Geschäftsservices sind IT-unterstützt Modellierung: Hierarchisch, mit Akteuren

20 Systematisches Design einer AL DOMÄNEN / Services / Komponenten Beispiel-Modellierung

21 Systematisches Design einer AL DOMÄNEN / Services / Komponenten Komponenten implementieren Services. Sie sind umfangreich und definieren sich über ihre Interfaces. Identifizierung: Services einer Domäne Komponenten sind mehr oder weniger stark mit unterschiedlichen weiteren Komponenten verflochten: Lose Kopplung Enge Kopplung QE macht hier im Detail Vorschläge zur Kategorisierung

22 Systematisches Design einer AL DOMÄNEN / Services / Komponenten Beispiel-Modellierung [Komponententyp nach QE; Hier: Zwei Bestands- und eine Interaktionskomponente]

23 Zusammenfassung: RE für Environmental Sustainability Aufgaben für den Requirements Engineer während der Kontextmodellierung: Identifizierung relevanter Stakeholder Verdeutlichung der Vorteile grüner, bzw. nachhaltiger Architekturentscheidungen ggü. Stakeholdern Geschickte Prozessmodellierung Geschickte Zielbaummodellierung Es ist für den Requirements Engineer ggf. nicht möglich, Nachhaltigkeit gegen den Willen der Stakeholder einzuführen. Auch ist Nachhaltigkeit nicht immer (vorrangiges) Ziel. Plausible Begründungen sind daher wichtig.

24 RE, QE und Environmental Sustainability Gezielte Nutzung des Ideal-AL Designs Einrichtung der Rolle eines Sustainability Engineer (?) Ausdehnung des Kontexts ( Stakeholder Scope ): Economical Sustainability Ergibt sich aus SOA Design Environmental Sustainability: Green IT, z.b.: Nutze Abwärme von Rechenzentren zur Gebäudeheizung Wähle Hardware nach Energieeffizienzrichtlinien Nutze Gebäudesteuertechnik für Energieeinsparung Green Business Processes :

25 RE, QE und Environmental Sustainability SOA Synergieeffekte für nachhaltigkeitsfokusiertes Design? Green Business Processes : Modelliere Prozesse umweltfreundlich und ressourcenschonend Beispiele: Ausdrucken von Dokumenten kann oft vermieden werden Kombiniere Versand von Dokumenten / Produkten Unnötiges Bereithalten von Ressourcen und Arbeitsgeräten, die für aktuelle Prozesse nicht benötigt werden viele mehr! Allgemein: Nutze Synergien und entwerfe Prozesse intelligent Aha-Effekt : Aspekte nachhaltiger Architektur stehen oft nicht im Widerspruch zu anderen Unternehmenszielen wie Kosteneinsparung!

26 RE, QE und Environmental Sustainability Social Sustainability: Grünbuch der Europäischen Kommission: Konzept, das den Unternehmen als Grundlage dient, auf freiwilliger Basis soziale Belange und Umweltbelange in ihre Unternehmenstätigkeit und in die Wechselbeziehungen mit den Stakeholdern zu integrieren. Schwierig mit primären Unternehmenszielen zu vereinbaren, mögliche Auflösung: Synergieeffekte mit Public Relations: Werbung, Markenbildung (PR: Tue Gutes und rede darüber )

27 Fazit zum Buch Quasar Enterprise und zu QE selbst Detailierte fiktive Case Study UML Baukasten-Elemente (Scheinbar) praxiserprobt Streckenweise unübersichtlich, Wichtiges oft zu knapp Strittige Reihenfolge der eingeführten Themen z.b. Geschäftsarchitektur nach Ist-Anwendungslandschaft Verfahren sind (voll angewendet) oft sehr komplex Beispiel: Einteilung von Komponenten Bestand-, Funktions-, Prozess- und Interaktions-K. Vorgehen zur kontrollierten Evolution zur Soll-AL sehr vage

28 Case Study

29 Case Study: Modellierung mit QE auf dem Whiteboard! 1. Gantt-Diagramm zur Planung 2. Geschäftsarchitektur 3. Ableitung von Ist-, Ideal- und Soll-AL 1. Domänen 2. Services 3. Komponenten 4. Roadmap zur Einführung der Soll-AL

30 Herzlichen Dank für die Aufmerksamkeit