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.
@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
http://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
http://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
http://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
http://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 ?