SOA ontwerpproces en migratie

1. Service Oriented Architecture
Deel 6 – Ontwerpproces
Amersfoort
12 september 2009
Bas Kruiswijk

2. Service Oriented Architecture
Overzicht
Deel 6: SOA in het ontwerpproces
1. Basisconcepten
2. SOA vanuit organisatorisch perspectief
3. Procesbesturing
4. SOA vanuit technisch perspectief
5. De SOA infrastructuur
6. SOA in het ontwerpproces
– SOA implementatiestrategie
– SOA principes toepassen in het ontwerpproces van software
© Twynstra Gudde 12-9-2009 2

3. Service Oriented Architecture
SOA implementatiestrategie
Hoe SOA in te voeren?
– SOA is geen oplossing, het is een strategie
– Je kunt niet alles van te voren bedenken en beslissen
– Kern van de aanpak: een groeistrategie
– Incrementeel, iteratief
– Bestuurd en in de hand gehouden door een goede ‘SOA governance’
© Twynstra Gudde 12-9-2009 3

4. Service Oriented Architecture
^ééäáÅ~íáçå
SOA volwassenheid N
^ééäáÅ~íáçå
O
Van silo tot ecosysteem
^ééäáÅ~íáçå
P
^ééäáÅ~íáçå
Volwassenheidsgroei (bijvoorbeeld) Q
`äáÉåí `äáÉåí `äáÉåí
1. Silo’s pÉêîÉê pÉêîÉê pÉêîÉê
2. Applicatie integratie dÉåÉêáÅ=Ñ~ÅáäáíáÉë
rëì~ääó=Äìäâ=Ç~í~=ÉñÅÜ~åÖÉ
`çêéçê~íÉ=Ç~í~Ä~ëÉ
3. Componentisering
4. Basisdiensten Afnemers
(presentatie)
5. Samengestelde diensten
Procesdiensten
6. Procesdiensten
Samengestelde diensten
7. Ecosysteem
Basisdiensten
Backends Bestaand
Database systeem
Domein Domein
© Twynstra Gudde 12-9-2009 4

5. Service Oriented Architecture
SOA Governance
Beheersing van de ontwikkeling naar SOA
– Visie, doelen, business case en financiering
– Referentiearchitecturen
– Enterprise architectuur (samenhang tussen bedrijfsprocessen,
informatievoorziening, applicaties en infrastructuur)
– Software architectuur (opbouw van software in lagen etc.)
– Rollen en verantwoordelijkheden
– Centrale coördinatie
– Beleid, standaarden, richtlijnen etc.
– Ontwerp/ontwikkelproces en levenscyclus van services
© Twynstra Gudde 12-9-2009 5

6. Service Oriented Architecture
Rol van de SOA infrastructuur
Basis neerleggen en voortbouwen
Pilot 3
Pilot 2
Pilot 1
SOA infrastructuur
© Twynstra Gudde 12-9-2009 6

7. Service Oriented Architecture
SOA architectuur = heterogeniteit
Balans tussen complexiteit en één pakket
leveranciers
afhankelijkheid
De verbeterde
situatie
Eén systeem
Oneindig
keuze één leverancier
veel
systemen bereik
complex
veel interfaces
overlap en gaten
veel leveranciers Keuze bereik betreft:
- ICT-architectuur
- leveranciersonafhankelijkheid
- mogelijkheden in de markt
© Twynstra Gudde 12-9-2009 7

8. Service Oriented Architecture
Praktijkvoorbeelden
– Veronderstellingen over doelstellingen
– SOA is middel om complexiteitsreductie te realiseren
– SOA ondersteunt een ‘best-of-breed’ strategie als alternatief voor een ERP-
benadering
– SOA zorgt voor integrale procesondersteuning (betere functionaliteit)
– SOA zorgt voor beter ‘spel’ tussen business en ICT
– Dilemma’s
– Hoe krijg je SOA uit de sfeer van een ‘ICT feestje’?
– Hoe financier je de initiële investering?
– Hoe verkoop je dat de kost voor de baat uit gaat?
– Wat is de implementatiestrategie?
– Ambitieniveau (wat streef je na, en in welk tempo)
– Roadmap (in welke stappen daar te komen)
© Twynstra Gudde 12-9-2009 8

9. Service Oriented Architecture
Agile ontwikkelaanpak
Moderne ontwikkelaanpak die past bij SOA
– Problemen in een traditionele waterval-aanpak
– Ontwikkelprojecten duren erg lang – leveren te laat toegevoegde
waarde
– Documentatie raakt snel gedateerd
– Wijzigingen gedurende een ontwikkelproces werken verstorend
– Sterke sturing op tijd en geld, waardoor en niet (of minder) op
toegevoegde waarde wordt gestuurd
– En ondanks dat toch vaak tijd en budgetoverschrijding
– Alternatieve aanpak is gewenst én mogelijk!
– Agile: beweeglijk, lenig, wendbaar, snel
– ‘lichter’ ontwikkelproces, met focus op mensen en toegevoegde
waarde
– SOA is de architectuur die daar bij uitstek bij past
© Twynstra Gudde 12-9-2009 9

10. Service Oriented Architecture
Agile is zelf geen ontwikkelaanpak
Maar een categorie ‘moderne’ aanpakken
– Extreme Programming (XP)
– Rational Unified Process (RUP)
– SCRUM
– Dynamic System Development Methodology (DSDM)
– Adaptive Software Development
– Crystal
– Feature-Driven Development
– Pragmatic Programming
– Rapid Application Development (RAD)
© Twynstra Gudde 12-9-2009 10

11. Service Oriented Architecture
Agile Manifesto (2001)
Bekende namen definiëren het fenomeen
© Twynstra Gudde 12-9-2009 http://agilemanifesto.org/ 11

12. Service Oriented Architecture
Fundamenteel andere benadering
van de balans tussen tijd, geld en functionaliteit
© Twynstra Gudde 12-9-2009 12

13. Service Oriented Architecture
Voorbeeld: SCRUM
Iteratief en incrementeel ontwikkelproces
© Twynstra Gudde 12-9-2009 13

14. Service Oriented Architecture
Voorbeeld: DSDM
Iteratief en incrementeel ontwikkelproces
© Twynstra Gudde 12-9-2009 14

15. Service Oriented Architecture
Voorbeeld DSDM
4 basistechnieken (1)
– MoSCoW prioritering
– Er is nooit genoeg tijd om alles te doen, maar je wilt toch alles
benoemen
– Belangrijke dingen eerst
– Prototyping
– Zien is geloven, en een goed communicatiemiddel
– Eerst vanuit business perspectief iets goeds maken, dan pas
technisch
– Het prototype evolueert naar de werkende eindoplossing
© Twynstra Gudde 12-9-2009 15

16. Service Oriented Architecture
Voorbeeld DSDM
4 basistechnieken (2)
– Gefaciliteerde workshops
– Multidisciplinair en “empowered” team
– Snel als team beslissingen nemen
– Alle invalshoeken / stakeholders betrokken
– Gezamenlijk eigenaarschap
– Timeboxing
– Periodes van 2 tot 6 weken
– Tijd en geld is gefixeerd, functionaliteit is variabel
– Functionaliteit gedefinieerd in geprioriteerde (MoSCoW) requirements
– Gericht op de oplevering van een resultaat aan het einde van de
timebox
© Twynstra Gudde 12-9-2009 16

17. Service Oriented Architecture
Timeboxing
tussen tussen eind
resultaat resultaat resultaat
timebox 1 timebox 2 timebox 3 timebox 4 timebox 5 timebox … timebox n
aanpak timebox inhoud timebox
functionaliteit variabel Requirements
•… Mo
•… S
•… prioriteit
•… Co
•…
tijd geld vast W
•…
© Twynstra Gudde 12-9-2009 17

18. Service Oriented Architecture
Slotopmerkingen over agile aanpak
– Agile is natuurlijk populair omdat
– Veel projecten mislukken
– Filosofie van een waterval-aanpak heeft fundamentele tekortkomingen
– Contracteren / aanbesteding, fixed-price/date is in traditionele aanpak
problematisch
– Je houdt elkaar met gefixeerde requirements voor de gek
– Maar ook omdat
– De technologie is er nu klaar voor
– Ontwikkelplatforms en –straten
– Technologie voor SOA is volwassen genoeg om applicaties
daadwerkelijk samenstellen uit services
– Prototypes kunnen daadwerkelijk worden doorontwikkeld
– Verschillende technologieën kunnen worden gecombineerd
© Twynstra Gudde 12-9-2009 18

19. Service Oriented Architecture
Ontwerpproducten
Business domein Oplossingsdomein
Enterprise
architectuur
Business Class diagrams
architectuur Use Cases
Informatie Werkende
architectuur Sequence software
diagrams
Applicatie
architectuur Scenario’s
(Activity Diagrams)
Technische Deployment
architectuur diagrams
© Twynstra Gudde 12-9-2009 19

20. Service Oriented Architecture
Business architectuur
Model van de bedrijfsprocessen
© Twynstra Gudde 12-9-2009 20

21. Service Oriented Architecture
Use cases
Functionaliteit vanuit gebruikersperspectief
– Gewenste functionaliteit vanuit het perspectief van de
gebruiker
– In de taal van de onderwijsinstelling – op te stellen en te
begrijpen door medewerkers van instellingen
– Goed basis voor communicatie onderwijsprofessional met
ICT professional
– Laat de noodzakelijke ruimte voor ICT leverancier
– Voldoende basis voor een aanbesteding
© Twynstra Gudde 12-9-2009 21

22. Service Oriented Architecture
© Twynstra Gudde 12-9-2009 22

23. Service Oriented Architecture
Use Case: Formatief beoordelen
Aanleiding Noodzaak of wens tot beoordeling
Actoren Deelnemer, Docent, Begeleider
Doel Inzicht krijgen in vorderingen en ontwikkeling van de deelnemer voor wat betreft
kennis en competenties
Beschrijving acties – Beschikbaar stellen toetsmateriaal
– Beoordelen
– Vastleggen resultaat beoordeling
– Signaleren noodzakelijke acties
– Beschikbaar stellen beoordeeld product
Resultaat – Vastgelegd resultaat
– Beoordeeld product
– Gesignaleerde acties
Frequentie 15 x per deelnemer, per week
© Twynstra Gudde 12-9-2009 23

24. Service Oriented Architecture
Activiteitendiagram /
Scenario
– Nadere uitwerking van de ‘flow
of events’
– Onderscheid in actoren
– Verschillende scenario’s per
use case mogelijk
© Twynstra Gudde 12-9-2009 24

25. Service Oriented Architecture
Van scenario naar services
Ontwerpen vanuit gebruikersperspectief
Procesdiensten
Beschikbaar stellen Beoordelen Beschikbaar stellen
Initiëren beoordeeld product
toetsmateriaal
Noodzakelijke acties
Samengestelde Raadplegen Vastleggen
diensten relevante producten formatief resultaat
Basisdiensten Beschikbaar Terugplaatsen
stellen Raadplegen Vastleggen resultaat
onderwijscatalogus
Raadplegen
Deelnemer
Portfolio begeleiding
© Twynstra Gudde 12-9-2009 25

26. Service Oriented Architecture
Bas Kruiswijk
bkr@tg.nl
www.twynstragudde.nl
Alle intellectuele eigendomsrechten met betrekking tot
deze presentatie berusten bij Twynstra Gudde. Niets uit
deze presentatie mag worden verveelvoudigd of openbaar
gemaakt zonder schriftelijke toestemming van Twynstra
Gudde.
© Twynstra Gudde 12-9-2009 26