De presentatie wordt gedownload. Even geduld aub

De presentatie wordt gedownload. Even geduld aub

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

Verwante presentaties


Presentatie over: "Bas Kruiswijk Amersfoort 12 september 2009 Service Oriented Architecture Deel 6 – Ontwerpproces."— Transcript van de presentatie:

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

2 © Twynstra Gudde Service Oriented Architecture 2 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

3 © Twynstra Gudde Service Oriented Architecture 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 © Twynstra Gudde Service Oriented Architecture 4 SOA volwassenheid Van silo tot ecosysteem Volwassenheidsgroei (bijvoorbeeld) 1.Silo’s 2.Applicatie integratie 3.Componentisering 4.Basisdiensten 5.Samengestelde diensten 6.Procesdiensten 7.Ecosysteem

5 © Twynstra Gudde Service Oriented Architecture 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 © Twynstra Gudde Service Oriented Architecture 6 Rol van de SOA infrastructuur Basis neerleggen en voortbouwen SOA infrastructuur Pilot 1 Pilot 2 Pilot 3

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

8 © Twynstra Gudde Service Oriented Architecture 8 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)

9 © Twynstra Gudde Service Oriented Architecture 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 © Twynstra Gudde Service Oriented Architecture 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 © Twynstra Gudde Service Oriented Architecture 11 Agile Manifesto (2001) Bekende namen definiëren het fenomeen

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

13 © Twynstra Gudde Service Oriented Architecture 13 Voorbeeld: SCRUM Iteratief en incrementeel ontwikkelproces

14 © Twynstra Gudde Service Oriented Architecture 14 Voorbeeld: DSDM Iteratief en incrementeel ontwikkelproces

15 © Twynstra Gudde Service Oriented Architecture 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 © Twynstra Gudde Service Oriented Architecture 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 © Twynstra Gudde Service Oriented Architecture 17 Timeboxing tijdgeld functionaliteitvariabel vast timebox 1timebox 2timebox 3timebox 4timebox 5timebox …timebox n eind resultaat tussen resultaat tussen resultaat aanpak timeboxinhoud timebox Requirements … prioriteit Mo S Co W

18 © Twynstra Gudde Service Oriented Architecture 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 © Twynstra Gudde Service Oriented Architecture 19 Ontwerpproducten Enterprise architectuur Use Cases Scenario’s (Activity Diagrams) Class diagrams Sequence diagrams Deployment diagrams Werkende software Business domeinOplossingsdomein Business architectuur Informatie architectuur Applicatie architectuur Technische architectuur

20 © Twynstra Gudde Service Oriented Architecture 20 Business architectuur Model van de bedrijfsprocessen

21 © Twynstra Gudde Service Oriented Architecture 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 © Twynstra Gudde Service Oriented Architecture 22

23 © Twynstra Gudde Service Oriented Architecture 23 Use Case: Formatief beoordelen AanleidingNoodzaak of wens tot beoordeling ActorenDeelnemer, 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 Frequentie15 x per deelnemer, per week

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

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

26 © Twynstra Gudde Service Oriented Architecture 26 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. Bas Kruiswijk


Download ppt "Bas Kruiswijk Amersfoort 12 september 2009 Service Oriented Architecture Deel 6 – Ontwerpproces."

Verwante presentaties


Ads door Google