Quasar Enterprise Anwendungslandschaften serviceorientiert gestalten

Transkript

1 Quasar Enterprise Anwendungslandschaften serviceorientiert gestalten Oliver Juwig Hamburg, November 2008

2 Capgemini sd&m steht für leistungsfähige Prozess- und Softwarelösungen, die die Wettbewerbsfähigkeit unserer Kunden erhöhen Kunden Unsere Kunden sind namhafte Unternehmen aller Branchen sowie öffentliche Institutionen, deren Erfolg von anspruchsvollen Prozessund Softwarelösungen abhängt Ihr Nutzen besteht in erhöhter Wettbewerbsfähigkeit durch Differenzierung bei unternehmenskritischen Lösungen Effizienzverbesserung bestehender Lösungen Leistungsangebot Prozess- und -Beratung Entwicklung individueller Softwarelösungen Implementierung und Roll-out von Standardsoftware Systemintegration Kompetenzen Umsetzungsorientierte Beratung Management komplexer -Projekte Software-Engineering Gestaltung anspruchsvoller -Architekturen Implementierung von SAP-Lösungen Rightshore TM Forschung & Innovation Partnerschaftliche Arbeitsweise Standorte Unternehmensentwicklung Hamburg Düsseldorf Köln/Bonn Frankfurt Walldorf Stuttgart Zürich Hannover Berlin München Standorte Capgemini sd&m Weitere Standorte der Capgemini-Gruppe Nearshore Wroclaw Farshore Mumbai Bangalore Plan SAP Business Solutions sd&m Capgemini sd&m 1 Anzahl Mitarbeiter im inkl. Polen und zugeordnetes Team Indien 2

3 Research entwickelt unsere Software-Engineering-Kompetenz kontinuierlich weiter und stellt Projekten aufbereitetes Wissen bereit Wir betreiben Innovationen zur systematischen Umsetzung unserer Vorstellung über die künftige Rolle der Projekte Studie - Trends Techno- Vision Ausbildung Schools für Entwickler, Architekten, Projektleiter Methoden Quasar 1 Enterprise Spezifikation Qualitätssteuerung epm 2 Kunde Partner RAIN 4 Innovation/Trends Web 2.0 Produktkennzahlen Client Architektur SOA Hochschul- Kooperationen Vorlesungen Publikationen Projekte Diplomarbeiten Communities Prozesse Portale Enterprise Integration Datenbanken Entwicklungsplattform Projektumgebung Komponenten auf Open-Source-Basis MDD 3 Forschungsprojekte Hochschulen Stiftungslehrstuhl 5 Projekte 1 Quasar = Qualitäts-Software-Architektur 2 epm = Effizientes und effektives Projektmanagement 3 MDD = Model Driven Development 4 RAIN = Rapid Innovation - globale, serviceorientierte Umgebung für die Auseinandersetzung mit der Zukunft 5 Stiftungslehrstuhl Global Software Engineering an der TU München im Lehrstuhl Informatik 3

4 Megacity Motivation 4

5 Software-Megacity??? = (große) Anwendungslandschaft = ein einzelnes Anwendungssystem 5

6 Die Rahmenbedingungen und Herausforderungen von gewachsenen Anwendungslandschaften und Städten sind durchaus vergleichbar Motivation Megacity Gewachsene Anwendungslandschaft Natürliches Wachstum: Städte unterliegen in der Regel einem natürlichen Wachstum um einen historischen Kern. Dieses natürliche Wachstum orientiert sich in der Regel an gegebenen Strukturen und kurzfristigen Zielen. Anwendungslandschaften sind in der Regel historisch gewachsen. Langfristige Organisationsbedürfnisse wurden in frühen und meist auch in späteren Wachstumsphasen nicht berücksichtigt. Historischer Kern: Häufig stellen die natürlich gewachsenen Strukturen einer Stadt Städteplaner vor besondere Herausforderungen, wenn die Stadt die aktuellen Bedürfnisse erfüllen soll beispielsweise zu enge Straßen im Stadtkern. Die in den frühen Wachstumsphasen vernachlässigten Organisationsbedürfnisse muss der -Architekt bei der Gestaltung von Anwendungslandschaften berücksichtigen. Die monolithischen Systeme stellen ihn vor besondere Herausforderungen. Kontinuierlich Funktionsfähig: Städte bilden den notwendigen Lebensraum vieler Menschen und tragen entscheidend zum Bruttoinlandsprodukt eines Landes bei. Sie müssen stets funktionieren. Die Anwendungslandschaft stellt eine beträchtliche Investition dar, die geschützt werden muss. Anwendungslandschaften müssen immer funktionieren. Anforderungen unterschiedlicher Stakeholder: Die Funktionsfähigkeit einer Stadt hängt von vielen Dimensionen ab. Wirtschaftliche Attraktivität und Lebensqualität müssen in einem ausgewogenen Verhältnis stehen. Anwendungslandschaften leisten einen Beitrag zum gesamten Unternehmenserfolg. Hierbei gilt es unterschiedliche Interessen ausgewogen zu berücksichtigen. 6

7 Aus der Stadtentwicklung kennen wir für verschiedene Ziele unterschiedliche Instrumente der Planung Motivation Raumnutzungsstrategien/räumliche Investitionssteuerung Leitlinien für Themenfelder wie Arbeiten, Wohnen, Ver- und Entsorgung Art der Bebauung (Wohnhaus, Bürogebäude etc.), Vorgaben (Höhe, Freiflächenanteil etc.) Auslegung von Straßen, Ver- und Entsorgungsstrukturen etc. Flächennutzungsplan Stadtentwicklungsplan Bebauungsplan Infrastrukturplan Strategisch Operativ 7

8 Serviceorientierung ist ein geeignetes Paradigma zur Gestaltung von - Anwendungslandschaften Was ist Serviceorientierung Verständnis von SOA Variante A Konkrete Technologie (z.b. Web Services) Software Engineering Konzepte die Technologien wie z.b. Web Services zugrunde liegen Hierfür ist kein neuer Begriff notwendig: Komponente, Schnittstelle und Operation sind bekannte und definierte Begriffe Variante B: Paradigma Um zunächst das eines Unternehmens zu strukturieren, Um dann von der geschäftlichen Unternehmensarchitektur die Architektur der -Anwendungslandschaft abzuleiten Im weiteren Verlauf wird dieses Verständnis von SOA verwendet 8

9 Für die serviceorientierte Entwicklung von Unternehmensarchitekturen benötigen wir ebenfalls Planungsinstrumente Überblick Unternehmensarchitektur Frameworks zur Gestaltung der Unternehmensarchitektur (IAF, TOGAF, ) sziele Architekturleitlinien -Architekturmanagement -Wirtschaftlichkeit sarchitektur sdimensionen Prozesse / Services sinformationen Informationssystem Architektur Domänenlandkarten Service-Repositories Kopplungsarchitektur Technische Infrastruktur Integrationsarchitektur Integrationsplattform Plattformarchitektur 9

10 Die serviceorientierte Entwicklung von Unternehmensarchitekturen orientiert sich am und am Ideal Überblick Schritt 1: Das Schritt 3: Das Ist erheben und Schritt 4: Die SollArchitektur IST vom Ist zum Ideal SOLL sarchitektur 10

11 und Ideal stellen zwei Pole dar Die Anwendungslandschaft muss möglichst beiden gerecht werden Überblick -Architektur/Anwendungslandschaft EUR Ideal Entwicklung der Anwendungslandschaft 11

12 Als Balance zwischen diesen beiden Bedürfnissen plant der Architekt die Entwicklung der Anwendungslandschaft Überblick Operative (und primär geschäftsgetriebene) Entwicklung -Architektur / Anwendungslandschaft Idealer Korridor der Balance EUR (wird konkret über Projekte angestrebt) SOLL Gesteuerte Evolution Verbesserung der operativen sunterstützung durch die Anwendungslandschaft IST Ideale Architektur Verbesserte Ausrichtung der Anwendungslandschaft am strategischen Ideal von und Strategische (und primär -orientierte) Entwicklung 12

13 Für diese serviceorientierte Entwicklung liefert Quasar Enterprise 20 erprobte Verfahrensbausteine Überblick 1 (Ziele und Anforderungen) 2 Methode zur Ableitung von sanforderungen Architekturleitlinien Informationssystem Architektur Methode zur Identifikation und Verfeinerung von sservice Informationssystem Architektur (Planung und Bebauung) Methoden und Regeln für eine Ideale Anwendungslandschaft Methoden und Regeln zur Erhebung und Bewertung der Ist-Anwendungslandschaft Technische Infrastruktur Regeln und Muster zur Gestaltung der Integrationsarchitektur Referenzarchitektur und Auswahl einer Integrationsplattform Methoden und Regeln zur Planung einer Soll- Anwendungslandschaft Methoden und Muster für gute Roadmaps vom Ist zum Soll 13

14 Serviceorientierte Architektur ist der Ansatz zur Fortentwicklung der Anwendungslandschaft Serviceorientierung Heterogene Prozesse Prozesse: Harmonisierung und Flexibilität Typische Situation Keine fachliche Struktur der Anwendungen Komplexe Anwendungslandschaft Struktur: Komponenten, Zuständigkeiten, Schnittstellen Infrastruktur: Entkopplung von Anwendungen Chancen durch SOA Kernfelder einer SOA Vielzahl an Plattformen Plattformen: Konsolidierung und Effizienz 14

15 Was ist eigentlich ein Service: Strikte Konzentration auf die Beschreibung der zu erbringenden Leistung eines Systems Serviceorientierung Außensicht System erbracht durch Innensicht System (Detaillierung Service A) Nutzungsvereinbarung System System Individualreise verkaufen sprozess Leistungen selektieren Angebot bereitstellen Kunde Pauschalreise verkaufen Leistungen empfehlen Plausibilität prüfen Nutzungsvereinbarung Nach Außen als Serviceaktion sichtbar verwendet Nutzungsvereinbarung Nach Außen als Serviceaktion sichtbar Nutzungsvereinbarung Leistungssuche,... Teilsystem 1 Service 2, Teilsystem 1 Teilsystem 2 Service 1, Teilsystem 2 Teilsystem 3 Service 1, Teilsystem 3 15

16 sservices als Bausteine der sarchitektur bilden die ideelle Vorlage für Anwendungsservices der SOA Die sarchitektur sservices... stellen eine Funktionalität dar, die eine unmittelbare geschäftliche Bedeutung hat (z.b. Überweisung eines Geldbetrages bei Banken) werden auf eine eindeutig definierte Art und Weise genutzt (z.b. per Überweisungsformular ODER per Online-Banking (aber nicht auf Zuruf)) haben klar definierte Reaktionen und Wirkungen zur Folge (z.b. Quittung, Belastung des einen Kontos und Entlastung des anderen) stehen im Kontext von vertraglichen Pflichten und Nutzen (z.b. ein überzogenes Konto wieder auszugleichen bzw. das Zielkonto tatsächlich und nach kurzer Zeit zu entlasten) werden an den Organisationsgrenzen nach außen angeboten (z.b. in einer Bankfiliale oder auch von einer Transaktionsbank oder einer entsprechenden Abteilung bankintern) Anwendungsservices der SOA... orientieren sich an den Idealvorstellungen der sservices bilden sservices ab, wo eine -Unterstützung sinnvoll ist werden von Komponenten der Anwendungslandschaft angeboten 16

17 Um eine Anwendungslandschaft grundsätzlich auf Serviceorientierung hin auszurichten, empfiehlt sich ein Programm Serviceorientierung 17

18 Für die serviceorientierte Gestaltung einer AL muss der Architekt zunächst das Die sarchitektur Schritt 1: Das sarchitektur Architektur sziele und Anforderungen sarchitektur sservices, sobjekte und Rollen sprozesse und Organisationseinheiten 18

19 Der Architekt leitet aus den szielen und Anforderungen die Architekturleitlinien ab Die sarchitektur Schritt 1: Das sarchitektur Architektur 1 sarchitektur X Y 1 Ableitung von Architekturleitlinien 19

20 Der -Architekt identifiziert und bewertet die relevanten sdimensionen Die sarchitektur Schritt 1: Das sarchitektur Architektur 1 Kunden / Marken sarchitektur Premiummarke Billigmarke z.b. eigene Unterkunft Vorabeinkauf Bedarfseinkauf Länge der Wertschöpfungskette Pauschalreise Individualreise Reisebüro Internet Call Center Kundenkanäle Produkte 20

21 Der Architekt identifiziert und verfeinert die sservices als Basis für eine echte SOA Die sarchitektur Schritt 1: Das sarchitektur Architektur 1 2 sarchitektur 2 Identifikation von sservices 21

22 und bestimmt die zugehörigen sobjekte Die sarchitektur Schritt 1: Das sarchitektur Architektur 1 2 sarchitektur 2 Identifikation von sservices 22

23 Identifikation von sservices ein betrachteter Serviceausschnitt kann funktional weiter verfeinert werden Die sarchitektur 23

24 Regel für elementare sservices: Eine Aktivität die von genau einer Rolle mit genau einem Ziel ausgeführt wird Die sarchitektur sziel 1 saktivität sobjekt Verhalten Information 1 sobjekt srolle 1 sservice 24

25 Versteht der Architekt das, beginnt er ein Idealbild der Anwendungslandschaft zu entwickeln Ideale Anwendungslandschaft Schritt 1: Das sarchitektur Architektur 1 2 Ideal sarchitektur? 25

26 Er strukturiert die Anwendungslandschaft in Form von Domänen Ideale Anwendungslandschaft Schritt 1: Das sarchitektur Architektur Ideal sarchitektur Flächennutzungsplan 3 Finden von Domänen 26

27 Domänen bilden einen idealen Ordnungsrahmen für die Komponenten einer Anwendungslandschaft Domänenlandkarte der Flächennutzungsplan Schritt 1: Das sarchitektur Architektur Domänen gruppieren die Komponenten einer Anwendungslandschaft nach fachlichen Gesichtspunkten Domänen dienen der Kommunikation zwischen Fachbereichen und, besonders wenn es um Verantwortung geht Für den Architekten sind Domänen ein wichtiges Werkzeug für die Planung und Durchführung der Evolution von Anwendungslandschaften Der Domänenschnitt liefert dem Architekten wichtige Kriterien für das Design von AL-Komponenten, deren Schnittstellen und Kopplung Domänen sind immer am des Unternehmens orientiert. Beispiele sind Vertrieb oder Partnermgmt. Es gibt grobe Erfahrungswerte für die Anzahl von Domänen und AL-Komponenten Größe der AL Anzahl AL-Komponenten Domänentiefe Anzahl Domänen Klein 1 <10 <30 Mittel Groß Sehr groß 3 >100 >

28 Ein gutes Domänenmodell erfüllt idealerweise eine Reihe von Strukturierungskriterien Domänenlandkarte der Flächennutzungsplan Schritt 1: Das sarchitektur Architektur 1 Minimalität Es gibt wenige Domänen auf oberster Ebene, diese werden ggf. weiter in Subdomänen gegliedert 4 Prozessorientierung sprozesse wechseln im Ablauf nicht zwischen Domänen hin und her 2 3 Ähnliche Verarbeitung Aus fachlicher Sicht wird durch die Domäne ein abgegrenzter Aufgabenblock bezeichnet, in dem gemeinsame Regeln und Vorgehensweisen existieren Minimale Abhängikeiten Die Anzahl der Abhängigkeiten zwischen den Domänen ist minimal 5 Stabilität Domänen sind bis zu einem gewissen Grad stabil gegenüber Variation/Weiterentwicklung der sprozesse 6 Nutzungsprofil Die Domäne bietet mehr als einen Service an, oder der Service wird von mehr als einer Domäne verwendet 28

29 Methode zum Entwurf von Domänen einer Anwendungslandschaft Domänenlandkarte der Flächennutzungsplan Schritt 1: Das sarchitektur Architektur 1 2 sservices des Unternehmens (Ebene 1) A Entwurf von Domänen Domänen sdimensionen und Ausprägungen des Unternehmens B 3 4 Zentrale sobjekte des Unternehmens (Ebene 1) C 5 Die folgenden Folien beschreiben das Verfahren in vereinfachter Form für CKR. 29

30 Schritt 1: Kerngeschäftsservices werden Domänenkandidaten Domänenlandkarte der Flächennutzungsplan Schritt 1: Das sarchitektur Architektur 1 30

31 Schritt 2: Domänenkandidaten können entlang einer sdimension aufgeteilt werden Domänenlandkarte der Flächennutzungsplan Schritt 1: Das sarchitektur Architektur 2 Pauschalreisen unterscheiden sich wesentlich von Individualreisen: Pauschalreisen werden komplett bepreist, Individualreisen nicht. Pauschalreisen unterliegen festen Zeitrastern (7 Tage, 14 Tage), Individualreisen nicht. 31

32 Schritt 2: Domänenkandidaten können auch über mehrere Dimensionen hinweg aufgespalten werden Domänenlandkarte der Flächennutzungsplan Schritt 1: Das sarchitektur Architektur 2 Der Verkauf als Ganzes besteht aus den Aktivitäten Reise zusammenstellen und Reise buchen. Das Zusammenstellen der Reise ist kundenkanalspezifisch. Im Reisebüro wird grundsätzlich anders verkauft als im Internet. 32

33 Schritt 2: Domänen nach Verfeinerung entlang der sdimensionen Domänenlandkarte der Flächennutzungsplan Schritt 1: Das sarchitektur Architektur 2 33

34 Schritt 3: Über Domänen hinweg genutzte Top-Level sobjekte werden eigene Domänenkandidaten Domänenlandkarte der Flächennutzungsplan Schritt 1: Das sarchitektur Architektur sobjekt Geschrieben in Kunde Reisebüro-Anwendungen, Internet- Portale, Call-Center, Buchung 3 Produkt Reiseauftrag Lieferant Leistung Produktgestaltung Buchung, Abwicklung Einkauf Leistungseinkauf, Verkauf 34

35 Schritt 4: Management- und Supportprozesse werden Domänenkandidaten Domänenlandkarte der Flächennutzungsplan Schritt 1: Das sarchitektur Architektur 4 35

36 Schritt 5: Finale Benennung und sinnvolle Anordnung der Domänen Domänenlandkarte der Flächennutzungsplan Schritt 1: Das sarchitektur Architektur 36

37 Die sd&m Referenz für Universalbanken spiegelt die Komplexität des s Domänenlandkarte Der Flächennutzungsplan Schritt 1: Das sarchitektur Architektur 37

38 Der Architekt identifiziert Anwendungsservices und ordnet diese den Domänen zu Ideale Anwendungslandschaft Schritt 1: Das sarchitektur Architektur Ideal sarchitektur Stadtentwicklungsplan 4 Identifikation von Anwendungsservices 38

39 Anwendungsservices und Serviceaktionen Anwendungsservices der Stadtentwicklungsplan Schritt 1: Das sarchitektur Architektur Definition Anwendungsservices Ein Anwendungsservice beschreibt eine informationstechnische Leistung, welche ein Servicegeber gegenüber einem Servicenehmer erbringt. Der Servicegeber ist eine Anwendungslandschaft oder ein Teil derselben. Der Servicenehmer kann eine Gruppe von Personen oder ein Teil einer möglicherweise anderen Anwendungslandschaft sein. Jedem Anwendungsservice liegt ein Vertrag zu Grunde. Dieser legt die ein- und ausgehenden Informationen fest. Er beschreibt die im Rahmen des Service durchzuführenden Aktionen und ihre Reihenfolge, sofern für den Servicenehmer relevant. Des Weiteren legt er alle relevanten Randbedingungen fest. Serviceaktionen Aktionen sind die Schritte bei der Ausführung eines Anwendungsservice, welche für den Servicenehmer relevant sind. 39

40 Einordnung der Anwendungsservices in die Domänen Anwendungsservices der Stadtentwicklungsplan Schritt 1: Das sarchitektur Architektur 40

41 Im nächsten Schritt plant der Architekt die Bebauung der Domänen mit Komponenten Ideale Anwendungslandschaft Schritt 1: Das sarchitektur Architektur Ideal sarchitektur Kategorien Bebauungsplan 5 Methode: Entwurf von Komponenten 6 Regeln: Entwurf von Komponenten 7 Ref. Architektur: Kategorisierte Anwendungslandschaft 41

42 AL-Komponenten Komponenten in der AL der Bebauungsplan Schritt 1: Das sarchitektur Architektur Definition Anwendungslandschaftskomponente Eine Anwendungslandschaftskomponente (AL-Komponente) ist eine geschlossene Einheit innerhalb einer Anwendungslandschaft mit den folgenden Eigenschaften: 1. Sie implementiert Anwendungsservices eines Unternehmens 2. Sie ist umfangreich 3. Sie hat explizite und wohldefinierte Schnittstellen für Funktionen, die sie anbietet 4. Sie hat explizite und wohldefinierte Schnittstellen für Funktionen, die sie nutzt 5. Sie kann mit anderen AL-Komponenten gekoppelt werden 42

43 Methode zum Entwurf von Komponenten Komponenten in der AL der Bebauungsplan Schritt 1: Das sarchitektur Architektur Die Anwendungsservices werden den Domänen zugeordnet. Die Anwendungsservices werden gruppiert nach den Kategorien Bestand, Funktion, Prozess und Interaktion Für die Anwendungsservices einer Domäne und einer Kategorie wird je ein Komponentenkandidat erstellt. Die Komponentenkandidaten werden gemäß den Regeln für den Komponentenschnitt verfeinert. 5 Die Komponentenkandidaten werden anhand der physischen Komponenten der Ist-Anwendungslandschaft auf Vollständigkeit überprüft und eventuell angepasst. Anschließend werden sie mit Namen belegt, die von den Beteiligten verstanden und akzeptiert werden. Sie bilden die finalen Komponenten. 43

44 Referenzarchitektur für Anwendungslandschaften Komponenten in der AL der Bebauungsplan Schritt 1: Das sarchitektur Architektur AL-Komponenten sind eindeutig Domänen zugeordnet Die Komponenten sind eindeutig einer Kategorie zugeordnet Die Komponentenabhängigkeiten folgen einer Schichtung in dem Sinne, dass klare Aufrufbeziehungen gemäß der Kategorien Interaktion Prozess Funktion Bestand gelten Die Trennung der Prozesslogik von Funktions- und Bestandskomponenten ist eine der wichtigsten architektonischen Maßnahmen zur Gestaltung von Anwendungslandschaften. 44

45 Kategorien sind keine Schichten! Komponenten in der AL der Bebauungsplan Schritt 1: Das sarchitektur Architektur 45

46 Regeln für den Entwurf von Komponenten Komponenten in der AL der Bebauungsplan Schritt 1: Das sarchitektur Architektur Komponenten Komponenten und Domänen Komponenten sollen eindeutig einer Domäne zugeordnet werden Fachliche Komponenten Komponenten sollen nach fachlichen Kriterien gebildet werden. Kategorienreine Komponenten Alle Operationen einer Komponente sollen von genau einer Kategorie (Bestand, Funktion, Prozess, Interaktion) sein. Kopplung gemäß Kategorien AL-Komponenten unterschiedlicher Kategorien sollen ausschließlich Kopplungen gemäß der Referenzarchitektur kategorisierte Anwendungslandschaft haben. Keine zyklischen Kopplungen Die Kopplungen zwischen Komponenten sollen einen gerichteten azyklischen Graphen bilden. Enger Zusammenhalt, geringe Kopplung Komponenten sollen so geschnitten werden, dass sie intern einen engen Zusammenhalt haben und untereinander gering gekoppelt sind. Datenhoheit Bestandskomponenten sollen die Datenhoheit über die sobjekte haben. 46

47 Bebauung der Domänen mit Komponenten Komponenten in der AL Der Bebauungsplan Schritt 1: Das sarchitektur Architektur 47

48 Danach plant er Schnittstellen und Kopplungsarchitektur Ideale Anwendungslandschaft Schritt 1: Das sarchitektur Architektur Architektur/Anwendungslandschaft Ideal sarchitektur Regeln Infrastrukturplan 8 Methode: Entwurf von Schnittstellen 9 Regeln: Entwurf von Schnittstellen 10 Regeln: Gestaltung Kopplungsarchitektur 48

49 Schnittstellen Schnittstellen der AL der Infrastrukturplan Schritt 1: Das sarchitektur Architektur Definition Schnittstellen Eine Schnittstelle fasst Operationen zusammen. Operationen beschreiben das Verhalten von Komponenten. Sie werden spezifiziert durch: 1. Signatur: Name der Operation, Parameter und Rückgabewerte und deren Typen, Ausnahmen 2. Semantik: Verhalten der Operation 3. Protokoll: Nutzung der Operation 4. Nichtfunktionale Eigenschaften: z.b. Performance, Verfügbarkeit, Kosten etc. 49

50 Regeln für den Entwurf von Schnittstellen Schnittstellen der AL der Infrastrukturplan Kategorie Art Regeln Interaktion Prozess Funktion Daten zusammengesetzt orchestrierbar geschäftsbezogen, technikneutral, referenzfrei grobgranular, idempotent, kompensierbar elementar kontextfrei 50

51 Gefundene Schnittstellen müssen validiert werden. Hierdurch ergibt sich auch die Kopplung der Komponenten. Schnittstellen der AL der Infrastrukturplan Schritt 1: Das sarchitektur Architektur 51

52 Zuletzt prüft der Architekt die Schnittstellen gegen die Prinzipien der Losen Kopplung Schnittstellen der AL der Infrastrukturplan Schritt 1: Das sarchitektur Architektur Sei A eine Komponente, die von B abhängt, also mit B kommuniziert. Ist A mit B lose gekoppelt, so gilt: Abhängigkeit von der Verfügbarkeit: A ist auch dann verfügbar, wenn B oder die Kommunikationsverbindung zu B nicht verfügbar ist Vertrauen: B vertraut nicht darauf, dass A Vorbedingungen von Operationen erfüllt. A vertraut nicht darauf, dass B die Nachbedingungen von Operationen erfüllt. Wissen: A verfügt nur über soviel Wissen über B, wie für die korrekte Nutzung der verwendeten Operationen notwendig ist. Dies umfasst die Syntax der Schnittstellen und die Struktur und Semantik der übergebenen und zurück gelieferten Daten. 52

53 Die Entfernung von Komponenten ist abhängig von der Kategorien- und Domänenzugehörigkeit Schnittstellen der AL der Infrastrukturplan Schritt 1: Das sarchitektur Architektur Domänen Kategorien Legende Domäne Schnittstelle Komponente Entfernung 53

54 Die Analogie zwischen den Planungsinstrumenten der Stadtentwicklung und der Anwendungslandschaft trägt. Ideale Anwendungslandschaft Ideal sarchitektur Domänen Anwendungsservices Flächennutzungsplan Stadtentwicklungsplan Komponenten Bebauungsplan Schnittstellen und Kopplung Infrastrukturplan 54

55 Und diesen Reiseführer gibt es auch als Buch Quasar Enterprise 55

56 Zusammen. Für nachhaltigen Erfolg.