Die vielen Gesichter von SOAGernot Starke • Stefan Tilkov
SOA zwischen Geschäftskonzept und technologischer Architektur
1
2
Was ist SOA?
3
Was ist SOA?
1.Ein unternehmensweiter
IT-Architektur-Ansatz
4
Was ist SOA?
1.Ein unternehmensweiter
IT-Architektur-Ansatz
Fokus auf Business/IT-Alignment
Modularisierung von Anwendungen
Von der Anwendungs- zur Service-Landschaft
Governance-Fokus
Realisierbar mit beliebigen Technologien
5
Was ist SOA?
2.Eine technologische
Architektur
6
Was ist SOA?
2.Eine technologische
Architektur
Services mit formal beschriebenen Schnittstellen
Wiederverwendung durch Aufruf
Trennung von Schnittstelle und Implementierung
Realisierbar mit WS-*, CORBA, Java EE/RMI/EJB, DCOM ...
7
Was ist SOA?
3.Das Konzept hinter SOAP/WSDL/WS-*
8
Was ist SOA?
3.Das Konzept hinter SOAP/WSDL/WS-*
SelbstbeschreibendeNachrichten (XML, XSD)
Envelope/Header/Body-Konzept
Dynamic lookup via Registry
Policy-getriebene Konfiguration
Anforderungsgetrieben kombinierbare Standards und
Spezifikationen
9
abstrakt konkret
tech
nisc
hfa
chlic
h EnterpriseArchitecture-
Konzept
High-Level-Architektur
Architektur vonWeb-Services/WS-*
10
SOA-Spektrum
Schritte
zu SOABusiness
Prozesse &
Methoden
RisikenArchitektur
& Technik
Governance
Betrieb
Grundlagen
Service-
orientierte
Architektur
11
Business
12
Business fordert mehr AgilitätSchnelle Umsetzung neuer
Geschäftsideen
Schnelle Unterstützung durch IT
Durch „konventionelle“ IT nicht leistbar!!
13
Business fordert mehr Agilität
Fokus auf
• Business-Agilität
• Business/IT-Alignment
• Wertschöpfung
• Wirtschaftlichkeit
14
Architektur & Technik
15
?Was bedeutet
“0 Rhesus negativ”
16
© 2005-2006 innoQ Deutschland GmbH
7
Component Based Development (CBD)– separation of interface &
implementation
– coarse-grained, reusable assets
– programming language independence
– declarative configuration
Object-oriented programming– encapsulation
– information hiding
– design by contract
– coupling of data & logic
Enterprise Application Integration– integration of monolithic apps
– intelligent infrastructure
– transformation & routing
– data integration
– OOTB adapters
Distributed Objects & RPC– location transparency
– request broker runtime
– common infrastructureservices
The Internet and the Web– global scale
– wire formats
– HTTP, URIs, REST
– XML and text-based protocols
SOA
Business Process Management– flexible business support
– IT/business alignment
Wie neu ist SOA?
17
SOA-Grundprinzipien1. Explicit Boundaries2. Shared Contract, not Code3. Driven by Policy4. Autonomous5. Wire Formats, not APIs6. Document-oriented7. Loosely coupled8. Standards-compliant9. Vendor independent
10. Metadata-driven
http://www.infoq.com/articles/tilkov-10-soa-principleshttp://msdn.microsoft.com/msdnmag/issues/04/01/Indigo/default.aspx
18
Dimensionen loser Kopplung
ZeitOrtTyp
VersionKardinalität
Schnittstellenspezifika...
19
ESB als Kern Ihrer SOA?SOA-Mainstream• Intelligente Infrastruktur• “Dumme” Endpoints• ESB im Zentrum• Produktlastig
“Pure SOA”-Alternative• “Dumme” Infrastruktur• Intelligente Endpoints• ESB nur als Konzept• Standard-fokussiert
20
Prozesse & Methoden
21
Bei der Einführung …
Top-down Strategisch, nur CxO-Involvierung, i.d.R. unbezahlbar
Bottom-up Chaotisch, unkontrollierbar, Governance-resistent
“Meet in the middle”
Wenige Rahmenbedingungen, Subsidiaritätsprinzip, Regelkreis
22
… und danach
Service-Lifecycle ist komplexer Prozess (Fachseite, Entwicklung, Betrieb)
Aktuell nur Kombination von Werkzeugen und Methoden einsetzbar
“SOA-Tools” nur fürs Management geeignet
23
Betrieb
24
Entzerrte Release-Verfahren
Lokalisierte Tests
Service Monitoring und Management
Service Ownership
“On the Wire”-Standardisierung
Metadaten und Governance
Konsequenzen für den Betrieb
25
Entzerrte Release-Verfahren
Lokalisierte Tests
Service Monitoring und Management
Service Ownership
“On the Wire”-Standardisierung
Metadaten und Governance
Konsequenzen für den Betrieb
26
Entzerrte Release-Verfahren
Unabhängige Evolution von Diensten
Lose Kopplung minimiert Abhängigkeiten
Services als Einheit von Entwicklung, Versionierung, Deployment, Administration
Schnellere Umsetzung von Anforderungen
27
Lokalisierte Tests
Klare Schnittstellenverträge gewährleisten Prüfbarkeit
Reduktion von Integrations- und Regressionstests
“Dummy”/”Mock”-Implementierungen
Starker Fokus auf Kompatibilität
28
Service-Monitoring und -Management
Management von Services statt Management von Ressourcen
Einsatz dedizierter Management-Software
Neue Möglichkeiten durch vereinheitlichte Protokolle/Formate
XML Gateways, Instrumentierung
BAM, CEP, EDA-Konzepte
29
Governance
30
Was ist Governance?
4 zentrale Aspekte:
• Welche Entscheidungen sind für effektives Management notwendig?
• Wer muss entscheiden und wer darf mitwirken?
• Wie werden Entscheidungen umgesetzt?
• Wie werden Ergebnisse verfolgt und gemessen?
Wie wird entschieden?
Was muss entschieden werden?
Wer soll entscheiden?
31
Darum SOA Governance
Governance spart Geld:
Unternehmen, die in Governance investieren, erzielen bis zu
20% höheren Nutzen aus ihren IT-Investitionen.
32
Darum SOA GovernanceKontrolle und ständige Verbesserung:
Regeln zur Umsetzung von Geschäftsanforderungen in IT
&
Prüfung der Einhaltung
SOA Metriken
33
Darum SOA Governance
Finden und Wiederverwenden von Services
Gestaltung von Services nach Geschäftsanforderungen
(sichert geschäftlichen Mehrwert)
34
SOA GovernanceBest Practices
Integration von IT- und SOA Governance
Entwicklung IT-Unternehmensarchitektur
Fokus auf „Geschäftszielen“
Priorisierung von IT-Investitionen anhand Geschäftswert
Zukunfts- statt vergangenheitsorientiert
35
Risiken
36
37
Risiko:Sprachverwirrung
Keine einheitlichen Begriffe - Beispiele:
• Service
• Servicevertrag
• Instanz
38
Risiko: Vergangenheitsbewältigung
SOA soll die IT-Sünden der Vergangenheit ausbaden
IT-Abteilung muss SOA „sowieso implementieren“
IT orientiert sich zu wenig an Fachbereichen
39
40
Risiko:Mammutprojekt
„Erfolgswahrscheinlichkeit eines Projekts sinkt mit dessen Grösse und Dauer“:
• Inhomogene Zielsetzung
• Viele Beteiligte - überhöhter Abstimmungsaufwand
41
Risiko:Unflexibilitätsfalle
Gewohnheitstiere: Menschen streben nach Stabilität und Sicherheit.
Flexibilität ist vielen Menschen zuwider
42
Risiko:Henne-Ei Problem
Services entwickeln und betreiben ist teuer
Wie & wo entsteht dadurch Mehrwert?
„Abrechnungsverfahren“ nicht ausgereift
43
Risiko:Tool-Falle
Wer nur den Hammer kennt, für den ist jedes Problem ein Nagel.
Ein „ESB“ macht noch keine SOA
44
Ihre Schritte zu SOA
45
1. Vergessen Sie Produkte
46
2. Formulieren Sie die konkreten Ziele Ihrer
Organisation
47
3. Starten Sie klein und fokussiert mit einem
Pilotprojekt für Business und Technik
48
4. Decken Sie alle kritischen Bereiche ab
(breites Spektrum)
49
5. Beginnen Sie frühzeitig mit Governance
50
Adler, OliverAlgermissen, JanAmmon, Rainer
vonBandholtz, Thomas
Bien, AdamBilling, GunnarColdewey, Jens
Cvetkovic, Kristijan Dahan, Udi
Dielingen, Axel vonDunkel, JürgenDüster, WillyFabini, Martin
Fink, ThorstenFrotscher, ThiloGförer, StefanGhadir, Phillip
Greiner, TorstenGutzeit, CarolHenning, Hans-
Jürgen vonHoffman, Frank
Höft, OliverIvanov, KonstantinJanning, Thorsten
Josuttis, NicoJuwig, Oliver
Kalex, UlrichKeller, WolfgangKleiner, CarstenKlemm, MarcoKoschel, ArneLauer, Daniel
Mahlberg, MichaelMezger, Thilo
Müller, ThomasOestereich, Bernd
Pingel, DierkRöder, Christian
Rohe, KlausRoth, Roman
Schelp, JoachimStal, Michael
Starke, GernotStein, SebastianStutz, MatthiasTilkov, Stefan
Tschierschke, DirkVölter, MarkusWestphal, Ralf
Wilms, HartmutWinter, RobertWolf, HenningWulff, Joachim
50 Meinungen.Auch eine für Sie dabei!
http://www.soa-expertenwissen.de
51
Two Faces of SOA...
52
Gernot StarkeSchwerpunktthemen:
Software-Architekturen
Entwurf, Entwicklung,Management
Mentoring und Coaching
Definition, Analyse,Optimierung vonEntwicklungsprozessen
Reviews, Audits, Retrospektiven
Dr. Gernot StarkeDoing IT Right
+49 (0) 177 – 728 [email protected]
www.gernotstarke.dewww.arc42.de
53
Stefan TilkovArchitekturberatungSOAMDA MDSD
WS-* RESTMDE
J(2)EE RoR .NET
http://www.innoq.com/blog/
http://www.innoq.com
54
Top Related