soa ontwerpproces en migratie

Bas Kruiswijk

Amersfoort12 september 2009

Service Oriented Architecture

Deel 6 – Ontwerpproces

2© Twynstra Gudde 12-9-2009


OverzichtDeel 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



SOA implementatiestrategieHoe 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 volwassenheidVan silo tot ecosysteem

Volwassenheidsgroei (bijvoorbeeld)

1. Silo’s

2. Applicatie integratie

3. Componentisering

4. Basisdiensten

5. Samengestelde diensten

6. Procesdiensten

7. Ecosysteem

^ééäáÅ~íáçåN

^ééäáÅ~íáçåO

^ééäáÅ~íáçåP

^ééäáÅ~íáçåQ

`äáÉåí

pÉêîÉê

`äáÉåí

pÉêîÉê

`äáÉåí

pÉêîÉê

dÉåÉêáÅ=Ñ~ÅáäáíáÉërëì~ääó=Äìäâ=Ç~í~=ÉñÅÜ~åÖÉ

`çêéçê~íÉ=Ç~í~Ä~ëÉ

Database

Backends

Basisdiensten

Bestaandsysteem

Afnemers(presentatie)

Samengestelde diensten

Domein Domein

Procesdiensten



SOA GovernanceBeheersing 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 infrastructuurBasis neerleggen en voortbouwen

SOA infrastructuurSOA infrastructuurSOA infrastructuurSOA infrastructuur

Pilot 1

Pilot 2

Pilot 3



SOA architectuur = heterogeniteitBalans tussen complexiteit en één pakket

Eén systeeméén leverancier

Oneindigveelsystemen

complex veel interfacesoverlap en gatenveel leveranciers

De verbeterde situatie

keuzebereik

Keuze bereik betreft:- ICT-architectuur- leveranciersonafhankelijkheid- mogelijkheden in de markt

leveranciersafhankelijkheid



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)



Agile ontwikkelaanpakModerne 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 ontwikkelaanpakMaar 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 benaderingvan de balans tussen tijd, geld en functionaliteit



Voorbeeld: SCRUMIteratief en incrementeel ontwikkelproces



Voorbeeld: DSDMIteratief en incrementeel ontwikkelproces



Voorbeeld DSDM4 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 DSDM4 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

tijd geld

functionaliteit variabel

vast

timebox 1 timebox 2 timebox 3 timebox 4 timebox 5 timebox … timebox n

eindresultaat

tussenresultaat

tussenresultaat

aanpak timebox inhoud timeboxRequirements• …• …• …• …• …• …

prioriteit

Mo

S

Co

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

Enterprisearchitectuur

Use Cases

Scenario’s(Activity Diagrams)

Class diagrams

Sequencediagrams

Deploymentdiagrams

Werkendesoftware

Business domein Oplossingsdomein

Businessarchitectuur

Informatiearchitectuur

Applicatiearchitectuur

Technischearchitectuur



Business architectuurModel van de bedrijfsprocessen



Use casesFunctionaliteit 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

15 x per deelnemer, per weekFrequentie

– Vastgelegd resultaat

– Beoordeeld product

– Gesignaleerde acties

Resultaat

– Beschikbaar stellen toetsmateriaal

– Beoordelen

– Vastleggen resultaat beoordeling

– Signaleren noodzakelijke acties

– Beschikbaar stellen beoordeeld product

Beschrijving acties

Inzicht krijgen in vorderingen en ontwikkeling van de deelnemer voor wat betreft kennis en competenties

Doel

Deelnemer, Docent, BegeleiderActoren

Noodzaak of wens tot beoordelingAanleiding



Activiteitendiagram /Scenario

– Nadere uitwerking van de ‘flowof events’

– Onderscheid in actoren

– Verschillende scenario’s per use case mogelijk



Van scenario naar servicesOntwerpen vanuit gebruikersperspectief

BasisdienstenBeschikbaar

stellenTerugplaatsen

Raadplegen

Raadplegenrelevante producten

Samengesteldediensten

Initiëren

Procesdiensten

Beschikbaar stellentoetsmateriaal

Noodzakelijke acties

Beoordelen Beschikbaar stellenbeoordeeld product

Raadplegenonderwijscatalogus

Portfolio

Vastleggenformatief resultaat

Vastleggen resultaat

Deelnemerbegeleiding



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 [email protected]

www.twynstragudde.nl