Service Oriented Architecture Deel 6 – Ontwerpproces

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

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’

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

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

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

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

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)

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

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)

Agile Manifesto (2001) Bekende namen definiëren het fenomeen http://agilemanifesto.org/

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

Voorbeeld: SCRUM Iteratief en incrementeel ontwikkelproces

Voorbeeld: DSDM Iteratief en incrementeel ontwikkelproces

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

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

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

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

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

Business architectuur Model van de bedrijfsprocessen

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

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

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

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

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.