Managed hosting door True

Experts: SAP-directeur vergeet belang partner

Dit artikel delen:

Implementatiepartners spelen een grote rol bij het slagen of mislukken van SAP-implementaties. Dat zeggen Computable-experts in reactie op de uitspraak van de directeur van SAP-Nederland. Zij zei eerder dat klanten vaak zelf verantwoordelijk zijn voor het mislukken van SAP-implementaties.

De directeur van SAP-Nederland Angelique de Vries zei in een interview met Computable dat het mislukken van SAP-implementaties vaak te wijten is aan de klant zelf. Drie Computable-experts buigen zich over die uitspraak. Daarnaast stelde zij dat bedrijven vaak onvoldoende realiseren dat een implementatie gevolgen heeft voor de bedrijfsvoering. De experts kijken ook naar het programma voor waarborging van de kwaliteit van de Duitse leverancier en bespreken het beeld dat SAP-projecten vaak mislukken.

"Dat het mislukken van SAP-implementaties vaak te wijten is aan de klant zelf, is te kort door de bocht en moet worden genuanceerd", vindt directeur en managing consultant Dynamics
Riccardo Arnst van TMC Dynamics Professionals. Hij benadrukt dat er altijd twee partijen verantwoordelijk zijn voor het slagen of mislukken van projecten. Freelance SAP-consultant Erwin Dekker: "Je kan de schuld niet op één partij afschuiven. Dat verschilt per situatie. Implementatiepartners spelen ook een cruciale rol in het slagen of mislukken van een project", aldus de oprichter en voorzitter van MySapply, de stichting die de belangen van ruim 230 freelance SAP-consultants behartigt.

Arnst vindt dat er ook een kern van waarheid in de stelling van de SAP-directeur zit: "Klanten nemen soms beslissingen die tegen het advies van de implementatiepartner ingaan. Als het project vervolgens misloopt, ligt het volgens de klant ineens aan de software en de adviseurs van het project. Dat is niet terecht." Managing consultant Aart van Berk Atos Origin: "De implementatiepartner speelt een belangrijke rol om mislukkingen te voorkomen. Hij moet onhaalbare voorstellen van klanten durven te weigeren en het financiële belang dat hij heeft buitenspel kunnen zetten."

Ingrijpend

Volgens de Nederlandse SAP-directeur realiseren bedrijven zich onvoldoende wat het effect van een implementatie is op hun bedrijfsvoering. In het interview stelt ze: "Iedere implementatie van bijvoorbeeld een erp-systeem is ingrijpend voor de gebruikers. Dat geldt net zo goed voor ons als voor onze concurrenten." De experts herkennen dat beeld.

Aart van Berk: "Bedrijven stappen vaak over van een verouderde maatapplicatie naar een standaardapplicatie van SAP. Ze denken: ‘wat in het oude programma kon, kan ook in het nieuwe uitgebreide pakket. Die vasthoudendheid werkt niet bij een standaard pakket. Soms moet de organisatie veranderen om in het pakket te passen." Van Berk benadrukt dat maatwerk goed mogelijk is maar dat het dan wel extra geld en inspanning kost.

Arnst ziet dat vooral bedrijven die voor het eerste een grote implementatie doorlopen de gevolgen voor de bedrijfsvoering onderschatten. "Een van de eerste vragen die wij onze klanten stellen is: ‘Realiseert u de impact van de implementatie voor de dagelijkse werkzaamheden. Bent u ervan bewust dat u zelf een inspanning moet leveren om de implementatie tot een succes te maken?'."

Monitoren

Om te voorkomen dat implementatietrajecten mislopen is SAP gestart met het Quality Insurance Programma. Door projecten continu in de gaten te houden worden eventuele problemen in de kiem gesmoord.

Aart van Berk merkt dat de betrokkenheid van de leverancier de laatste jaren groter is geworden. Steeds vaker wordt ook bij contracten met middelgrote en kleine bedrijven gekeken of de implementatie wel op de goede weg zit. Riccardo Arnst vraagt zich af of het zogenoemde Quality Insurance programma wel de oplossing is. Volgens hem zou een onafhankelijke derde partij meer kunnen aantonen dan de peilstok van de leverancier. Hij vindt de controles van SAP een zinvolle aanvulling maar vindt dat door goed projectmanagement en een volwassen houding van de stuurgroep de vorderingen van een implementatie in kaart gebracht kunnen worden.

Erwin Dekker "Het is belangrijk om implementaties op te delen in blokken. Door de implementatie gefaseerd door te voeren is er voor de klant meer overzicht en de implementatie komt vaak beter overeen met de verwachtingen van de klant.

Imagoprobleem

Door een mislukte SAP-implementatie bij Free Record Shop en de provincie Noord-Holland heeft SAP het imago van dure en moeilijk te implementeren software. De Vries zegt dat het lijkt alsof projecten van de Duitse softwareleverancier relatief vaak mislukken omdat er in de media te weinig aandacht is voor de succesverhalen. De experts kennen de vooroordelen van klanten over de bedrijfssoftwarereus.

Dekker: "De gebruiksvriendelijkheid kan nog steeds beter. Het programma heeft veel complexe schermen . Het is voor gebruikers niet altijd duidelijk wat de stap of het proces is in het grotere geheel. Menu's zijn erg uitgebreid en standaard koppelingen zijn voor een gebruiker vaak niet te begrijpen. Dat lijkt de arrogantie te zijn van de grootste leverancier. Het is machtsmisbruik."

Dekker merkt dat er bij klanten vaak het vooroordeel bestaat dat paketten van de Duitse leverancier duur zijn en een lange implementatietijd vergen. "Maar er zijn juist paketten speciaal voor middelgrote en kleine bedrijven. Die software kan binnen enkele weken geïmplementeerd worden en biedt alleen een selectie van de functionaliteiten." Riccardo Arnst heeft voor kleine bedrijven die minder functionaliteiten willen een pakket van een concurrerende leverancier in het productaanbod.

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Lees verder


Reacties

Even een paar fragmenten:

"en het financiele belang dat hij heeft buitenspel kunnen zetten"
Toon me de leveranciers die dit kunnen, dat zijn een paar uitzonderingen, een dergelijke opmerking getuigt van een verlies aan realiteitszin.

"moet de organisatie veranderen om in het pakket te passen"
Dat hadden we al jaren geleden en iedere automatiseerder die een basiscursus doet leert dat juist dat de verkeerde weg is. Past de software niet bij de organisatie moet je andere software kiezen.

"de implementatie gefaseerd door te voeren"
Ja hebben we dan niets geleerd? Geen SDM 1 of 2 of hoe het vandaag de dag mag heten? IEDERE implemantatie moet gefaseerd doorgevoerd worden, als je een groot softwarepakket plotseling in een organisatie plempt, dan richt je schade aan. Die "implementatoren" die dat doen zouden voor de schade moeten opkomen.

Na dit tweede artikel moet een klant zich toch ernstige zorgen maken over de "expertise" van deze mensen. Iedere zichzelf respecterende automatiseerder moet toch een minimum talent hebben op gebied van projektplanningen anders moet je een ander beroep zoeken en zo voorkomen dat je klanten in de ellende stort.

Mijn zojuist gegeven reactie op het eerste artikel is hier ook nog van toepassing, daarom plaats ik het ook hier.

Natuurlijk hebben alle partijen schuld.

SAP omdat ze zeggen dat hun product 'alles' kan en ze uiteraard niet gaan zeggen: "als je je organisatie en werkwijze maar aanpast".

De consultants, omdat ze al in de offertefase van een traject de directie niet voldoende ondersteunen met goede, onafhankelijke adviezen en vervolgens ook vaak te veel naar het technische implementatietraject kijken en te weinig naar de culturele - menselijke - organisatorische aspecten (die 75% van het succes bepalen).

De directie en de rest van de business omdat ze een hype achterna lopen (dan is het weer ERP, dan is het weer SOA, dan is het weer Vista, ....) en zich onvoldoende verdiepen in de consequenties van hun keuzes (waarin ze, zie boven, dan ook onvoldoende worden ondersteund door SAP en consultants). En omdat ze meestal niet in staat zijn om hun wensen en eisen in voldoende mate aan te geven. Ze vertrouwen op de consultants. Maar kennen die de bedrijfsprocessen?

Als je er pas bij het testen achterkomt dat de SAP implementatie niet helemaal voldoet aan de verwachtingen ben je wat mij betreft rijkelijk laat.



Waarom zoemt toch dit nummer door mijn hoofd:

Denk niet wit, denk niet zwart, denk niet zwart wit.

Wat voor SAP geldt, geldt ook voor de andere grote ERP-pakketten: ze hebben een behoorlijke mate van starheid, worden vaak vertegenwoordigd door consultants die maar ??n pakket kennen en maatwerk heeft slechts de levensduur van ??n release. Bij de volgende release moet je weer opnieuw beginnen. Oorzaak: Slechte standaardisatie. Waarom: Niemand (behalve de klant) is gebaat bij standaardisatie. Standaardisatie betekent immers: minder werk voor de consultants, minder maatwerk voor de integrators en minder monopolie voor de ERP-leverancier. Daaraan wil ik nog toevoegen dat de ERP-consultants die ik tegenkom, zelden een IT-achtergrond hebben. Ze zijn ooit begonnen als super user bij concern X en eindigen als pakket-expert bij een consultancy club.

Reaktie op bericht 1 van Jan van Leeuwen:

Hij is duidelijk geen ERP deskundige en werkt waarschijnlijk bij een verkeerde organisatie. Volgens hem zetten implementatiepartners het financiele belang niet opzij. Dat is nu juist het punt waar het fout gaat als ze dat niet doen in die gevallen waar het nodig is. Een goede implementatie partner (en ja die zijn er wel) zal altijd het belang van de klant en de lange termijn relatie in het oog houden. Korte termijn financieel belang is kortzichtig. Er is juist van realiteitszin als een implementatiepartner hier wel naar kijkt. Waar werkt u?

En ja als je een standaardpakket aanschaft moet je op sommige punten je organisatie misschien maar aanpassen. Met SAP kan je ook programmeren dat er een rakket afgeschoten kan worden, dat moet je echter niet doen want daar is vast andere software voor die dat beter kan.

Het is kortzichtigheid als je vindt dat als je een standaardpakket aanschaft je dan alles maar moet kunnen met dat pakket. Ik kan dhr. van Leeuwen uit de droom helpen dat die pakketten niet bestaan. Zelfbouw is de andere optie. Kan een keuze zijn natuurlijk. Doe dan een kosten baten analyse. Dus toch maar af en toe consessies doen door je organisatie hier en daar aan te passen. Ook Shell / Unilever / DSM en noem maar op hebben dat gedaan. Maar heer van Leeuwen droom maar door.

Ook de laatste opmerking over gefaseerd doorvoeren van dhr van Leeuwen getuigd van weinig verstand van ERP / SAP implementatie. SAP is een mega pakket. Daarom kan het ook verstandig zijn om ook het pakket niet in zijn volle omvang in ??n keer te implementeren. Dat is de boodschap van Erwin Dekker volgens mij. Dat het gefaseerd moet is inderdaad voor de hand liggend.

Dus heer van Leeuwen: laat de reakties nu aan de experts, ik kon mij goed vinden in deze reakties in dit artikel. Er spreekt ervaring uit en ik heb zelf bijna 15 jaar ervaring in implementaties en vond de conclusies heel herkenbaar.

@ Tim de Recht

"Hij is duidelijk geen ERP deskundige en werkt waarschijnlijk bij een verkeerde organisatie."

Typisch, zodra je duidelijk stelt dat SAP-Consultants hun eigen belang niet buiten beschouwing laten, wordt je aangevallen. Hoe vaak heb ik dat in het verleden niet gehoord. Jullie werken met SAP om er beter van te worden, niet uit edele motieven. Dat is de realiteit.

(wat is overigens "een verkeerde organisatie"?)

Wat is er te dromen aan een beter proces bij het kiezen van het juiste standaardpakket? Dat je in het proces je organisatie verandert is normaal, automatiseren is per slot ook struktureren. Maar, SAP kiezen omdat 't SAP is en dan je organisatie afstemmen op SAP, het spijt me maar dat is D O M dom dom dom.

Wat ik over faseren schrijf heeft u niet gelezen of niet begrepen. In het artikel wordt een open deur ingetrapt, ieder groot pakket wordt gefaseerd ingevoerd.

Uw reaktie samengevat, ik ben "geen deskundige", "kortzichtig", "een dromer", "heb geen verstand van zaken" en "ben geen expert".
Kijk meneer de Recht, dat is de grondhouding die u waarschijnlijk ook tegenover uw klanten heeft.

Dat maakt SAP-Consultants zo mateloos "populair".

Er moet mij toch nog iets van het hart. De IT industrie is eigenlijke maar een rare business. Vergelijk het eens met de aannemerij. We zouden raar opkijken als een aannemer bij het opleveren van je huis een bedrag van 20% per jaar vraagt voor het onderhoud er van. Jawel, onderhoud betekent dan het oplossen van fouten (in de constructie) en andere zaken die er bij oplevering al in zaten en nu aan het licht komen of door aanpassingen door de aannemer erbij komen (hoezo garantie?). En elke keer als je de inrichting van je huis wilt veranderen, (te) dure bouwvakkers op je afstuurt om dat te doen, ook al is het het ophangen van een schilderijtje of het (opnieuw) behangen en schilderen. Een beetje handige huiseigenaar kan dat zelf.

En ja dat inrichten. Je kunt niet zomaar zelf allerlei meubeltjes en apparaten aanschaffen die op de markt verkrijgbaar zijn. Nee, die moeten compatible zijn met je huis (whatever that may be). Nou is het logisch dat het handig is dat ze bijvoorbeeld met 220 volt kunnen omgaan, maar compatible met wat? Zolang het apparaat het zelf goed doet, de bank lekker zit? En als je een garage wilt bijbouwen, een (andere) keuken wilt plaatsen of de badkamer wilt verbouwen, krijg je allerlei vergelijkbare problemen. En bovendien legt de aannemer ook nog op hoe en waar je die meubels en apparaten moet plaatsen. Want de aannemer heeft een bepaalde manier van wonen en leven in het huis ingebouwd. Die had hij immers van de architect doorgekregen die een ontwerp met jou heeft gemaakt. Dat de plek van de badkamer en de WC vastligt OK, maar de plek van de TV en het koffiezet apparaat ook? En ook wanneer je die wel en niet mag gebruiken? En als je nou de woonkamer anders wilt inrichten omdat het na een half jaartje uitproberen toch niet zo handig blijkt? (Te) dure bouwvakkers inhuren om dat te doen en na een half jaar is het gelukt (hoop je)? Had je maar van te voren beter moeten nadenken over hoe je het wilt hebben en testen. Ja, duh? Hoe kun je nou vanaf een CAD tekening beoordelen of iets lekker wonen is, ook als is dat in 3D en virtueel te bezichtigen? Dat kan toch alleen in de praktijk? En dan dat testen. Dus je moet eerst een half jaar proef gaan wonen in je nieuwe woning, met "nep" spulletjes en meubels (test data) en ondertussen in je oude woning nog het "echte" wonen blijven doen (productie)? En dan pas mag / kun je verhuizen? En met die "nep" spulletjes en meubels kun je je ook echt een goed oordeel vormen.

En periodiek zegt de aannemer met een compleet nieuwe versie van je huis te komen waar allerlei al dan niet gevraagde nieuwe snufjes inzitten. Want het huis moet wel meegaan met de nieuwste stand van de techniek en je wilde toch zo graag daar en daar een nieuw stopcontact? Maar dan moet wel je hele huis met de grond gelijk gemaakt worden en het nieuwe gebouwd en ondertussen kun je niet wonen. En oh ja, omdat je al klant bent krijg je een flinke korting op dit nieuwe huis. Maar ondertussen zijn al die leuke dingen die je zelf verbouwt hebt (keuken, badkamer, "maatwerk") niet compatible met het nieuwe huis en dus niet herbruikbaar en moet je die weggooien. En als je teveel versies achterloopt dan krijg je geen (duurbetaald) onderhoud meer. En als je dan in de problemen komt doordat fouten die jij nog in de constructie ontdekt (fouten gemaakt door de aannemer) niet meer opgelost worden, heb je pech.

Tja en dan het implementeren. Natuurlijk moet je op een hele nieuwe manier leren koken, want die nieuwe keuken werkt totaal anders. En ook de TV en DVD speler, want die oude moest je immers weggooien. En dan het deuren openen en ramen dichtdoen. Niet meer wat je gewend bent. Maar een paar intensieve weken cursus doet gelukkig wonderen. Het is immers ook volstrekt logisch dat je bij de aanschaf van een nieuwe auto opnieuw je rijbewijs moet halen, want dat nieuwe ding rijdt en werkt niet zoals je gewend bent, laat staan het besturen ervan of het benzine tanken (is de brandstof ?berhaupt wel te krijgen?)

Zulke aannemers zouden geen lang leven beschoren zijn, sterker nog: geen aannemer haalt dit in zijn hoofd. Waarom is dat dan in de IT industrie heel gewoon? Die zou nu zo langzamerhand toch wel eens volwassen en (al lang) uit het experimenteer stadium mogen zijn? En software kan niet eens slijten. De (buiten)verf van een huis bijvoorbeeld wel. En inderdaad, je manier van leven zal wel veranderen als je verhuist, maar het is toch (meestal?) de bedoeling dat je prettiger gaat wonen en voelen? En niet krapper of in een (ongewild) keurslijf?

Ik draaf misschien een beetje door, maar een situatie in het extreme verbeelden, maakt het wel zo duidelijk dat er toch iets grondig mis is in de IT industrie.

Jacco Hiemstra
www.produrion.nl

Was dit voorbeeld bedoeld als een afspiegeling van SAP of gaat het algemeen om automatisering?

Uw stijl bevalt me.

@ Jan.

Automatisering in het algemeen. Maar wie de schoen past trekke hem aan in het bijzonder ;-)

@Jaco Hiemstra

Ooit een applicatie gezien die een jaar of 70 jaar meegaat ?

Want daar heb je het wel over als je software vergelijkt met een huis.

@Jacco Hiemstra

Ik ben het niet eens met je uitspraak dat "de basisarchitectuur overeind blijft".
Een applicatie als SAP heeft in de laatste 20 jaar diverse fundamentele veranderingen doorgemaakt :
- van mainframe naar andere OS
- van 2-laags naar 3-laags architectuur
- van lokale applicatie naar Internet enabled
- van monoliet naar een modulair opgebouwd software stack.
Dat zijn allemaal fundamentele en noodzakelijke veranderingen in de evolutie van deze applicatie.

Geef eens een praktijkvoorbeeld van een applicatie waarvan de basisarchitectuur een paar decennia hetzelfde is.

@Bram

Ik ben het helemaal met je eens en toch ook niet. Die fundamentele (noodzakelijke) veranderingen die je beschrijft hebben niet zozeer met de pure functionaliteit te maken, maar met de onderliggende techniek. "Arme" klant die elke keer (te) duur moet betalen voor een nieuwe release, omdat de technologie verandert is, maar hij krijgt er geen nieuwe functionaliteit bij. Misschien wel gemak, zoals Internet enabled. Maar wisselingen van OS of tier of software stack is toch niet boeiend voor de klant? Alleen voor de software bouwer.

Bijvoorbeeld: je koopt groene stroom. De leverancier zegt: je moet je bedrading en stopcontacten in huis veranderen (en dus verloopstekkers aanschaffen voor de apparatuur die je al in huis hebt), want wij stappen nu over van zonne-energie naar wind energie. En om 23:00 uur gaat de stroom er 3 uur af voor de upgrade. Ik zou wit heet worden. Maar de IT leverancier vindt dit volstrekt normaal, zowel de interne IT afdeling als de software leverancier. Je verwacht dat jou elektriciteitsvoorziening volstrekt abstract is van de manier waarop de leverancier het produceert en transporteert. Zo zou het ook moeten zijn met functionaliteit van software.

Om volstrekt flexibel te (kunnen) zijn, moet je functionaliteit volkomen los zijn (abstract) van de gebruikte techniek. Zo kun je je functionaliteit altijd "aanpassen" aan of "plakken" op die technologie die je op dat moment zinvol vindt. Dit doe je o.a. door abstracte componenten te defini?ren (en programmeren) die een functionele interface gebruiken en die alleen puur de benodigde functionaliteit bevatten. De communicatie met andere componenten gebeurt buiten dat component om (door "communicatie" componenten). Daarnaast heb je "architectuur" componenten die ervoor zorgen dat de functionele componenten in / met een bepaalde architectuur, OS etc. kunnen draaien. Als je dan overstapt naar of ook gebruik wilt maken van een bepaalde andere of nieuwe architectuur, bijvoorbeeld Internet enabled, of ander OS, hoef je "alleen maar" een set componenten te maken die dat ondersteunen en ALLE componenten die ooit op deze manier gemaakt zijn kunnen daarmee werken. Dus als je eenmaal nuttige functionaliteit hebt gemaakt, kan dat decennia meegaan, onafhankelijk van de ontwikkelingen in de techniek. Alleen als functies veranderen, kan een (functionele) component overbodig raken (valuta component die met guldens werkt), of als een technologie (hardware / OS platform) niet meer wordt gebruikt, is die specifieke component(en set) die die technologie gebruikt overbodig en gooi je die weg (OS2). Niet de hele applicatie die op dat platform draaide.

Voor mij bestaat de basisarchitectuur uit die elementen die de benodigde functionaliteit leveren, de basisarchitectuur is voor mij niet de onderliggende techniek. Analoog met de bouwmetafoor: de basis architectuur is de functie van het gebouw: wonen, fabriek e.d., niet dat het gemaakt is van bakstenen of hout. Als er later een super kunststof uitgevonden wordt, kun je daarmee (aanvullende) functionaliteit voor het wonen of werken cre?ren, maar de basis functie blijft dezelfde.

Voorbeeld: een component om te printen. Je kon "vroeger" "alleen" maar naar een matrix- of letterwiel printer e.d. printen. Daarna kwamen de laserprinter, kleuren laserprinter, inktjet printer, PDF bestanden, enz. Straks krijg je nog 3-D printen of holografisch printen, etc. Maar ook de uitvoer naar het beeldscherm kan printen zijn (print voorbeeld). Maar het blijft printen, onafhankelijk van de voortschrijding van de techniek.

Wat je doet is dat je een print component definieert (volkomen abstract van andere componenten), die het fenomeen printen afhandelt voor alle componenten die daarom vragen. Hoe die print component dat dan doet is niet van belang voor die componenten die om een print functie vragen. Op het moment dat een component vraagt om een print functie, biedt de print component zich aan. De twee componenten wisselen bepaalde informatie uit die van belang is voor het printen, waaronder de te printen data. De print component vraagt dan, wie kan er voor mij daadwerkelijk printen en hoe? Hij krijgt dan reacties terug van alle op dat moment beschikbare componenten die daadwerkelijk kunnen printen (printer-, printvoorbeeld-, PDF-, enz. driver componenten). Die print component kan dan bijvoorbeeld een keuzelijstje component opvragen, die ervoor zorgt dat de gebruiker een keuzelijstje voorgeschoteld krijgt van alle voor de gebruiker op dat moment relevante printmogelijkheden (de reacties gefilterd op relevantie op basis van de print informatie, door een filter component). Als de gebruiker een keuze gemaakt heeft, vraagt de print component om een component die die keuze waar kan maken (bijvoorbeeld printen op een kleurenlaserprinter op de afdeling financi?n). En het zaakje wordt geprint. Al die tijd heeft de component die vroeg om een print functie er niets meer mee te maken gehad. Hij heeft zijn data en wensen afgegeven en gaat verder "met zijn leven".

De maker van de component die om een print functie vraagt, hoeft zich niet druk te maken over welke print mogelijkheden er wanneer zijn en welke veranderingen er daarin plaats vinden. Op het moment dat de kleurenprinter defect is, verschijnt hij niet in het keuze lijstje of wordt hij gemeld als niet beschikbaar maar wel aanwezig. Als er ergens een nieuwe printer geplaatst wordt, zorgt de betreffende verantwoordelijke voor de benodigde printer driver component(en). Als er glasvezel door het gebouw wordt gelegd, met daarop draaiende protocollen: boeiend, maar "zijn" component heeft daar volstrekt niets mee te maken en hij dus ook niet. Met andere woorden, geen enkele verandering in de IT omgeving heeft invloed op zijn component! Hij hoeft zich daar ook niet druk om te maken of te speculeren over de toekomst en alvast flexibiliteit in te bouwen voor die toekomst. Het systeem is inherent flexibel en ALTIJD klaar voor de toekomst

Ook hoeft hij zich niet druk te maken welke componenten hij allemaal nodig heeft om te kunnen printen en op welke hardware ze draaien of op welk architectuur platform. Voor die programmeur volstrekt niet interessant en / of noodzakelijk om te weten. Dat geldt ook voor zijn "eigen" component. Hij kan zich puur (met zijn klant) richten op de benodigde / gewenste functionaliteit. "Anderen" houden zich (met hun klanten, dat kunnen ook componenten programmeurs zijn) bezig met de gewenste / benodigde performance, architectuur, hardware, OS etc. Zonder dat ze daarbij moeten weten wat de gevraagde functionaliteit behelst. Zij hoeven zich alleen bezig te houden met voor hun relevante zaken, zoals performance, uitwisseling met andere systemen, etc. Heerlijk overzichtelijk, prettig managen, snel parallel ontwikkelen.

Zo kun je evolutionair een applicatie ontwikkelen. Je begint met een analyse op hoog niveau van de benodigde functionaliteit. In een eerste fase worden de fundamentele basisprocessen van het systeem gestructureerd door het identificeren van een of meerdere meta-applicaties en door het vervolgens bouwen van de interpreters voor deze meta-applicaties. Als de meta-applicaties zijn gebouwd dienen voor de verschillende situaties componenten te worden gebouwd die in deze situaties toepasbaar zijn (als je ze nog niet had -> hergebruik!). Als eenmaal een voldoende uitgebreide set van meta applicaties samen met functionele componenten is gebouwd kan men meta-programma's maken. Dit zijn kleine mini-programma's in ASCII-tekst die eventueel met een GUI kunnen worden getekend. Deze mini-programma's lijken sterk op analyses, omdat ze op een vrij hoog niveau beschrijven wat er gedaan moet worden.

Dit hele proces wordt beschreven zonder gebruik van code, zonder compilatie, zonder linking. Het is een kwestie van het proces intypen of tekenen en door de relevante interpreter laten uitvoeren.
Het maken van deze mini-programma's (en de daarbij horende beschrijvingen) is een taak die ook door iemand zonder programmeerkennis kan worden uitgevoerd. Gezien de kracht van de meta-applicaties kunnen hele systemen worden beschreven, zelfs en juist door personen met weinig kennis van IT. Men heeft niet alleen impact op de lay-out en look and feel van schermen, maar ook op de manier waarop de processen worden verwerkt.

Een groot verschil met de traditionele manier van programmeren is dit: Een standaard applicatie definieert via een beschrijving (de broncode) hoe een set van input data leidt tot een bepaald resultaat. Een meta-applicatie definieert via een meta-programma hoe een set van losse componenten kan samenwerken om te komen tot een bepaald functioneel geheel (of programma).

Als je eenmaal bepaalde, meer algemene, componenten hebt, kun je ze oneindig hergebruiken. Eventueel met kleine specifieke updates of toevoegen van subcomponenten. Bijvoorbeeld "functionele" componenten als printen, of "communicatie" componenten als ondersteuning TCP/IP. Je kunt heel snel, parallel, met de klant en zelfs door de klant, toekomst vast ontwikkelen.

En inderdaad, dit is een heel andere manier van werken, maar volgens mij de enige uitweg uit de IT problemen van vandaag de dag:

Te allen tijde FLEXIBEL zijn en blijven!
De mogelijkheid hebben om:
- Elk ontwerp, algoritme, interface of tool
- Op eender welk moment voor, tijdens en na het project
- Voor zo laag mogelijke kosten te kunnen wijzigen!

Time for a change?

Jacco Hiemstra
www.produrion.nl
P.S. ik dacht: even wat leesvoer voor het weekend ;-)

@Bram en @Jacco,

Ik ben het eens met Jacco Hiemstra. Zijn voorbeeld is bijzonder illustratief. Bovendien is de basisarchitectuur in dit geval het MODEL. Noem het voor mijn part het datamodel. Een dergelijk model kan decennia lang meegaan. Wat jij (Bram) als architectuur ziet, is in werkelijkheid een keuze voor een bepaalde technologie. Het fundament wordt gevormd door standaarden in werkprocessen en modellen die daarop gebaseerd zijn. Je zult je verbazen over de houdbaarheid daarvan. Ik ken systemen die wisselingen van OS, 2/3-tier etc. hebben overleefd. Je kunt altijd discussi?ren over de definitie van systeem, maar voor mij is een systeem het model waarin je je werkprocessen giet. De keuze die daarna komt is de uiteindelijke implementatievorm. Waar standaarden worden gehanteerd gaan systemen lang mee. Datzelfde geldt voor een huis. Als je daar gangbare standaarden in hanteert kun je je huis goed onderhouden en kun je de inrichting naar behoefte aanpassen. Standaarden zijn simpele dingen als: stopcontacten, voedingsspanningen, schakelaars, deurhoogtes, techniek van verwarmen etc.

Ik ben er overigens van overtuigd dat met een relatief klein ontwikkelteam een ERP-systeem kan worden neergezet dat de huidge marktleiders volledig van de kaart zou kunnen blazen. Als ik de IT in ??n sector qua technologie bijzonder zwak vindt, is het wel de ERP-business.

Mocht iemand nog in de verleiding komen om op te merken dat ik wel voor een bedrijf zal werken, waar dit soort pakketten niet gebruikt wordt, dan moet ik deze persoon helaas teleurstellen. Ik werk voor een multinational (>50.000 medewerkers). Wij werken met zowel SAP als Oracle en de bijbehorende consultants.

Momenteel zitten we in een project waarin de aannemer een nieuwe versie van het huis probeert te promoten. Deze nieuwe versie heeft een inpandige garage, terwijl wij net een vrijstaande garage hadden gebouwd die op alle vlakken beter is dan de inpandige versie van de aannemer. Bovendien weten we door te kiezen voor een vrijstaande garage zeker dat bij de volgende versie van het huis de garage ongeschonden blijft. Onze garage is gebouwd gebaseerd op de meest gangbare standaarden voor garages, heeft een mooie garagedeur naar de buitenwereld en een achterdeur die middels een pad toegang biedt tot ons huidige huis en tot eventueel toekomstige huizen. Wat wil je nog meer?

Bedankt voor de geweldige analogie Jacco! Bij mijn volgende presentatie aan de stuurgroep heb ik daar zeker wat aan.

@Johan,

Anytime. Ik heb nog wel meer in mijn koffer zitten ;-)

En je moest eens weten hoezeer je gelijk hebt!

: "Ik ben er overigens van overtuigd dat met een relatief klein ontwikkelteam een ERP-systeem kan worden neergezet dat de huidge marktleiders volledig van de kaart zou kunnen blazen. Als ik de IT in ??n sector qua technologie bijzonder zwak vindt, is het wel de ERP-business."

Sterker nog: het is mogelijk een Multi-tenant ERP applicatie (oftewel "hetzelfde" systeem dat per klant of zelfs gebruiker toch uniek is) te maken waarbij het procesverloop gestuurd wordt door bijvoorbeeld events. Vergelijk het met computer spellen. Op basis van een stuk intelligentie in het systeem, past het spel zich aan aan de situatie. Hoeveel levenskracht heb je, welke wapens en extra krachten bezit je etc. Een samenstel daarvan bepaalt of je bijvoorbeeld door een bepaalde deur mag of een level hoger enz. Of als je door een deur gegaan bent met bepaalde attributen krijg je bepaalde andere mogelijkheden (of verlies je ze). Allerlei gebeurtenissen hebben invloed op het verloop van het spel. Dingen van zowel jezelf, als andere spelers, als door het spel bepaalt. Al die mogelijkheden zijn natuurlijk nooit van te voren allemaal te voorspellen, laat staan vast te leggen. Dat doen ze dus in computerspellen dan ook niet (dat lossen ze veel slimmer op). Bij ERP, en alle IT projecten, willen (en kunnen) we dat wel?

Stel je het spellen principe eens voor bij een ERP systeem of welk IT systeem dan ook. Op basis van wat op je af komt als gebruiker (bijv. een bepaalde klant wil iets), gecombineerd met bepaalde input, krijg je een bepaalde procesflow met bepaalde functionaliteit voorgeschoteld en niets meer of minder dan wat je op dat moment nodig hebt. Sterker nog, het systeem neemt al een aantal beslissingen voor je op basis van wat hij al weet of te weten komt (al dan niet met behulp van kunstmatige intelligentie). Daarbij leert het systeem ook nog van beslissingen die je al eerder genomen hebt of eerdere procesverlopen. Het enige wat je als gebruiker dan nog hoeft te doen is bijvoorbeeld nog bepaalde extra input te geven of bepaalde beslissingen te nemen. Het systeem zorgt voor de rest. Daarbij hoef je dus niet van te voren alle mogelijke situaties en/of processen, en alle uitzonderingen daarop, in kaart te hebben. Een stevige basis, met een set situaties /uitzonderingen volstaat. Net als bij een spel: je hebt een bepaald verhaal in het spel zitten, dat zich in een bepaalde omgeving afspeelt. Maar hoe het verhaal zich afspeelt hangt van jou en andere factoren af. Een stap verder en je kunt zelf actie figuren, omgevingen en spelvarianten in het spel invoeren.

Komt het dan eens voor dat het systeem een bepaalde situatie (nog) niet aankan, kun je als gebruiker zelf het systeem uitbreiden (op meta niveau). Of laten doen door een collega die daar net wat bedrevener in is of meer verstand heeft van processen en/of modeling. Ontbreken er voor het realiseren van dat meta niveau bepaalde componenten, dan pas hoef je IT-ers in te schakelen en laat je die ontbrekende componenten door de IT afdeling of je leverancier maken. En als die componenten na een paar uren, dagen of hooguit weken (al naar gelang de urgentie en omvang) klaar zijn, stop je ze door middel van software hot-swap bij je systeem. Oftewel de componenten worden aan het systeem toegevoegd, zonder dat de gebruikers er ook maar iets van merken. Ja of het moet zijn, dat ze "opeens" meer kunnen / meer functionaliteit tot hun beschikking hebben. Een, enigszins manke, maar wel illustratieve vergelijking is te maken met second life.

En dat veel goedkoper, sneller ontwikkelt, toegespitst op wat de klant / gebruiker wil / nodig heeft, beter onderhoudbaar, goedkoper in het onderhoud, robuuster en stabieler, dan huidige IT oplossingen. Toekomst vast, zonder big-bangs of upgrades. Maar met smooth migration, integrerend met huidige systemen en de aanwezige infrastructuur / architectuur. Waarbij de klant / gebruiker een (groot) deel van het werk zelf kan doen (als hij dat wil).

Want zeg nou zelf: wie weet er nou het meeste van hoe het er in zijn eigen organisatie aan toe gaat of aan toe zou moeten gaan? Al dan niet naar boven gehaald met behulp van een organisatie adviseur? Laat iedereen zich concentreren op waar hij goed in is en vermeng dat niet (schoenmaker blijf bij je leest). Laten IT-ers zich bezig houden met waar ze goed in (behoren te) zijn: componenten programmeren, hardware installeren e.d. Zeg maar de infrastructuur maken: het casco voor het huis neerzetten, de aannemerij. Architecten ontwerpen dat casco op basis van wat de klant wil, interieur architecten ontwerpen het interieur, als je daar geld voor (over) hebt, enz. En hoe dichter het bij de klant komt, hoe meer de klant het vaak zelf wil doen. Doe het zelven, behangen, meubels kopen, lampen ophangen, kamer inrichten en zo. En hoe vaker dat ook verandert. Je huis verbouw je niet snel zo vaak, maar wat nieuwe / andere meubeltjes, ander behang, schilderijtje erbij? De bouwvakker (IT-er) ontwerpt niet het huis en koopt ook niet de meubels of kiest het behang. Hij bouwt het huis nav. een ontwerp door de gebruiker bepaalt. Zo wordt de IT-er weer een vakman/vrouw en komt de business (weer) aan het roer, ipv. de IT.

Ik voorspel dat die manier van werken uiteindelijk voor alle betrokkenen prettiger en minder frustrerend is. Iedereen kan zich specialiseren in zaken waar hij goed in is en hoeft niet (gedeeltelijk) op de stoel van een ander te zitten. Want dat gebeurt nu vaak, de IT-er zit ook op de stoel van de business en de business moet verstand van IT hebben om de juiste beslissingen te kunnen nemen. Bij het kiezen voor groene stroom hoef je toch ook alleen maar te weten dat groen betekent: zonne-, wind- of waterkracht. Hoe die stroom precies wordt opgewekt (dikte van de koperdraden in de generator), met welk voltage getransporteerd etc. boeit toch niet voor de keuze van de klant? Dat is interessant voor de stroomleverancier. Waarom zou je dan als klant wel moeten weten wat de spec's zijn van een Oracle database en of die beter of slechter zijn dan die van de concurrent? Boeit niet voor de klant, boeit wel voor de IT leverancier.

Leg de keuzes (en de uitvoering ervan) op de niveaus waar ze horen. Keuzes over (het verloop van) het primaire proces liggen bij de business, niet bij de IT. Nu bepaalt (de starheid van) het IT systeem hoe het proces moet verlopen. Pas je bedrijfsvoering aan, anders mislukt de implementatie wordt er gedreigd. De omgekeerde wereld. Vanaf nu moet je altijd eerst door de garage om de brievenbus te openen, in plaats van door de voordeur zoals je in het oude systeem gewend bent en toch ook wel het handigst en minst omslachtig is. Maar ja, als je dat in je nieuwe systeem (huis) wilt, is dat heel duur om te maken en bij de eerstvolgende upgrade is het maar afwachten of het dan nog steeds werkt. Geen enkele projectontwikkelaar kan op deze manier huizen verkopen. Software leveranciers flikken het wel. Of zij doen iets goed of de klanten iets goed fout. Als je dan toch de schuld bij de klant wilt leggen, moet het zijn dat die dit soort zaken pikt. Wat dat betreft heeft de directeur van SAP helemaal gelijk: het ligt aan de klant, alleen op een heel andere manier dan zij bedoelt. Of gooi ik nu een te grote knuppel in het hoenderhok ;-)

Zijn de geschetste mogelijkheden slechts een droom? Neem de eerste stap en ervaar het zelf ;-)

Jacco Hiemstra
www.produrion.nl

@jacco
Je vind dat functionaliteit onafhankelijk moet zijn van de techniek waarmee deze wordt aangeboden.

Natuurlijk zie zie direct de voordelen daarvan in, maar ik vraag mij af in hoeverre dat te realiseren is in de praktijk. Zo vereist de opslag van data bijvoorbeeld nu eenmaal een database (of een filesystem of beide) en het draaien van een programma ( of dat nu objectgeorienteerd is, functioneel of procedureel ) de aanwezigheid van een run-time environment. Het feit dat die virtueel, gecompileerd of geinterpreteerd wordt aangeboden maakt eenvoudigweg niets uit. Er bestaat altijd een betrekking tussen functionaliteit en architectuur, dat is nu eenmaal de realiteit.

Een praktijkvoorbeeld : om je functionaliteit persistent te maken, zal je een opslagmethode ervoor moeten verzinnen. Dat houdt in dat je een datamodel zal moeten ontwerpen om die functionaliteit op te kunnen slaan. SAP gebuikt hiervoor een relationele database. Het aanpassen van functionaliteit komt dus neer op een paar wijzigingen in deze database.

Wat betreft onafhankelijkheid van de software componenten ten aanzien van de run-time environment : SAP maakt gebruik van ABAP programma's die gecompileerd draaien in een geinterpreteerde runtime omgeving. Deze ABAP programma's zijn OS onafhankelijk en kunnen procedureel of object-georienteerd zijn. Ook maken ze gebruik van universeel gedefinieerde en herbruikbare business objecten. Pas daaronder bevindt zich een software laag die OS afhankelijk is, de SAP kernel.

Een SAP systeem is over te zetten naar een ander (virtueel) OS of kan gemigreerd worden naar een andere database en is in die zin niet afhankelijk van de techniek.

Dus stel ik je weer de vraag : geef mij nu eens een concreet voorbeeld van een bestaande applicatie waar de aangeboden functionaliteit volledig onafhankelijk is van de techniek waarmee die functionaliteit wordt aangeboden.

Verder zeg je : ""Arme" klant die elke keer (te) duur moet betalen voor een nieuwe release, omdat de technologie verandert is, maar hij krijgt er geen nieuwe functionaliteit bij. Misschien wel gemak, zoals Internet enabled."

Dat vind ik wat te sterk gesteld. In het geval van SAP (sorry voor de verwijzingen naar dit merk, maar het is nu eenmaal mijn specialisme) krijgt de gebruiker bij een release wissel wel degelijk nieuwe functionaliteit en vele verbeteringen in performance en dus ook functionaliteit, want het performance aspect van functionaliteit telt ook mee in de beleving van de gebruiker. Om de internet enabling van het SAP systeem simpelweg te classificeren onder de noemer 'gemak' doet mij vermoeden dat je deze applicatie niet echt kent. De mogelijkheden en toepassingen van Internet-enabling voor het SAP Netweaver platform zijn enorm.

Een evidente ervan bijvoorbeeld is dat gegevensuitwisseling tussen systemen van de klant en zijn leveranciers niet meer over dure verbindingen hoeft te lopen, maar nu via het internet plaatsvind.

De prijs die de klant betaald voor het produkt, is de prijs die hij ervoor over heeft. Dat jij die prijs relatief duur vindt doet daar niets aan af.

Een interessante discussie. Een ding valt op, het gebruik van de nederlandse taal en het gebruik van (slecht) jargon.
Als klant zou ik met "Bram" niet uit de voeten kunnen. Als je dure woorden gebruikt moet je ook weten wat ze betekenen. Neem een voorbeeld aan Jacco Hiemstra, die spreekt beter nederlands.
Een prijs is bijv. niet duur maar hoog.

Ik stel me langzaam de vraag of SAP leidt tot een eigen taalgebruik bij zijn consultants, als dat zo is begrijp ik de problemen met klanten.

Inderdaad een interessante discussie. En ik snap volkomen dat mensen worstelen met dit (nieuwe) gedachtegoed. Ik heb er zelf ook best lang over gedaan om tot de essentie te komen (en de vraag is of ik er al ben ;-)

"Een praktijkvoorbeeld : om je functionaliteit persistent te maken, zal je een opslagmethode ervoor moeten verzinnen.". Hier zit hem volgens mij de crux van het verschil tussen het "oude" en het "nieuwe" denken. Je moet juist NIET bijvoorbeeld een opslag methode voor de functionaliteit verzinnen. Daarmee cre?er je inherent afhankelijkheid / relaties. Dan ben je dus niet meer abstract bezig en dus niet meer optimaal flexibel. Je vraagt als het ware om een TECHNISCHE interface: database huppeldepup met datamodel zus en me zo, draaiend op ?, enz. Hoe dan wel? De functionaliteit vraagt om: wie kan voor mij een kant opslaan? Of een product, e.d. Je vraagt dus om een FUNCTIONELE interface. Hoe en waar is niet interessant, alleen wat. Nu vind je een relationele database spannend, maar morgen misschien wel een XML database. Als je het op de "oude" manier doet, ben je dan de klos, want je moet het hele zaakje migreren naar die XML database, functionaliteit aanpassen ("intern" in de code om met die nieuwe database te werken), enz. En dan hopen dat het goed gedocumenteerd is en je precies weet, waar je wat moet aanpassen. OK, goed voor de leverancier, want die kan weer een (te) dure upgrade verkopen, maar wat schiet de klant ermee op? Qua functionaliteit niets en niemendal. Het is handig voor de leverancier, want die kan bijvoorbeeld iets sneller programmeren, er is meer deskundigheid op dat gebied, oude database presteert slecht, draait op legacy hardware, etc. Lees leverancier kan ook de (interne) IT afdeling zijn.

Bij de "nieuwe" manier hoef je "niets" te doen. Als jij om TECHNISCHE redenen (want daar hebben we het over) besluit over te stappen op een andere database, hoef je alleen het component dat de opslag van de gegevens van bijvoorbeeld de klant verzorgt te vertellen dat het op een andere manier, ergens anders gebeurt. Alleen voor dat component doe je aanpassingen, migreer je de data enz. Alle componenten die gebruik maken van die opslag componenten weten van niks, merken het niet en hoeven het ook niet te weten!

Je moet het echt allemaal scheiden. Bijvoorbeeld een klusjesman: wat wil je van die klusjesman? Bijvoorbeeld een dakkapel, die aan bepaalde eisen moet voldoen. Ga je hem vertellen hoe hij dat moet doen en met welk gereedschap? Waarom huur je hem dan in als je het zelf beter weet? En ga je hem dan op de neus kijken of hij dat gereedschap ook daadwerkelijk gebruikt? En als hij tijdens zijn klus zijn "oude" hamer inruilt voor een "nieuwe", omdat hij dat om (technische) redenen handig vindt? Het veranderen van (merk, grootte, type) hamer boeit de klant toch niet? Als hij de dakkapel maar mooi en goed plaatst, tegen niet al te veel kosten.

Stel je voor hoe krachtig dit is! Je krijgt applicatie virtualisatie: je complete toepassing draait "ergens". Maar je weet niet precies waar en hoe (als gebruiker). De componenten die jou toepassing vormen, draaien op 1 of meer machines, van maakt niet uit welk type, welke performance, welk OS enz. En maakt niet uit waar, onder je bureau, in een service center, op internet of alles tegelijk. Ook voor de IT-ers is dit ideaal. Is de toepassing klein genoeg, past het op 1 stuk (goedkope) hardware. Neemt de belasting toe, koop je een stuk (goedkope) hardware erbij en laat 1 of meer componenten daarop draaien, enz. De database(s) draait lokaal of ergens anders. Beslis je als IT-er dat het op een bepaalt moment anders moet, dan doe je dat, zonder dat de klant / gebruiker er ook maar iets van merkt (of het moet een verbetering zijn). De toepassing hoeft niet plat (software hotswap), je hoeft geen upgrade van de hele toepassing te doen, alleen die componenten die rechtstreeks met die (technische) aanpassing te maken hebben. Fouten opsporen en repareren is een makkie vergeleken met de "oude" situatie. Want die beperken zich tot 1 of een paar componenten. En omdat die componenten geen (technische) relatie met elkaar hebben (zoals inheritance) en ook geen verborgen relaties (de pest van alle software!), legt een fout niet de hele toepassing lam. Ook een aanpassing van een component (functioneel, technisch of een fout reparatie) brengt, om dezelfde redenen, niet de hele toepassing in gevaar.

Nog een goed voorbeeld: " De mogelijkheden en toepassingen van Internet-enabling voor het SAP Netweaver platform zijn enorm. Een evidente ervan bijvoorbeeld is dat gegevensuitwisseling tussen systemen van de klant en zijn leveranciers niet meer over dure verbindingen hoeft te lopen, maar nu via het internet plaatsvind."

Performance, bijvoorbeeld, moet ALTIJD onafhankelijk zijn van de functionaliteit. Lees mij goed: ALTIJD. Net zoals alle andere technische zaken. In het genoemde geval, moet de hele applicatie overgezet worden naar een nieuw platform om de gevraagde (technische) functionaliteit te realiseren. In het geval van het "nieuwe" denken, hoef je alleen maar een "internet communicatie" component toe te voegen, et voila, alle componenten die je ooit op deze manier gemaakt hebt, lees het goed ALLE, zijn "opeens" internet enabled. Hoe dat kan? Een (functionele) component vraagt alleen maar: "wie kan mij de productgegevens van dat en dat artikel, van die en die leverancier leveren?". Het boeit hem (de vragende component) volstrekt niet waar die vandaan moeten komen (of je ze nou al locaal hebt staan of nog bij de leverancier moet halen) en hoe dat gebeurt (leased line, internet, 33k6 modem, etc.), als het maar de juiste gegevens zijn (datzelfde geldt voor de gebruiker achter het scherm ;-), maar wel een beetje snel graag ;-). Vervolgens biedt een component zich aan die dat kan leveren. Dit kan 1 component zijn of een set van componenten, al naar gelang de situatie en de "architectuur" die je voor de "leverancier" component gekozen hebt. En als je die nog niet geprogrammeerd hebt, want bijv. een nieuwe leverancier, bouw je die en voeg je die toe (matter of days / weeks, not months). Vervolgens maakt die "leverancier" component weer gebruik van de aanwezige "technische" communicatie mogelijkheden / componenten van het systeem. Hij vraagt om een verbinding met de (database) van de leverancier en wel een beetje snel graag. En alweer boeit het de "leverancier" component volstrekt niet hoe dat gebeurt. Het systeem of "componenten set / wolk" dat verantwoordelijk is voor de communicatie zorgt voor de snelle verbinding. Daarbij kiest hij uit de tot hem ter beschikking staande middelen (componenten) de beste (op basis van bijv. prijs-, prestatie- en kwaliteitscriteria). Is die verbinding toch te slecht of valt weg, schakelt hij over op een andere. Komt er iets nieuws, bijv. internet, voeg je dat toe aan zijn repertoire (http, https, ftp, enz). Een nieuw protocol (SOAP hupeldepup of iets anders XML achtigs, protcol XYZ, standaard PQR)? Componentje (of 2) toevoegen, klaar. Satelliet verbinding, communicatie met de maan, laser verbinding? Wat voor "gekkigheid" ze (in de toekomst) ook verzinnen, je voegt het zo toe. En daarvoor hoef je dus niet het hele systeem te upgraden of van platform te veranderen. Componenten van 20 jaar oud kunnen er net zo goed meteen gebruik van maken, net zo makkelijk als componenten van vandaag of morgen. Niemand, niet de gebruiker of de componenten bouwer of de component zelf, hoeft zich immers druk te maken over hoe er gecommuniceerd wordt. Alleen degene (IT-er en/of communicatie component) die direct over de (manier van) communiceren gaat, hoeft dat in de gaten te houden en er eventueel op te anticiperen (bij te bouwen).

Zoals gezegd een hele andere manier van denken. En weer: Stel je voor hoe krachtig dit is!

En dan heb ik het nog niet over de mogelijkheden zoals:
- testen van nieuwe functionaliteit in productie omstandigheden (switchen tussen master / slave en weer terug), want dan wordt het immers pas echt spannend,
- terug kunnen vallen op een of meerdere oudere situaties, ook naar jaren, als er opeens toch grote problemen met de nieuwe situatie opduiken die acuut zijn (show stopper) en je hebt ze niet 1, 2, 3 opgelost
- toepassingen draaien op elk platform dat je wilt, ook mobiel. Ook transactie gericht (dat je dus zeker weet dat iets is uitgevoerd), en niet alleen via een webrowser op je mobiel / PDA, maar een echte bruikbare applicatie, ook als de verbinding er even niet is (dat komt mobiel immers nooit voor ;-)
- semi-automatisch, context gevoelig, beheer en upgraden van (duizenden / miljoenen) devices: bijvoorbeeld mobieltjes en PDA's, maar ook embedded, zoals software in auto's, verwarmingsketels enz.
- ...

Jacco Hiemstra
www.produrion.nl

@Jacco Hiemstra

Je verhaal lezende besef ik nu pas (wat laat en dat geef ik direct toe) dat we hier praten over een concept en niet iets dat al bestaat. Ik had je al 2 maal gevraagd om een verwijzing naar een implementatie van je idee, maar aangezien je blijft komen met een beschrijving van de mogelijkheden en het potentiaal van je concept en een beschrijving van de implementatie ervan uit de weg gaat, neem ik dus nu aan dat het hier om een concept gaat.

Nogmaals : jij vind dat functionaliteit onafhankelijk moet zijn van de techniek waarmee deze wordt aangeboden.

Ik ben van de overtuiging dat, zolang computers zijn gebaseerd op een von Neumann architectuur, jouw idee een utopie blijft. Een beeetje te vergelijken met een perpetum mobile, aantrekkelijk maar niet te verwezenlijken in de praktijk.

In de realiteit, (want daar heb ik het hier over!), heeft elke run-time environment, hoe gevirtualiseerd ook, afhankelijkheden naar een OS. Om functionaliteit en data persistent te maken, moet deze opgeslagen worden en daarmee heb je weer een afhankelijkheid naar het OS. Om te kunnen communiceren met de buitenwereld heb je een netwerkverbinding, en dus weer een afhankelijkheid, nodig. Zo kan ik nog wel even doorgaan.

In plaats van een huis als vergelijking te gebruiken zou je ook een radioprogramma kunnen nemen : de functionaliteit is het radioprogramma, de luisteraar is de gebruiker en de architectuur is het medium. Ruis is dan een storing in de architectuur die invloed heeft op de ontvangst van het radioprogramma. Om die ruis weg te nemen, zal je redundantie moeten hebben in je architectuur. Deze redundantie is vooralsnog het enige instrument dat er bestaat om de aangeboden functionaliteit onafhankelijk te maken van de architectuur.

Dan het voorbeeld dat je aangeeft. Je zegt :
"Componenten van 20 jaar oud kunnen er net zo goed meteen gebruik van maken, net zo makkelijk als componenten van vandaag of morgen."

Geef eens aan hoe jij denkt dat een component van 20 jaar oud kennis kan hebben over het bestaan van een andere, nieuwere, component die een nieuwe functie aanbiedt (bijvoorbeeld de toegang naar het internet) ?

@Jan van Leeuwen
Je selecteert je consultants dus op hun kennis van de Nederlandse grammatica. Geen wonder dat er zoveel mislukte SAP implementaties plaatsvinden. Evenwel geef je je toch nog het advies om nog even te wachten met de stuurgroep te informeren totdat Jacco met een praktische implementatie van zijn idee op de proppen komt.

Ik vind deze discussie een heerlijke uitdaging en ik merk dat dezelfde stappen gezet worden als ik al heb gezet en we gaan goed vooruit!

En inderdaad zoals Bram eigenlijk zegt (denk ik): uiteindelijk is het toch aSmoP (a Simple matter of Programming). Je moet uiteindelijk kleur bekennen, met de billen bloot, concreet worden naar inderdaad een database, OS, netwerkverbinding etc. Ontken ik niet, maar doe dat zo laat mogelijk. Niet al bij het "begin" van de functionaliteit. Het volgende citaat is cruciaal in het denken (of eigenlijk de "denkfout"):

"Geef eens aan hoe jij denkt dat een component van 20 jaar oud kennis kan hebben over het bestaan van een andere, nieuwere, component die een nieuwe functie aanbiedt (bijvoorbeeld de toegang naar het internet) ?"

Hier zit hem de crux: dat component hoeft dat niet te weten (we hebben het hier over een "functionele" component). Als je even terugbladert voor de langere uitleg, zeg ik het hier even kort: een "bestel" component (van bijvoorbeeld 20 jaar oud, want bestellen is en blijft immers bestellen), vraagt om een component dat de artikelgegevens van een leverancier kan leveren, de "leverancier" component (de "bestel" component weet niet of die bestaat, hij vraagt erom). Die "leverancier" component vraagt weer om een component die de verbinding met de leverancier database kan maken, de "communicatie" component. Tot nu toe weet nog geen enkele component iets over HOE dat moet, zij het de soort (internet), het protocol (http), de "taal" (SOAP) enz. En hoeft dat dus ook niet te weten om zijn werk te kunnen doen! Nu vraagt de "communicatie" component een aantal dingen (al dan niet gedelegeerd aan weer andere componenten):
- hoe wil de database van de leverancier dat er met hem gecommuniceerd wordt?
- wie kan hem een verbinding leveren die aan bepaalde eisen voldoet, zoals snelheid, beveiliging, het kunnen communiceren met de database van de leverancier zoals opgegeven?

Op dat moment biedt een component (als "hoofdaannemer" van een samenspel van componenten) zich aan, of misschien wel meerdere " hoofdaannemers". De "communicatie" component maakt een keuze (of legt die keuze voor aan de gebruiker, want misschien staat de artikelen database van de leverancier zowel locaal, als bij de leverancier, bijvoorbeeld. Alleen loopt die locale een dag achter en vindt de gebruiker dat helemaal niet erg, want de aangeboden verbinding met de leverancier is nogal traag). Als de keuze gemaakt wordt en de verbinding gelegd, zit daar "ergens" een component tussen die weet heeft van de toegang tot internet, de "internet" component. En alleen DIE hoeft te weten hoe internet werkt, en alleen DIE hoeft te worden aangepast als dat verandert (of krijgt er een zusje bij die de verandering ondersteund, zodat de "oude" manier ook beschikbaar blijft). En nog beter: die "internet" component kan door meerdere "hoofdaannemers" worden gebruikt! 1 keer programmeren, altijd hergebruiken!

Het is inderdaad een concept, maar 1 die al zo'n 40 jaar bestaat: object geori?nteerd programmeren of component gebaseerd programmeren (en nog wat termen). Alleen heeft dat tot nu toe nooit tot zijn volle potentie kunnen komen, omdat je altijd te maken kreeg met afhankelijkheden. De weg die tot nu toe bewandeld is om dit concept te realiseren, is door frameworks en andere zaken BOVENOP de programmeertaal te leggen. Laag op laag. De afhankelijkheden stapelden zich op, in plaats van dat ze verminderden. En de performance loopt terug en je hebt enorme libraries nodig. Kijk bijvoorbeeld naar Java. Je zou zeggen toch redelijk platform onafhankelijk. Maar je moet wel een dikke 100 Mb of meer installeren, afhankelijk van wat je wilt / nodig hebt, voordat het werkt. En supersnelle transactie systemen moet je er niet mee willen bouwen of vlotte mobiele applicaties. En die platform onafhankelijkheid? De deskundigen zijn het er allemaal niet over eens. En als je even niet oplet, programmeer je niet meer volgens het concept, of je doet het bewust vanwege performance of omdat het wel zo makkelijk en/of snel is. En weg is je concept en je flexibiliteit.

Wat wij gedaan hebben is vanaf scratch beginnen. Wat wil je nou eigenlijk bereiken:
Te allen tijde FLEXIBEL zijn en blijven!
De mogelijkheid hebben om:
- Elk ontwerp, algoritme, interface of tool
- Op eender welk moment voor, tijdens en na het project
- Voor zo laag mogelijke kosten te kunnen wijzigen!

Het geschetste concept biedt dat en het is gelukt dat concreet te maken. Onze "basis" installatie is 50kB groot (kleiner dan een foto op je mobiel) en kan naar zo goed als elk OS worden geporteerd. Het draait nu op Unix, Linux, Windows en Windows mobile. Het draait vlak "bovenop" het OS of eigenlijk "erin". En "daarboven", of "ernaast", komt direct de programmeertaal van jou keuze (zowat alle programmeertalen kunnen er mee werken als ze maar aan C-binding e.d. doen en dat doet bijna elke taal). Iedere programmeur kan er in zo'n 5 dagen mee leren werken. En kan dan volgens het geschetste concept programmeren. En ons systeem "dwingt" dat concept af, je kunt niet anders. Als je ons "systeem" kost je dat zo'n 1% performance ten opzicht van het direct in de programmeertaal programmeren en daar krijg je heel wat voor. Dat het maar 1% kost, komt doordat de verbindingen tussen de componenten rechtsreeks gelegd worden (peer tot peer) en niet via een "bus". Het "basis" component initieert de verbinding maar bemoeit zich er verder niet meer mee. Hij weet wel dat die verbinding bestaat (en kan ingrijpen), maar de communicatie tussen de componenten verloopt rechtstreeks. Die "bus" is 1 van de problemen van de huidige uitwerking van het concept:
- het vormt al snel een bottleneck, vooral als je veel componenten hebt, die veel data snel uitwisselen,
- je cre?ert weer een afhankelijkheid, want je moet voldoen aan de spec's van die bus.

En zoals je nu wellicht al wel berijpt, kan ons "systeem" (groot woord voor 50k) met elk soort "bus" communiceren, want je bouwt "gewoon" een component die het kan en alle componenten kunnen immers met die "bus" communiceren. Ze weten immers niet dat ze met die "bus" communiceren. Alleen die "bus" component weet dat. Dit cre?ert mede die gewenste onafhankelijkheid van interface of tool.

De technologie bestaat dus wel degelijk. En is zeer krachtig, maar dat hoef ik denk ik niet meer uit te leggen? Bedenk voor jezelf maar eens wat dit zou kunnen beteken. De technologie is inderdaad vrij nieuw. Het grootste "probleem" is dat het zo'n andere manier van denken en werken is, dat mensen er niet zo gauw aan willen of durven. Ze kunnen de impact niet goed overzien. Bovendien is het funest voor de gevestigde bedrijven die op uurtje factuurtje basis werken: hoe meer IT problemen, hoe meer omzet. Degene die gebaat is bij de IT problemen, wordt gevraagd ze op te lossen. Met meer uurtjes ertegenaan gooien, upgrades en onderhoudscontracten om fouten die ze zelf gemaakt hebben op te lossen (zie mijn eerdere bijdragen) enz.

Veel IT problemen bestaan met onze technologie eenvoudigweg niet. Net zoals een auto geen last heeft van wisselstoringen, het hoort gewoon niet bij het concept auto. Het cre?ert wel uitdagingen:
- hoe ga je om met gebruikers die zelf meer aan het (IT) stuur zitten?
- hoe ga je om met gebruikerswensen? "Alles" is immers mogelijk en snel en goedkoop te realiseren.
- wat wordt de rol van de IT leverancier, zowel intern als extern?
- hoe ga je om met het feit dat elke gebruiker zijn eigen implementatie en versie heeft van het systeem? Wat voor consequenties heeft dat?
- hoe ga je om met het veranderde project- en release management? Je hebt immers geen (grote) releases of upgrades meer, alleen op componentniveau en nog wel met software hotswap. Dus die nieuwe functionaliteit is er "opeens".
- wie is eigenaar van de nieuwe functionaliteit? De gebruiker, de component bouwer (zowel intern of extern). Wil je die nieuwe functionaliteit met collega's delen (zowel intern, als extern (eventueel de "concurrent"))?
- ?

En het mooie is: je kunt legacy applicaties ook "omzetten" naar onze technologie, zonder aan de code te komen. Ideaal om de spaghetti in/van applicaties, interfaces e.d. te ontwarren en je legacy volop mee te laten doen / draaien in je moderne IT omgeving. En je kunt eventuele tekortkomingen van de legacy aanvullen of verbeteren (upgraden), zonder dat je precies hoeft te weten hoe die legacy in elkaar zit, of dat je de programmeertaal van die legacy moet beheersen.

Jacco Hiemstra
www.produrion.nl

@Jacco Hiemstra

Je zegt nu "Je moet uiteindelijk kleur bekennen, met de billen bloot, concreet worden naar inderdaad een database, OS, netwerkverbinding etc. Ontken ik niet, maar doe dat zo laat mogelijk. Niet al bij het "begin" van de functionaliteit."

Ik ben verheugd dat je deze toegeving doet. Uiteindelijk is alle functionaliteit afhankelijk van een fysieke infrastructuur, al zijn er de laaste tijd veel SaaS aanhangers die verwijzen naar een abstractie als "de cloud"

Ik ga er dan hierbij ook van uit dat je noodzaak van maintenance acties inziet. Immers, niemand neemt het risico om het support van de leveranciers te verliezen omdat een applicatie/OS/database/firmware niet meer wordt gepatcht. Bovendien bestaan er meestal combinaties van en afhankelijkheden tussen de versies van deze IT architectuur componenten. Jouw suggestie dat er bedrijven zijn die desondanks toch bereid zijn om dat risico te nemen doordat jouw concept hen daartoe in staat zou stellen, is wellicht iets te optimistisch. Planned downtime is het gevolg van de noodzaak om te patchen. Met elke nieuwe versie worden vaak honderden technische problemen aangepakt. Velen daarvan hebben een directe invloed op de functionaliteit, bijvoorbeeld omdat zij een invloed hebben op de performance en/of capaciteit van de applicatie.

Het is mij nog niet duidelijk waar precies je de grens legt tussen functionaliteit en de IT architectuur.
Ik krijg de indruk dat je de objecten en hun instanties als de representatie van de functionaliteit zelf ziet, klopt dat wellicht ? In dat geval zeg jij dat je de functionaliteit aanpast, terwijl je in werkelijkheid de objecten aanpast die die functionaliteit leveren.
Een semantisch trucje dus, want in werkelijkheid zit je gewoon code aan te passen. Ik schaar die code onder de IT architectuur en beschouw de code niet als functionaliteit.

Verder zijn er in jouw model toch wijzigingen in functionaliteit denkbaar die een invloed hebben op meerdere. Stel bijvoorbeeld dat bij het plaatsen van een bestelling er voortaan ook rekening moet worden gehouden met de kwaliteit van het artikel. Van de 3 artikelen met de beste kwaliteit moet de goedkoopste worden besteld.

In jouw programmeermodel komt dat neer op het veranderen van een aantal objecten. De "bestelcomponent" krijgt nu 1 attribuut per artikel meer te verwerken, namelijk de kwaliteit van het artikel. Hierdoor verandert de interface van dat object. Bovendien moet er binnen deze component een soortering op prijs gaan plaatsvinden van de artikelen die gevonden zijn door de "leveranciercomponent". De "leveranciercomponent" ondergaat ook een verandering in de interface omdat er een nieuw attribuut (kwaliteit) moet worden teruggegeven aan het aanroepende object.

Er bestaat dus een direct verband tussen een verandering in functionaliteit en de objecten die deze functionaliteit verzorgen.

Dan heb je nog de implementatie van jouw wijzigingen, die volgens jou in een draaiend systeem kan plaatsvinden zonder een verstoring van de functionaliteit. Stel je voor dat je een ERP systeem hebt met 3000 actieve wereldwijde gebruikers (voor een SAP systeem niet ongewoon), en dat je bovengenoemde wijziging in het systeem gaat aanbrengen.
Hoe denk je de nieuwe objecten te kunnen aanbrengen terwijl er duizenden instanties van de oude objecten zich in het applicatiegeheugen bevinden ? Denk je nu eens in dat een oude "bestelcomponent"
een nieuwe "leveranciercomponent" oproept of andersom. Je suggereerde eerder dat dat kon plaatsvinden zonder verstoring van de functionaliteit. Denk je daar nog steeds zo over ?

De "bijdrage" van Jan van Leeuwen was mij ook al opgevallen. Hij probeert "argumenten" op te voeren tegen SAP welke geen hout snijden. Iedere voorstander van SAP is een tegenstander voor van Leeuwen. Dat is wel duidelijk uit zijn reakties.

"Dat hadden we al jaren geleden en iedere automatiseerder die een basiscursus doet leert dat juist dat de verkeerde weg is. Past de software niet bij de organisatie moet je andere software kiezen."

Waar is deze basiscursus gevolgd? Werkt u zelf alleen maar met software die bij u past? Wel eens gehoord van een kosten baten analyse? Waar is de realiteitszin?

Ook lijkt het de praktijk van dhr van Leeuwen om het financiele belang van zijn organisatie boven het klantbelang te stellen. Dat is blijkbaar zijn realiteit. Het advies om dit niet te doen doet hij af als niet getuigen van realiteitszin.

"Ja hebben we dan niets geleerd? Geen SDM 1 of 2 of hoe het vandaag de dag mag heten? IEDERE implemantatie moet gefaseerd doorgevoerd worden, als je een groot softwarepakket plotseling in een organisatie plempt, dan richt je schade aan. Die "implementatoren" die dat doen zouden voor de schade moeten opkomen."

Heer van Leeuwen weet niet hoe dit vandaag de dag mag heten (in ieder geval geen implemantatie als we het toch over taalgebruik hebben). Lees nog eens goed de mening van Erwin Dekker. Hij heeft het m.i. over iets anders dan wat Jan denkt te lezen. Bepaalde functionaliteit van SAP wordt geimplementeerd in ??n brok volgens een projectplanning (bij SAP is dat veelal Prince 2 in combinatie met de ASAP methodiek), vervolgens kan je een volgend functioneel brok implementeren. Dat vind ik een verstandig advies. De meeste klanten willen in ??n keer veel te veel en dat is veelal onverstandig.

"Na dit tweede artikel moet een klant zich toch ernstige zorgen maken over de "expertise" van deze mensen. Iedere zichzelf respecterende automatiseerder moet toch een minimum talent hebben op gebied van projektplanningen anders moet je een ander beroep zoeken en zo voorkomen dat je klanten in de ellende stort."

De projecten zijn niet fout gelopen door een foute projectplanning.

@Bram en @Jacco,

Zo... Ik was een paar dagen niet op deze site en het duurde dan ook even om door jullie zeer inhoudelijke discussie heen te komen. Het concept dat Jacco verwoordt kan ik tot op zekere hoogte begrijpen. Echter niet voldoende om daar een goed oordeel over te kunnen vormen. Als ik ergens terecht kan voor een uitgebreidere beschrijving, houd ik me daarvoor aanbevolen.

Ik begrijp Bram ook, die de abstracte utopische weerspiegelingen van Jacco graag geconcretiseerd ziet. Om eerlijk te zijn worstel ik daar ook wel mee.

Ieder systeem heeft tot doel bepaalde processen te ondersteunen of zelfs uit te voeren. Om dat te kunnen, werken we met modellen. Deze modellen representeren deze processen in hun meest abstracte vorm en bieden ruimte tot een eigen invulling van dergelijke processen. Ik noem dat invullen voor het gemak maar even configureren. Daarmee wordt de grootste gemene deler van alle processen (het model) vertaald in een concrete representatie. Ik heb het hier nog niet over techniek. Techniek is echter nodig om gegevens daadwerkelijk te kunnen opslaan, verplaatsen, verwijderen, presenteren etc. Die technische oplossingen KUN je ook vangen in een model. Daartoe moet je technologieen vertalen naar modellen en moet je diezelfde technologieen kunnen laten luisteren naar die modellen zodat bij de invulling van het model, zich als het ware automatisch een technische implementatievorm uitvouwt. Dat is mogelijk en wordt (in een weliswaar zeer starre vorm) ook toegepast.

Wat ik bij deze wil bestrijden is dat een object georienteerd model al onze processen kan omvatten. Objectorientatie is een hierarchische aanpak die zeer krachtig is. Onze wereld zit echter objectgeorienteerd EN relationeel in elkaar. Daar kun je niets aan veranderen. Natuurlijk streven we er zoveel mogelijk naar om onze werkelijkheid hierarchisch te presenteren omdat dat dat ons de mogelijkheid tot generaliseren biedt en op dat concept zijn onze hersenen nu eenmaal gebouwd. Voor ik helemaal afdwaal: mijn visie is dat modellen het fundament van een systeem vormen en dat er daarbinnen een hierarchie noodzakelijk is die gebaseerd is op abstractie. Het bestaan van modellen maakt het voor ons mogelijk om met elkaar te communiceren. Modellen zorgen dus voor een gemeenschappelijk "wereldbeeld". Dat laatste mis ik in het verhaal van Jacco. Wie onderhoudt dit model? Je uitleg roept bij mij het gevoel op van een netwerk van samenwerkende cellen/processen, waarbij modellen in expliciete vorm niet meer terug te vinden zijn en ownership t.a.v. deelmodellen en de controle daarop niet meer mogelijk is. Dat is een situatie die niet wenselijk en niet te verkopen is.

Het gedrag van het systeem moet te allen tijde zijn gebaseerd op modellen waarop een vorm van ownership en release control van toepassing is. Daar is wat mij betreft een rol weggelegd voor IT-professionals (intern dan wel extern). De modellen die bekende processen beschrijven zijn al in grote mate geevolueerd en daarom al jaren vrij statisch.

Aan de andere kant is er de technologie en de daaraan gekoppelde modellen die deze technologie moeten ondersteunen. Daar zit een grotere mate van dynamiek, hoewel veel principes niet nieuw zijn. Op dat vlak is mijns inziens de grootste IT-rol weggelegd.

De eerste categorie aan modellen (de modellen van de kernprocessen) vormen het erfgoed dat decennia lang mee kan gaan. Kleine wijzigingen vormen het evolutieproces.

De tweede categorie aan modellen ondersteunt de technische implementatievormen waarvoor gekozen wordt. De dynamiek daarin is groter. Hierin kom je datawarehousing, BI, web technology, OPC, XML etc. tegen.

10 jaar geleden zijn we deze weg ingeslagen. We passen op bijna dagelijkse basis hotswaps toe, maar dat is blijft zeker een uitdaging: testen onder diverse omstandigheden blijft altijd noodzakelijk en gebruikers willen ook niet verrast worden met "zomaar" iets nieuws.

Maar... Ik ben een grote voorstander van de scheiding van model en techniek. Koester het model van de kernprocessen. Onderhoud en bewaak dat met je leven! Dat bepaalt de levensduur van een systeem. Een technologische oplossing kun je daar tegenaan modelleren. Laat deze 2 modellen zich NOOIT vermengen. Dat is het begin van het einde.

We draaien sinds 1999 24/7 (= full time) en laten de omvang van de kernprocessen geleidelijk groeien. Daarbij beperken we ons echter tot de processen waarvoor wij ownership hebben.

Het betoog van Jacco gelezen hebbende, denk ik dat onze ideeen in grote mate bij elkaar aansluiten. De kanttekeningen die Bram plaatst, zijn zeker niet alleen ?het nog niet snappen?. Die kanttekeningen zijn re?el en worden denk ik ook al wel onderkend door Jacco in de vorm van ?uitdagingen?.

De laatste reactie van Jan van Leeuwen vond ik overigens niet erg gepast. Je voert een discussie op inhoud en niet op syntax. Dat laatste doe je pas als de inhoudskaarten op zijn. We zijn tenslotte wel mensen en geen computers?

@Bram,

Ik weet niet of dit de plek is om er heel diep (technisch) op in te gaan, maar ik doe een poging het zo niet-technisch mogelijk te houden en per item te reageren.

* Het stukje "maintenance": dit is uiteraard in (bepaalde gevallen) noodzakelijk. De grootste beveiligingsrisico's / problemen ontstaan immers vaak door niet (tijdig) patchen. Alleen de vraag is: moeten gebruikers daar "last" van hebben. Of anders: hoe doe je dat met zo min mogelijk overlast voor de gebruikers. En waar wordt de noodzaak door ingegeven: technisch (oplossen van problemen) of omdat de leverancier (zo nodig) nieuwe features moet bieden, waarbij het de vraag is of de klant er echt om zit te springen (ik kan prima een briefje tikken in Word 97, daar heb ik geen Word 2007 voor nodig). Nu is dat vaak een package deal. Je krijgt een nieuwe release met opgeloste problemen en nieuwe features tegelijk, je kunt niet kiezen en je moet mee op straffe van het verliezen van support. Gedwongen winkelnering dunkt me. Ik moet de aannemer nog tegenkomen die het lukt om met het repareren van de badafvoer, meteen een nieuwe badkamer mee te verkopen, op straffe van dat het anders niet gerepareerd wordt.

En ik blijf erop hameren: technische zaken als performance, en laten we daar bugs e.a. problemen ook even onder scharen voor het gemak, staan los van en moeten los staan van de pure functionaliteit. Doordat techniek en functionaliteit nu vaak aan elkaar geklonken zitten, krijg je inderdaad het fenomeen, dat als je technisch problemen in de applicatie aanpakt, dat invloed heeft op de performance en andersom als je het niet doet.

Ik suggereer niet dat bedrijven risico's willen of moeten nemen: juist niet. Door de geschetste modulaire aanpak loop je veel minder risico's! Ga maar na: doordat techniek en functionaliteit zowel gescheiden van elkaar zijn, als verspreidt over verschillende componenten die onafhankelijk (!) van elkaar opereren, blijven problemen meestal "regionaal" beperkt tot 1 of enkele componenten. En dus ook de upgrades. Daarbij heb je dus geen grote monoliete systemen, die in 1 keer ge?pgrade moeten worden en dus down moeten. De gebruiker heeft er geen (zo min mogelijk) last van.

Met de geschetste modulaire aanpak heb je geen downtime nodig (voor de gebruiker). Als je bijvoorbeeld een grote database gebruikt voor allerlei belangrijke gegevens, dan voer je die (uiteraard) redundant uit. Tijdens de upgrade van de ene, is die dus niet beschikbaar voor componenten die erom vragen, maar de andere wel. De "oude" met de "nieuwe" synchroniseren (als het goed is zijn ze voor de upgrade synchroon) en dan de andere upgraden. Heb je bijv. datamodel verschillen, dan gebruik je coercion componenten, met "tussentabellen", die even tijdelijk de lacunes van het "oude" datamodel opvangen tijdens de synchronisatie. Als de "oude" database is ge?pgrade en (ook) het nieuwe datamodel bevat, voltooi je de synchronisatie. Ondertussen heeft de gebruiker niets gemerkt. Heb je "maar " 1database (server), dan kun je het onderstaande scenario voor een OS gebruiken.

Hetzelfde geldt bijv. voor een OS. Als je "maar" 1 server hebt, zet je er tijdelijk (gehuurd?) een andere (ge?pgrade) naast. Je kopieert je hele "componenten wolk" naar die andere nieuwe server. Zet die applicatie op de nieuwe server in "slave mode" en laat de hele productie daar ook door lopen. De testers kunnen dan testen of alles het nog goed doet met het nieuwe OS. Ondertussen draait de productie gewoon door op de oude server in "master mode". (Het verschil tussen master en slave mode is dat de output / "impact" bij de slave "niet naar buiten gaat". Verder zijn de omstandigheden hetzelfde: de ideale test situatie!). Als de situatie op de nieuwe server goed is bevonden switch je de master - slave verhouding om. De productie loopt door op de nieuwe server in master mode terwijl de oude ge?pgrade wordt. Is de nieuwe situatie op de oude server goed bevonden switch je de master - slave verhouding om, et voila, de productie draait op een ge?pgrade server. De tijdelijke server kan terug. Heb je 2 of meer servers, dan kun je hier heel creatief mee omgaan. Bij 2 servers gaat de performance wel om laag als je tijdelijk van 2 servers 1 maakt. Is dit een probleem, schakel je een extra (gehuurde) server bij. Hoe meer servers je hebt, hoe minder dit een probleem hoeft te vormen.

Al met al is het leven van een IT-er zo heel interessant en bevredigend, om uit te dokteren hoe hij achter de schermen alles soepeltjes kan laten verlopen, patchen, migreren, upgraden etc., zonder dat de gebruiker er "last" van heeft of niet kan werken.

* Het stukje "grens functionaliteit en architectuur": dit is een heel interessante. Sommige componenten fungeren (inderdaad) als een soort proxies: de component biedt zich aan als zijnde iets te kunnen, maar is eigenlijk "leeg" en geeft alleen maar iets door van "iets anders". Wat heb je daar nou aan zul je wellicht denken. Dit is uiterst krachtig, want ga maar na: terwijl je aan de "voorkant" iets aanbiedt, kun je er aan de "achterkant" van alles achter zetten, zonder dat iemand er iets van merkt. Zo kan die "proxy" component fungeren als een soort schakelaar (bruikbaar bij bijv. master - slave zoals eerder geschetst). De ene keer schakelt hij naar de ene situatie om de gevraagde functionaliteit te leveren, de andere keer naar de andere situatie. Of ze kunnen fungeren als een soort "hoofdaannemer" component die, om zijn functionaliteit te kunnen leveren, allerlei andere functionaliteit aanvraagt. In wezen gebeurt er in die " hoofdaannemer" component niet zo heel veel. Vooral een stukje co?rdinatie, de rest gebeurt in de andere componenten die zich aanbieden. Die op zichzelf ook weer proxy componenten kunnen zijn. Zo componeer je een hele applicatie, waarbij het "echte werk" zo "laat mogelijk" en dichtbij de technologie gebeurt. Heel krachtig, snel en effici?nt. Immers hoe dichter op de hardware / technologie hoe sneller programma's lopen.

Let hierbij nog even goed op: componenten roepen niet andere componenten op! Dit zou immers betekenen dat ze van hun bestaan zouden moeten afweten. Nee, ze vragen om functionaliteit (functionele interface) en krijgen die aangeboden. Het is dus meer dan een semantisch trucje. Daarbij: code kun je naar mijn idee niet ergens onder scharen: functionaliteit of architectuur of techniek. Met de code bouw je zowel de techniek (OS, communicatie, database etc.), als de pure functionaliteit. Vergelijkbaar met steen, hout, metaal, enz. Die zijn zo fundamenteel, zonder dat bouw je niks. Het hoort overal of nergens bij.

* Het stukje "attribuut kwaliteit": uiteraard veranderen hier de componenten. Alleen moet je heel goed opletten (maar eigenlijk gaat dat "vanzelf", zoals je gewaar zult worden in deze alinea). Je weet immers niet welke componenten nog meer van de bestel en leverancier componenten gebruik maken! Dat is juist de kracht van het systeem! Je hoeft je niet druk te maken over (verborgen) relaties, je houdt je alleen bezig met die relaties die voor jou van belang zijn (tussen de bestel en de leverancier component in dit geval). Maar dat doe je op dusdanige wijze dat andere componenten, die om de bestel of leverancier functionaliteit vragen, het niet merken. Anders krijg je te maken met verborgen relaties (je weet immers niet welke componenten hier nog meer gebruik van maken), en dat is nou juist de pest van veel software: die verborgen relaties! Dus je doet het volgende: je behoudt de oude interface (zonder het nieuwe "attribuut kwaliteit"). Daarnaast maak je op dezelfde component een nieuwe interface die identiek is aan de oude, maar dan wel met het nieuwe "attribuut kwaliteit". De code van het component pas je aan zodat hij ook het nieuwe "attribuut kwaliteit" kan verwerken, naast het oude. Dit werkt zo door in alle componenten die voor jou proces van belang zijn. Zolang componenten (inclusief "jou" bestelcomponent) vragen om een leverancierscomponent die de oude set gegevens kan leveren, antwoord de leveranciercomponent met de oude interface. Op het moment dat "jou" bestelcomponent vraagt: wie kan mij artikel gegevens leveren (met het nieuwe "attribuut kwaliteit"), antwoord de leveranciercomponent met de nieuwe interface. Jou nieuwe situatie werkt naar behoren, maar ook alle andere situatie waar jij geen weet van hebt en ook niet van hoeft te hebben!

Heerlijk toch, voor zowel projectmanagers, architecten, programmeurs, testers als "outsourcers"? Je kunt je concentreren op dat stukje functionaliteit ge?mplementeerd in een componenten set, wat voor jou van belang is (projectmanagers, architecten en testers) of dat component dat jij onderhanden moet nemen (programmeur). De rest is volstrekt niet van belang en werkt als voorheen. Geen afstemmingsoverleg anders dan over de onderhavige functionaliteit, geen uren bestuderen van de documentatie en / of broncode van hoe het ook alweer in elkaar zat (ik heb me laten vertellen dat daar soms wel meer dan de helft van de tijd in gaat zitten). Zeker een probleem als de oorspronkelijke programmeurs niet meer beschikbaar zijn.

* Het stukje "implementatie": je kunt nu bovenstaande extrapoleren. Uiteraard werkt dit alleen als een applicatie is opgebouwd als beschreven (optimaal flexibel)! Je hebt de oude bestel component in geheugen. Je doet de nieuwe bestelcomponent ook in geheugen (en alle andere bijbehorende ivm. de "attribuut" wijziging). De bestel component staat aan de top van die keten. Op het moment dat iemand om bestel functionaliteit vraagt, zet je er een proxy bestel component tussen, of die "vrager" fungeert zelf al als proxy. Nu heb je een switch, die kan schakelen tussen de oude en de nieuwe situatie. Elke keer als een instantie "los" laat van de "oude" component, laat je bij een nieuwe vraag alleen de nieuwe situatie reageren. Samen met de boven beschreven coercion kun je zo een smooth migration organiseren, zonder dat het systeem plat moet. Dit is natuurlijk een ideale situatie. In de praktijk kan het wel eens voorkomen dat bepaalde instanties te lang duren, waardoor zaken uit sync. kunnen raken die je ook met de boven beschreven coercion niet meer kunt oplossen / overbruggen. Het systeem is zich bewust van die instanties en je kunt daar op ingrijpen. Je kunt de gebruiker bijv. (eventueel van te voren) een bericht sturen dat hij voor een bepaalde tijd even uit die bepaalde functionaliteit moet om een upgrade te kunnen doen. Hij hoeft niet uit de hele applicatie, maar alleen uit een stukje. Of je doet een geforceerde upgrade op die instantie die te lang duurt. Er zijn situaties waarin de software hotswap toch wat kost (voor niets gaat de zon op). Maar je kunt de implementatie en upgrade impact zo enorm terug brengen.

En nog een interessante feature: onderhoud op functionaliteit, niet op code (ook bij legacy). Stel: in de loop der tijd is je IT systeem gegroeid. Stukken zijn 20 jaar oud, stukken zijn nieuwer. Van alle componenten is bekend wat er van verwacht wordt (functionele interface, zou ik altijd goed beschrijven). Hoe die functionaliteit uiteindelijk in code tot uitdrukking is gekomen is niet van belang (wel handig, want dan kun je sneller aanpassen als je mensen in huis hebt die de gebruikte programmeertaal beheersen). Sterker nog, je hoeft niet eens over de broncode te beschikken (wederom wel handig, want ?). Stel dat je op een bepaalt moment besluit dat een component moet worden aangepast of je ontdekt een fout die moet worden opgelost en je verkeert in 1 of meer van de volgende omstandigheden:
- je beschikt niet (meer) over de broncode, je hebt alleen een runt-time / gecompileerde versie o.i.d.,
- je beschikt wel over de broncode, maar die is (te) slecht gedocumenteerd, of je mag er niet aanzitten (intellectueel eigendom),
- je beschikt wel over de broncode, maar niet (tijdig) over de programmeurs die de programmeertaal (voldoende) beheersen of die zijn (te) duur, of de programmeertaal is "domweg" te oud en niet meer in gebruik.
Omdat je wel beschikt over de beschrijving over wat die component moet doen (functioneel), bouw je die component "gewoon" opnieuw in de programmeertaal die jou het beste schikt op dat moment. En dat kost niet zoveel (tijd, geld). Want als je je applicatie een beetje slim hebt opgebouwd, bevatten componenten niet al teveel code (koste je immers weer flexibiliteit). Heb je toch "toevallig" componenten die bestaan uit bijv. honderduizend(en) regels code, kun je die altijd nog opdelen in kleinere componenten. Maar dan moet je nog wel enigszins begrijpen wat er in de code gebeurt, om dat component zinvol op te kunnen delen. Dat opdelen gebeurt dan overigens zonder dat je een stukje code hoeft aan te passen! Dus je moet begrijpen wat er in de code gebeurt, je hoeft niet in die programmeertaal te kunnen programmeren. Dit allemaal is heel handig als je je legacy applicaties wilt moderniseren en die zijn niet (goed) gedocumenteerd of je beschikt niet meer over programmeurs die de gebruikte taal beheersen. Of je IT systeem zit vol met (ongedocumenteerde) interfaces en verborgen relaties. Je kunt je systeem zo ontwarren zonder dat je systeem als mikado in elkaar stort als je ergens aanzit.

P.S. ik had gedacht deze bijdrage kort te houden, maar het lijkt wel of ze steeds langer worden ;-)
P.S. 2 op Johan reageer ik graag op een ander moment.

Jacco Hiemstra
http://www.produrion.nl

@Jacco


#
Definitie functionaliteit

Ik heb mijn standpunt over de scheiding tussen functionaliteit en implementatie toch wat scherper bijgesteld. Ik definieer functionaliteit als iets wat de gebruiker ervaart, een set diensten die geleverd wordt door de IT-architectuur die dan weer bestaat uit een hardware laag en diverse software lagen.

In die zin betekent een verandering in de IT-architectuur, hoe miniem ook, ook ALTIJD een verandering in de functionaliteit. Of de gebruiker iets van die verandering in functionaliteit ervaart, is eigenlijk irrelevant. Het zou hier bijvoorbeeld kunnen gaan om een verbeterd encryptie-algoritme, dat de gebruiker niet zelf ervaart, maar wel een verandering in functionaliteit betekent.

Met betrekking tot die verandering in functionaliteit, is het ook niet relevant dat de softwarecomponenten hoog in de aanroep-hierarchie (bijvoorbeeld de "bestelcomponent") iets van die verandering merkt, in de zin dat ze wel of niet moeten worden aangepast. Het gaat hier om het geheel, de som van de hard en software componenten waaruit de IT architectuur bestaat. Het is het geheel dat de functionaliteit levert aan de gebruikers.

Funcionaliteit en de implementatie ervan zijn niet los te koppelen van elkaar, net zoals de betekenis van een
boek ervaren wordt door een lezer. Dat boek bestaat uit een organisatie van hoofdstukken die elk weer bestaan uit alinea's, zinnen, woorden en letters. Naarmate je je op een lager niveau afdaalt, verlies je het verband met de betekenis voor de lezer.

# Objectorientatie is slechts een methode om software te organiseren

De manier waarop je software organiseert, procedureel of objectgeorienteerd, heeft alleen invloed op de hoeveelheid werk die zo'n verandering met zich meebrengt. Het is waar, een objectgeorienteerde organisatie van software is wat efficienter te onderhouden dan een procedurele brei spaghetticode.
Maar ook objectorientatie kent zijn nadelen. In een SAP systeem met zijn vele duizenden classes, interfaces en methoden is het vaak flink zoeken naar de component die verantwoordelijk is voor een bepaald stukje functionaliteit. In zulke gevallen wordt vaak het wiel uitgevonden en ontstaan er vrijwel identieke componenten omdat de programmeur niet beseft dat er al iets bestaat dat hij kan (her)gebruiken.

Verder zijn er andere wijzigingen denkbaar, bijvoorbeeld in het onderliggende datamodel, die een grote invloed kunnen hebben op vele componenenten, bijvoorbeeld de lengte van een veld dat een bedrag geld moet opslaan kan invloed hebben op alle componenten die ermee rekenkundige bewerkingen plegen.

# Verdere optimalisatie van software

Kijk eens naar het MVC (Model View Controller) concept dat weer een andere manier heeft om software te organiseren. Wikipedia heeft er een duidelijk uitleg van. Ook SAP kent dit concept en streeft ernaar om de procedurele broncode te vervangen door object-georienteerde (webdynpro)componenten die het MVC cocept implementeren ( google: "SAp MVC" ). In het MVC concept is het ontwerp van complexe toepassingen opgedeelt in drie eenheden met verschillende verantwoordelijkheden: datamodel (model), datapresentatie (view) en applicatielogica (controller). Het scheiden van deze verantwoordelijkheden bevordert de leesbaarheid en herbruikbaarheid van code.
Het is dus niet de scheiding van functionaliteit en IT-architectuur die je als programmeur kan nastreven
, want dat zijn 2 fundamenteel verschillende zaken. (zie mijn "definitie" hierboven). Je applicatie is direct verantwoordelijk voor die functionaliteit en je kan er hooguit voor zorgen dat die applicatie ten aanzien van het noodzakelijke onderhoud zo efficient mogelijk is georganiseerd, door bijvoorbeeld het MVC concept te hanteren.


# Implementatie van veranderingen

Het "injecteren" van software veranderingen in een draaiend systeem is in principe mogelijk. In een SAP systeem kan je gewoon software transporten "inspelen" terwijl de gebruikers actief zijn. In een druk systeem zijn er dan vaak dumps waar te nemen die worden veroorzaakt omdat software op schijf verschilt van de runtime versies ervan. Je zou er ook voor kunnen kiezen om die software op een rustiger tijdstip te kunnen vervangen.
Het gebruik maken van een shadow database in het geval van conversies of upgrades is een techniek die in de SAP wereld al een tijdje voorkomt. In feite maak je hierbij gebruik van redundantie, net als het geval is bij een reloceerbare service, een cluster etc., om het gebruikersongemak te beperken.
Redundantie heeft echter zijn prijs. Een verbouwing in een huis zal ook met het nodige ongemak gepaart gaan. Een tijdelijk onderkomen kan daarbij uitkomst bieden, maar kost ook het een en ander.
Verder kent het faciliteren van oudere versies van componenten zijn grens. Als de nieuwere componenten aanroepen van oudere interfaces moeten blijven aankunnen, dan wordt de software trager en ook duurder om te onderhouden. op een gegeven moment zal je de band met het verleden moeten doorknippen. Ook jij zal die grens ergens moeten trekken.

# functionaliteit van software en huis vergelijken

Wanneer je de functionaliteit van software en die van een huis vergelijkt zul je zien dat de functionaliteit van een huis weining varieert in de tijd, ja zelfs in het geheel niet veranderd.
Software daarentegen
moet continu veranderen om tegemoet te komen aan de eisen van de (zakelijke) context waarin zij wordt gebruikt.
Het zijn juist die continue veranderlijke eisen ten aanzien van de functionaliteit die tot veranderingen in de software leiden en niet andersom, zoals jij dit toch een beetje doet voorkomen. Je kunt die veranderlijke eisen een beetje vergelijken met een krankzinnig stedebouwkundig beleid dat bijvoorbeeld bepaald dat huizen iedere week een andere kleur moeten hebben.

@Johan

Je schets van "een netwerk van samenwerkende cellen/processen, waarbij modellen in expliciete vorm niet meer terug te vinden zijn", herkende ik ook en voelde er mij ook niet gemakkelijk bij. In een SAP applicatie is elke gebuikersactie transactiegeorienteerd. Voor elke transactie bestaat een vaste volgorde van schermen, als het ware een dialoog die het systeem aangaat met de gebruiker.
Ouderwets wellicht, maar het zorgt wel voor een bepaalde structuur en indeling van de software, waarin een nieuwe programmeur rdelijk gemakkelijk zijn weg kan vinden. Omdat ik wel eens programmeer in een SAP systeem, vind ik persoonlijk dat programma's die objectgeorienteerd zijn, lastiger te debuggen als procedureel geschreven code, maar dat zal wel aan mijzelf liggen !

Dit artikel beschrijft op hoofdlijnen de verantwoordelijkheden van de verschillende partijen bij een SAP implementatie. De klant realiseert zich onvoldoende wat de impact van een ERP implementatie op zijn organisatie is en laat zich lastig 'managen' door implementatiepartner en SAP. Ook is er aandacht voor de rol die de implementatiepartner zou moeten hebben om mislukkingen te voorkomen. 'Hij moet onhaalbare voorstellen van klanten durven te weigeren en het financi?le belang dat hij heeft buitenspel kunnen zetten.' De directeur van SAP Nederland en de drie Computable-experts zijn het er op grote lijnen over eens dat de verantwoordelijkheid voor een geslaagde SAP implementatie bij zowel de implementatiepartner als de klant ligt. En natuurlijk is dat zo!

Wat ik mis in het artikel is een verdere uitwerking van de terloops genoemde 'onafhankelijke derde partij'. Is een andere 'waarheid' immers niet dat de waarde van een 'Quality Insurance' valt of staat bij objectiviteit, onafhankelijkheid en feiten? Daarom is het opmerkelijk dat deze toezichthoudende rol in een SAP omgeving vaak ofwel door SAP ofwel door de implementatiepartner wordt uitgevoerd. De klant doet er echter goed aan om voor de 'Quality Insurance' de eerder genoemde 'onafhankelijke derde partij' in de arm te nemen. Een partij die noch SAP licenties noch SAP consultants verkoopt. Een partij die maar ??n doel heeft: op objectieve gestructureerde en feitelijke wijze toezicht houden op de kwaliteit van de onderhavige SAP implementatie. Niet meer en niet minder. Deze peilstok lijkt mij voor de klant uiteindelijk zinvoller dan die van SAP of zijn implementatiepartner.

Marischa van Zantvoort

@Marischa Een onafhankelijke kwaliteitscontrole door een derde partij biedt geen meerwaarde want :
- wie garandeert de kwaliteit van de kwaliteitscontrole?
- de controlerende partij moet de beschikking hebben over SAP-consultants. Wie zou de controle anders moeten uitvoeren?
- SAP voert al een goede controle uit door de zogeheten GoLive-sessies. Ook kan een Early Watch-sessie worden aangevraagd.

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.