Difference between revisions of "3.5.3 Proof of Concept en Plan van Aanpak"

From Geonovum Wiki
Jump to: navigation, search
(Proof of Concept en Plan van Aanpak)
(No difference)

Revision as of 11:51, 6 August 2009


Proof of Concept en Plan van Aanpak

Bureau Xpert is gevraagd een Plan van Aanpak te ontwerpen voor het implementatieproject, met een nadere begroting van de kosten, en een Proof of Concept te vervaardigen.


Proof of Concept (PoC)
De adviseur van Xpert is gevraagd een implementatietraject te ontwerpen voor invoering van SOA bij IngClub, met een nadere begroting van de kosten. Na enige tijd komt Xpert met een Plan van Aanpak. Het bestaat uit 3 stappen:

  1. Het programma van eisen uitwerken en oplossingen ontwerpen,
  2. Het inrichten van een proeftuin om aan te tonen dat de gerealiseerde ontwerpen aan de gestelde eisen voldoen.
    De bedoeling is, dat de software bouwers door terugkoppeling uit de proeftuin hun ontwerp kunnen bijstellen, terwijl ook de gebruikers zonodig hun wensen kunnen aanpassen.
    Dit is een iteratief proces, waarbij het aantal terugkoppelingsslagen en de eraan te besteden tijd begrensd moet zijn.
  3. Als het MT tevreden is met wat in de proeftuin wordt getoond, kan de werkelijke invoering in de organisatie beginnen.
    Dat is de volgende fase. Om daarin terecht te komen moet het MT van IngClub een GO / NO GO beslissing nemen.

De genoemde stappen zijn in onderstaande figuur weergegeven:


SOA-PvA+PoC 70procent.png


De stap PROEFTUIN bevat een aantal componenten:



Er wordt intern bekend gemaakt dat er een proeftuin ingericht is voor de invoering van SOA, met omschrijving van doel en werkwijze, en contact-personen per afdeling en bij de directie. Dit is van belang voor het draagvlak van het project.


In de proeftuin wordt het werk-proces nagebootst van een zorg-vuldig geselecteerde representatieve case.
Deze case moet de eerder gesignaleerde probleemsymptomen vertonen, zodat kan blijken of die in de proefopzet zich niet voordoen.
Ook kan hier blijken dat zich bottlenecks voordoen die eerder niet genoemd of voorzien waren.


Er wordt specifieke software voorgesteld.
De keuze moet worden onderbouwd met een beargumenteerde afweging van aspecten van functionele, financiële, en beheersmatige aard, en benodigde gebruikerskennis.
Ook de benodigde bouwtijd van de applicatie(s) moet daarin worden verwerkt.


Met de gekozen software wordt een 'Quick and Dirty' prototype van de SOA productie-omgeving gemaakt. Hiermee kan de geselecteerde case worden beproefd, en kunnen losse vragen worden gesteld door de medewerkers.
Dit prototype wordt gewist als de proeftuin wordt opgeheven.








































Plan van Aanpak (PvA) en Begroting
Xpert maakt een plan voor de optimale volgorde om technische aanpassingen in te voeren, in combinatie met eventuele organisatorische en personele veranderingen en opleidingen. Daarmee ligt er een kritisch tijdpad, opgedeeld in een aantal fasen. In combinatie hiermee wordt ook begroot wat de kosten zullen zijn van de onderdelen van de implementatie, en hoe deze in de tijd gespreid kunnen worden.
Deze eerste versie van het PvA wordt aan de interne projectleider toegezonden, 1 week voordat hij zal rapporteren aan het MT.


Rapportage in MT
Door de interne projectleider wordt bijgehouden hoe alles in de proeftuin verloopt. Ook de software keuze en kosten van de applicatiebouw liggen op tafel.
De projectleider rapporteert hierover aan het eind van de periode aan het MT.
Op grond daarvan wordt in het MT besloten: nog op een onderdeel aanpassen, helemaal stoppen (NO GO) of doorgaan (GO) naar de implementatie in de productieomgeving.


Extra budget nodig
Tet MT is inhoudelijk overtuigd door de presentatie van Xpert, en stemt voor GO. Probleem hierbij is wel, dat het kosten-plaatje van Xpert het budget van het MT ruimschoots overschrijdt.
In overleg met de directievertegenwoordiger van het MT met de financieel directeur en de directievoorzitter lukt het om het SOA-projectbudget aangepast te krijgen. Daarbij waren de doorslaggevende argumenten:

  • Intern: het belang van SOA is afdelingsoverschrijdend vanwege de samenwerking tussen afdelingen. SOA moet leiden tot minder interne knelpunten.
  • Extern: de introductie van SOA vereenvoudigd de verwerking van binnenkomende bestanden, en de vereenvoudigd productie ervan voor afnemers.


Voorwaarden
De extra financiële ruimte wordt door de directie gegeven onder de volgende voorwaarden:

  • Breng een goede fasering aan (volgorde van veranderingen op basis van afhankelijkheid, mensen tijd geven om ermee te leren omgaan),
  • Blijf monitoren hoe de verbeteringen uitpakken, met bijvoorbeeld de eerder gebruikte case als referentiemateriaal,
  • Formuleer criteria, in overleg met Xpert, om aan de hand van de monitoringresultaten te kunnen beslissen wanneer het SOA implementatie-project beter kan worden gestopt, omdat de voorspelde verbeteringen in de werkprocessen niet worden gerealiseerd.


GO
Met het verruimde budget kan het MT van IngClub nu opdracht verlenen aan Xpert om SOA te implementeren.


Vereisten

De volgende vereiste wordt gesteld bij het Proof of Concept en Plan van Aanpak:

  • Management, ICT en alle betrokken afdelingen moeten samenwerken.


Details

De volgende details zijn van belang bij het Proof of Concept en Plan van Aanpak:

  • Management en andere betrokkenen moeten worden overtuigd van de meerwaarde van SOA;
  • Rekening houden met aanvulling en omvorming van software gereedschap;
  • Rekening houden met aanpassing van datasets en databases;
  • Rekening houden met aanpassing van organisatie;
  • Rekening houden met herplaatsen/bijscholen/aanvullen van personeel.


Faalfactoren

De volgende factoren zijn van invloed op het falen van het Proof of Concept en Plan van Aanpak:

  • Eisen en reikwijdte zijn niet vastgesteld;
  • De weergave van het bedrijfsproces in de PoC is niet van voldoende realistisch;
  • Vorm en inhoud van eindpresentatie van PoC zijn niet afgestemd op het kennisdomein en de belangstellingssfeer van het beoogde publiek;
  • Er is geen vertegenwoordiger van de ICT-afdeling in het hoger management van de organisatie;
  • Economische meerwaarde van de voorgestelde veranderingen wordt niet zichtbaar gemaakt;
  • Als het tempo waarin een PoC wordt geproduceerd te laag is, stimuleert het niet;
  • Afhankelijkheid van leveranciers van commerciële software voor aanpassen van software;
  • Teveel vooruitlopen op de massa (= de brede technische ontwikkeling);
  • Te weinig aandacht voor de menselijke factor (zeggenschap, creativiteit, sociaal);
  • Geen prioriteit voor kernapplicaties boven satellieten;
  • Geen risico inventarisatie gemaakt;
  • Geen maatregelen bedacht om de risico's te beperken.



previous Services Oriented Architecture (SOA) next