Service Oriented Architecture

Presentatie over: "Service Oriented Architecture"— Transcript van de presentatie:

1 Service Oriented Architecture
Deel 6 – Ontwerpproces

2 Overzicht Deel 6: SOA in het ontwerpproces
Basisconcepten SOA vanuit organisatorisch perspectief Procesbesturing SOA vanuit technisch perspectief De SOA infrastructuur SOA in het ontwerpproces SOA implementatiestrategie SOA principes toepassen in het ontwerpproces van software

3 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’

4 SOA volwassenheid Van silo tot ecosysteem
Volwassenheidsgroei (bijvoorbeeld) Silo’s Applicatie integratie Componentisering Basisdiensten Samengestelde diensten Procesdiensten Ecosysteem

5 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

6 Rol van de SOA infrastructuur Basis neerleggen en voortbouwen
Pilot 3 Pilot 2 Pilot 1 SOA infrastructuur

7 De verbeterde situatie
SOA architectuur = heterogeniteit Balans tussen complexiteit en één pakket leveranciers afhankelijkheid De verbeterde situatie Eén systeem één leverancier Oneindig veel systemen complex veel interfaces overlap en gaten veel leveranciers keuze bereik Keuze bereik betreft: ICT-architectuur leveranciersonafhankelijkheid mogelijkheden in de markt

8 Praktijkvoorbeelden Veronderstellingen over doelstellingen Dilemma’s
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)

9 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

10 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)

11 Agile Manifesto (2001) Bekende namen definiëren het fenomeen

12 Fundamenteel andere benadering van de balans tussen tijd, geld en functionaliteit

13 Voorbeeld: SCRUM Iteratief en incrementeel ontwikkelproces

14 Voorbeeld: DSDM Iteratief en incrementeel ontwikkelproces

15 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

16 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

17 Timeboxing aanpak timebox inhoud timebox functionaliteit variabel
tussen resultaat tussen resultaat eind 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 vast tijd geld W

18 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

19 Ontwerpproducten Business domein Oplossingsdomein Enterprise
architectuur Use Cases Class diagrams Business architectuur Informatie architectuur Werkende software Sequence diagrams Applicatie architectuur Scenario’s (Activity Diagrams) Deployment diagrams Technische architectuur

20 Business architectuur Model van de bedrijfsprocessen

21 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

22

23 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

24 Activiteitendiagram / Scenario
Nadere uitwerking van de ‘flow of events’ Onderscheid in actoren Verschillende scenario’s per use case mogelijk

25 Van scenario naar services Ontwerpen vanuit gebruikersperspectief
Procesdiensten Beschikbaar stellen toetsmateriaal Beoordelen Beschikbaar stellen beoordeeld product Initiëren Noodzakelijke acties Samengestelde diensten Raadplegen relevante producten Vastleggen formatief resultaat Basisdiensten Beschikbaar stellen Terugplaatsen Raadplegen onderwijscatalogus Vastleggen resultaat Raadplegen Deelnemer begeleiding Portfolio

26 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.