View
213
Download
0
Category
Preview:
Citation preview
Bas Kruiswijk
Amersfoort12 september 2009
Service Oriented Architecture
Deel 6 – Ontwerpproces
2© Twynstra Gudde 12-9-2009
Service Oriented Architecture
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
3© Twynstra Gudde 12-9-2009
Service Oriented Architecture
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’
4© Twynstra Gudde 12-9-2009
Service Oriented Architecture
SOA volwassenheidVan silo tot ecosysteem
Volwassenheidsgroei (bijvoorbeeld)
1. Silo’s
2. Applicatie integratie
3. Componentisering
4. Basisdiensten
5. Samengestelde diensten
6. Procesdiensten
7. Ecosysteem
Application1
Application2
Application3 Application
4
Client
Server
Client
Server
Client
Server
Generic facilitiesUsually bulk data exchange
Corporate database
Database
Backends
Basisdiensten
Bestaandsysteem
Afnemers(presentatie)
Samengestelde diensten
Domein Domein
Procesdiensten
5© Twynstra Gudde 12-9-2009
Service Oriented Architecture
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
6© Twynstra Gudde 12-9-2009
Service Oriented Architecture
Rol van de SOA infrastructuurBasis neerleggen en voortbouwen
SOA infrastructuur
Pilot 1
Pilot 2
Pilot 3
7© Twynstra Gudde 12-9-2009
Service Oriented Architecture
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
8© Twynstra Gudde 12-9-2009
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)
9© Twynstra Gudde 12-9-2009
Service Oriented Architecture
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
10© Twynstra Gudde 12-9-2009
Service Oriented Architecture
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)
11© Twynstra Gudde 12-9-2009
Service Oriented Architecture
Agile Manifesto (2001)Bekende namen definiëren het fenomeen
http://agilemanifesto.org/
12© Twynstra Gudde 12-9-2009
Service Oriented Architecture
Fundamenteel andere benaderingvan de balans tussen tijd, geld en functionaliteit
13© Twynstra Gudde 12-9-2009
Service Oriented Architecture
Voorbeeld: SCRUMIteratief en incrementeel ontwikkelproces
30 days
24 h
Working incrementof the softwareSprint Backlog SprintProduct Backlog
14© Twynstra Gudde 12-9-2009
Service Oriented Architecture
Voorbeeld: DSDMIteratief en incrementeel ontwikkelproces
15© Twynstra Gudde 12-9-2009
Service Oriented Architecture
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
16© Twynstra Gudde 12-9-2009
Service Oriented Architecture
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
17© Twynstra Gudde 12-9-2009
Service Oriented Architecture
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 timebox
Requirements• …• …• …• …• … • …
prioriteit
Mo
S
Co
W
18© Twynstra Gudde 12-9-2009
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
19© Twynstra Gudde 12-9-2009
Service Oriented Architecture
Ontwerpproducten
Enterprisearchitectuur
Use Cases
Scenario’s(Activity Diagrams)
Class diagrams
Sequencediagrams
Deploymentdiagrams
Werkendesoftware
Business domein Oplossingsdomein
Businessarchitectuur
Informatiearchitectuur
Applicatiearchitectuur
Technischearchitectuur
20© Twynstra Gudde 12-9-2009
Service Oriented Architecture
Business architectuurModel van de bedrijfsprocessen
21© Twynstra Gudde 12-9-2009
Service Oriented Architecture
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
22© Twynstra Gudde 12-9-2009
Service Oriented Architecture
23© Twynstra Gudde 12-9-2009
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
24© Twynstra Gudde 12-9-2009
Service Oriented Architecture
Activiteitendiagram /Scenario
– Nadere uitwerking van de ‘flow of events’
– Onderscheid in actoren
– Verschillende scenario’s per use case mogelijk
25© Twynstra Gudde 12-9-2009
Service Oriented Architecture
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
26© Twynstra Gudde 12-9-2009
Service Oriented Architecture
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 Kruiswijkbkr@tg.nl
www.twynstragudde.nl
Recommended