In 1982 schreef Jaap van Rees in het maandblad Informatie zijn roemruchte artikel: ‘de Methode doet het niet’. Daarmee zette hij zich doelbewust af tegen het mechanisch toepassen van een methode, in die tijd het SDM van Pandata als dé methode voor systeemontwikkeling in Nederland.
In 1995 nuanceerde Van Rees zijn uitspraak in het boek ‘De informatiearchitect’ als volgt: ’De methode doet het niet voor informatiearchitecten, maar voor systeemaannemers doet de methode het wel’.
Wat Van Rees in feite bedoelde, is dat een methode slechts kan dienen als richtlijn, checklist, sjabloon om op gedisciplineerde wijze een plan-van-aanpak op te zetten. Voor architectuur, waarbij een grotere mate van creativiteit wordt gevergd, dient een methode slechts een checklist te zijn; voor systeemontwikkeling is een methode een ontwikkelmodel dat dient te worden aangepast aan de bedrijfscultuur, aan de projectsituatie en aan het soort applicaties dat wordt ontwikkeld.
Dat laatste was ook al bekend bij Pandata. Het was niet de bedoeling van Pandata om een dwangbuis voor systeemontwikkelaars te maken, dat hebben de klanten er van gemaakt. Klanten probeerden exact alle, ook de niet-relevante, activiteiten die in het SDM-boek stonden uit te voeren tot de laatste komma nauwkeurig. Zelfs Pandata, de uitvinder van SDM, kreeg daar last van bij haar klantprojecten. Zij verwijderde het gebruik van SDM door Pandata uit haar standaard leveringsvoorwaarden, omdat klanten Pandata gingen aanspreken op het letterlijk werken volgens de methode.
Toen ik door de overname van Pandata door Cap Gemini Nederland in 1989 de verantwoordelijkheid kreeg over SDM (inmiddels versie 2) hebben wij de methode omgewerkt van een activiteitgerichte methode naar een resultaatgerichte methode, zie mijn artikel ‘Resultaatgerichte systeemontwikkeling’ uit 1992 in het maandblad Informatie jaargang 34, nummer 2. Onder resultaten wordt verstaan software, testsets en documentatie waaronder dossiers, inhoudelijke rapporten en handleidingen. Immers voor het onderhoud en de verdere uitbreiding, het grootste deel van de life cycle van de applicatie, zijn de resultaten belangrijk, niet het pad waarlangs die bereikt zijn.
Automatiseren is in essentie niets anders dan documenteren. Hiermee bedoel ik dat – na het noteren en ordenen van de praktisch geformuleerde eisen en wensen van de gebruikers – de verdere arbeid voornamelijk neerkomt op: schrijven, structureren, herschrijven, herschrijven en nogmaals een aantal keren herschrijven. Automatiseren is dus een stapsgewijs concretiseren van vage behoeften geformuleerd door mensen, naar eenduidige beschrijvingen die kunnen worden geïnterpreteerd door computers (processors).
Systeemontwikkeling vereist dus een zeer gedisciplineerd werken, daarbij staan niet de activiteiten centraal, maar de (tussen)resultaten eventueel opgeborgen in een repository.
Na het lineaire systeemontwikkelmodel van SDM-1 en SDM-2 zijn er allerlei iteratieve, incrementele, interactieve varianten ontstaan op dat lineaire model (ook wel de watervalmethode genoemd).
Scrum, een exploratieve op zich verdienstelijke vorm van systeemontwikkeling, is een dergelijke variant. Tijdens mijn IT-audits in de afgelopen drie jaar zie ik dat Scrum wordt omarmd omdat het veel speelser lijkt te zijn voor de teamleden. Vaak wordt voorbij gegaan aan de noodzaak van discipline met nadruk op het documenteren en het systematisch testen.
Dus, niets mis met Scrum maar zorg wel dat je een gedegen ontwikkelmodel gebruikt waarbij de (tussen)resultaten centraal staan. Een ontwikkelmodel met een ingebouwd kwaliteitssysteem.
Als ik zo om mij heen kijk, constateer ik dat de gemiddelde vakbekwaamheid in de IT nog steeds omlaag gaat. In 2008 stelde ik in het artikel ‘Toen was vakbekwaamheid nog heel gewoon’ in het maandblad Informatie, jaargang 50, nummer 10: ‘Rond het begin van de jaren negentig beleefden wij in Nederland het methodologische hoogtepunt in de IT. De essentie van degelijke systeemontwikkeling, zakelijk projectmanagement en praktisch kwaliteitsmanagement was redelijk goed in kaart gebracht. Rond 2002, ongeveer tien jaar later, kwamen we volop in het tijdperk van het knippen en plakken van software, en dat nog wel uit de losse pols. Ik bedoel dus zonder methode. Elke knutselaar kon heel makkelijk wat software in elkaar zetten achter zijn eigen pc. Structuur, compactheid en betrouwbaarheid waren zaken die uit de mode raakten’.
Bij menige IT-audit die ik de laatste jaren heb verricht, mis ik bij systeemontwikkeltrajecten een gezonde methodologische onderbouwing gericht op resultaten, waardoor er nogal chaotisch wordt ontwikkeld.
Is orde en discipline iets ouderwets waaraan jonge IT-ers zich niet meer wagen? Denken jonge IT-ers dat orde en discipline hun creativiteit beperkt?
Terugkomend op de nuancering van Jaap van Rees: de methode is absoluut noodzakelijk bij systeemontwikkeling mits met het juiste gevoel van nuances en discipline toegepast. En natuurlijk ‘de methode doet het niet’, het zijn de professionals die de methode gebruiken, die het doen. Dit is niet alleen semantisch correcter, maar onderstreept ook nog eens het belang van vakbekwame automatiseerders.
PS: Sommige jonge IT-ers zullen verzuchten ‘we hoeven toch niet steeds naar het verleden te kijken of was vroeger alles beter?’. Neen, de technologie is nu veel krachtiger. We kunnen een papierloos kantoor bouwen, we doen het alleen niet.
De essentie van alle methoden is vroeger al bedacht, ze hoeft alleen maar te worden afgestoft. Dus: hedendaagse technologie met de gelouterde methoden van 20 jaar geleden leveren ons, als bedrijfsleven en als publieke sector, nuttige en mooie informatiesystemen.
Daan Rijsenbrij, www.Rijsenbrij-Academy.nl
Het is altijd leuk om iemand te ontdekken waar je het fundamenteel mee oneens kan zijn en die zelf ook dieper doordenkt. Dit stukje tekst in je verhaal over “vage behoeften geformuleerd door mensen” zou je toch aan het nadenken kunnen zetten.
Mensen hebben het grote probleem dat ze hun behoeften niet kunnen articuleren. Door ze in een vast proces te persen van wat voor achtergrond dan ook gaan ze net doen of ze het wel weten en krijgen ze uiteindelijk weer precies wat ze niet willen.
Wat we moeten doen is het fenomeen “behoefte” is serieus nemen en is onderzoeken wat daar nu achter zit. Als we weten wat een behoefte bevredigt zouden we dat daarna kunnen gebruiken om iets te maken wat wel werkt.
Hans,
Ik geloof niet dat wij het fundamenteel oneens zijn. Ik geloof meer dat wij zaken op een iets andere manier benaderen.
Met ‘vage behoeften’ bedoel ik dat mensen wel weten wat ze willen, maar het niet goed kunnen formuleren (verwoorden). En ik geloof helemaal niet in vaste processen (dwangbuis), zoals uit mijn blog toch wel blijkt.
Om die ‘vage behoeften’ te concretiseren hebben we tegenwoordig vele instrumenten zoals inzichtgevende visualisaties, gedegen Scrum etc. etc.
Groet,
Daan.
Daan,
Leuk verhaal en erg herkenbaar. Ik zou een split willen maken in de vraagarticulatie en het uiteindelijke hulpmiddel. Daarbij moet je wel degelijk onderscheid maken van diegene die de vraag formuleren en de hulpmiddelen die je gaat gebruiken bij het beantwoorden van de vraag.
Eigenlijk komt het gewoon neer om de aloude verwarring tussen vraag en oplossing en die binnen de discussie heel erg word ondersneeuwt.
In een beetje organisatie (van voldoende omvang) zou het als volgt moeten gaan. De RvB/Directie stelt dat ze efficiënter willen gaan werken. En even voor het gemak: na een heel kundig vooronderzoek en van alles en nog wat komt daar uit dat er een aantal zaken moet gebeuren om die efficiency voor elkaar te krijgen. Mijn stelling is dat een oplossing voor welk bedrijfsvraagstuk op RvB/Directie dan ook, dat nooit alleen kan bestaan uit een stuk nieuwe software. Als dat daadwerkelijk zo zou zijn, dan kunnen de mensen die met de software werken Рwat mij betreft Рmorgen hun biezen pakken (ze hebben totaal geen toegevoegde waarde blijkbaar). Ik denk dat een oplossing voor een vraag vanaf dat niveau uiteindelijk resulteert in een combinatie van allerlei zaken, als procesveranderingen, organisatie inrichtingswijzigingen en ja hulpmiddelen (waar ICT er in van is). Zo bezien nog geen vuiltje aan de lucht.
Maar daar komt ie, denk je dat de uiteindelijke bouwers van het stukje ICT de oorspronkelijke vraagstelling in zijn context op hun bord krijgen? Nee ergens in de chain-of-command is er iemand geweest die blijkbaar een vertaalslag heeft gemaakt dat een software pakket X bouwen een deeltje is van die verzameling oplossingscomponenten. Mijn stelling is dat die vertaalslag(en) vaak op basis van onderbouwgevoel of smaak zijn genomen (niet te vergeten de bekende golfbaanretoriek (“mijn baas wil effici√´nter gaan werken, hoe hebben jullie dat aangepakt?”, “Ohh, wij hebben pakket X gekozen, heel goed spul, bel me morgen maar even”).
Zie hier dat de vraagarticulatie van de RvB/Directie tot in de haarvaten van de organisatie (echt niet alleen ICT hoor, sommige afdelingen worden domweg vergeten, vaak de gebruikers). niet op een consistente manier wordt vertaald naar de onderliggende niveaus. Hierdoor hebben de onderliggende niveaus nauwelijks echt afgedwongen randvoorwaarden die ik terug kan herleiden naar het oorspronkelijke vraagstuk.
Een tweede niet geheel onbelangrijk aspect in je verhaal is de vakmanschap van ICT-ers in het algemeen. Maar dat is in elk vakgebied waar vakmanschap wordt vereist. Een architect in de bouwwereld kan nog zo mooi gebouw schetsen en de vertaling (technisch ontwerp) neerleggen bij een bouwer (aannemer). Als daar mensen rondlopen die hun eigen vak niet verstaan, gaat het hem niet worden.
Een laatste aspect is de manier waarop de oplossing wordt vormgegeven. Ik zie de oplossing en de manier waarop die wordt “ge√Ømplementeerd” als een ding. De oplossing is vaak het tastbare resultaat van de bouwactiviteit. Zeker in de ICT is het erg belangrijk ook een goede aanpakkeuze te kiezen. Draagvlak, acceptatie en inbedding zijn typische eigenschappen van een aanpakkeuze en bepaalt mede het eindresultaat.
Het interessante fenomeen doet zich sinds 5 jaren voor, dat het aantal discussies over effectiviteit van methodes weer aan het toenemen is. Zo lijkt het na jaren van slaafs toepassen en onoverdacht kopieren van methoden en technieken, bedoeld om consultant aan het werk te houden, nu zover, dat het algehele nut van methoden en technieken nu zelf onder vuur komt te liggen. Je kan dit zien als een theoretische meta-discussie, maar het gaat feitelijk terug op een groot probleem: Er zijn op het gebied van software ontwikkeling in de afgelopen 10 jaar zeer sterke, invloedrijke, nieuwe “outsiders” bijgekomen in de beinvloedingssfeer rondom software. Te denken valt aan de verschillende soorten “analisten” en “architecten”, die in multipele business lines de besluitvorming over software voorbereiden en “beinvloeden”. Er valt ook te denken aan de vele “business / advisory” rollen, die erbij geformuleerd zijn. Wat voorheen een relatief beschermd gebied van “ontwikkelaars” was, is metterhand bijna gehele operationele organisaties gaan overlappen. Automatisering is geen domein meer van IT alleen. Elk van deze IT beinvloeders hanteren eigen “scholen” van “structureren”en “vooruitgangsgeloof”, maar geen enkele “school” kijkt naar overlap, dan wel witte vlekken hiertussen. Niemand is daar ook voor te porren, want deze “common fields” worden door niemand gefinancierd. Probleem beschreven door Daan is dan m.i. ook niet dat er methoden missen, integendeel, er zijn veel te veel personen, partijen en lines-of-business betrokken in verschillende fasen van voorbereiding en besluitvorming, die elk hun eigen methodes inbrengen en “normaal” verklaren. Oplossing: daar was enterprise architectuur toch voor? Echter: zolang Enterprise Architectuur gaat over toepassing van methoden “vanuit de IM/IT afdeling” zal dit probleem niet worden opgelost, maar wordt het sterk verergerd. Wellicht is het daarom tijd, om de container term “Architectuur voor Enterprises” maar gewoon af te schaffen. Methodisch zijn de daaronder te vinden methodieken vaak gebaseerd op gesimplificeerde structureringsprocessen en overmatig “betrouwbaar” gemaakt vinkenlijsten. Zolang in de Financiele huishouding van bedrijven IT Asset Management (inclusief Software Waarde Management) EN Innovatie schaart onder “Intangible Assets” (Art 38 IAS maakt software tot een moeilijk/niet waardeerbaar, vaak ook ongrijpbaar goed), kan er methodisch NOOIT ge-uniformeerd worden. De belangentegenstellingen daarin zijn simpelweg te groot en de discussie rondom het eigen gelijk van toepassing van methoden woekert ineffectief voort. Daarom van hieruit een pleidooi om IT-Audits dan ook niet langer meer te gebruiken als review-plek van kwaliteit in IT, maar vanuit Innovatie Management te kijken naar OUTPUT van geleverde vernieuwing en concurrentie voordelen door alle betrokken partijen. De ontwerpers, bedenkers en ontwikkelaars kunnen zich dan daaraan onderwerpen en de regie kan dan geregeld worden vanuit staged Innovatie en Investment Management en het pad van Asset Management wordt dan gesloten, dan wel gesepareerd naar operations (en IT)management en dito methodisch aangestuurd vanuit een interne bedrijfsautoriteit, die niet de methodische toepassing, maar de effectieve OUTPUT als maatstaf hanteert.
Alleen de methode doet het.
Naar mijn idee wordt nogal snel vergeten dat een gepubliceerde en geaccepteerde methode in feite een bundeling en vastlegging is van kostbare kennis en ervaringen. Het klakkeloos terzijde leggen van deze gebundelde kennis getuigt naar mijn gevoel dan soms misschien ook wel van lichte zelfoverschatting.
Wellicht kunnen we hier een maturiy model op loslaten:
1) De professional gaat enthousiast aan de slag in de volle overtuiging de wereld te verbeteren. De gebruikte methode is nu: Heijermans’ “op hoop van zegen”.
2) Het valt allemaal toch wat tegen en drie rechtszaken later beseft de professional dat er misschien toch iets te leren valt. Hij neemt een boek over adviesvaardigheden, projectplanning en gestructureerde systeemontwikkeling ter hand.
3) Het gaat al beter nu en de opdrachten nemen toe in complexiteit. Misschien is het nu tijd om iets over structuren, architecturen en patterns toe te passen?
4) De professional kent zijn vak en kan gaan spelen met de geleerde methoden. Wellicht kan in deze fase de uitspraak va van Rees gelden: de methode doet het niet (meer).
5) De vijfde fase: continue zelfverbetering. Covey wellicht?
Wat ik maar wil zeggen: voor het aanstormend talent doet “de methode” het wel zeker. Pas als je “de methode” door en door kent, kun je weloverwogen en risicoloos afscheid gaan nemen. Wie met de methode kan spelen is de professional.
Het is daarom jammer dat veel aanpakken de inhoudelijke component missen. SDM was zo slecht nog niet.
Herkenbare discussie die je terecht in de juiste tijdgeest plaatst. Lang geleden ben ik mijn werkzame leven begonnen bij Pandata, een bijzonder interessante en kennisintensieve omgeving. Een heel aantal ideeën die daar zijn ontstaan, leven vandaag de dag nog voort, zijn soms zelfs nog verrassend actueel. Indertijd was ik, net als een groot deel van mijn vakcollega’s een toegewijde missionaris van de SDM-methodiek. Dat was deels natuurlijk mijn werk, maar daarnaast was het mij ook duidelijk dat deze methodiek voorzag in een grote behoefte om meer greep te krijgen op de -toen heersende wildgroei- in de systeemontwikkeling.
Inmiddels is de situatie radicaal veranderd en is de markt voor IT-projecten vooral een vervangingsmarkt geworden en ook is de kennis & ervaring binnen de IT enorm toegenomen. Daarnaast heeft ook de techniek en de tooling een grote ontwikkeling doorgemaakt. Het denken over (nieuwe )systeem ontwikkel methodieken is in al die jaren blijven meegroeien. Dat is volgens mij op zich al een bewijs van het nut en de noodzaak van deze methodieken.
Maar hierin zit volgens mij ook een fundamentele zwakte, die de laatste jaren steeds duidelijk naar voren komt. Het briljante idee om de software ontwikkeling in duidelijk afgekaderde projecten onder te brengen en deze vervolgens te segmenteren, werkte prima in een ‘greenfield situatie’. In het huidige steeds sterker geïntegreerd IT landschap is dat echter veel minder het geval. De ‘’splendit isolation’ waarin projectleiders menen hun projecten te moeten voerden leidde altijd al tot wanhoop bij de opdrachtgevers, gebruikers en beheerorganisaties. Door de vele koppelingen en interacties die informatiesystemen tegenwoordig hebben, wordt deze wanhoop inmiddels gedeeld door de hele organisatie en vaak ook nog daarbuiten door klanten en leveranciers. Misschien zou in de toekomst wel eens helemaal afscheid genomen moeten worden van de projectmatige aanpak (typische VS/ Europese benadering) en veel meer voor de weg van de geleidelijkheid (Japans/ Aziatische benadering) gekozen moeten worden.
Een ander opvallend punt is dat de ontwikkeling van de methodologie zich in de afgelopen twintig jaar grotendeels in hetzelfde domein en op hetzelfde niveau heeft voltrokken. Steeds voornamelijk tactisch/ operationeel gericht op projectbeheersing en het sturen op tijd, geld en kwaliteit. En waar de verbinding met de techniek wel de nodige aandacht heeft gekregen, is de kloof tussen de gebruikers en de bedrijfsvoering altijd levensgroot blijven bestaan. Al vele jaren wordt ervoor gepleit dat projecten en projectmethodieken meer oog zouden moeten hebben voor de bedrijsvoerings- en veranderkundige aspecten, maar gevreesd moet worden dat dat zal wel nooit zal gaan lukken. Ik zou dan ook willen pleiten voor een extra vertaalslag, door een extra informatie governance kolom tussen de IT en de bedrijfsvoering te plaatsten. Opvallend is dat een heel aantal nieuwe en steeds belangrijker wordende beheerdisciplines zoals; architectuur, BI, (meta)gegevens management, data management, allemaal onderdeel uitmaken van een dergelijke informatie governance kolom.
Een dergelijke nieuwe visie vraagt natuurlijk ook om een nieuwe methodiek. Ik zou me kunnen voorstellen dat er naast de projectmatige aanpak van de IT-ontwikkeling een geheel nieuwe informationele aanpak komt die zich primair zal richten op de integratie en veranderkundige aspecten. Voor de invulling daarvan is een nieuwe evolutie (misschien wel revolutie) in denken nodig, misschien wel vergelijkbaar met introductie van SDM twintig jaar geleden.
Atilla,
Dank voor jouw nuchtere reactie.
Wat mij zeer aanspreekt in jouw commentaar is dat jij net als ik stelt dat automatiseren degelijk dient te gebeuren en dat de oplossing vaak niet bestaat uit alleen maar een stuk ‘software’.
Groet,
Daan.
Raymond,
Dank voor jouw waardevolle reactie.
Vakmanschap is belangrijker dan de methode, hoewel een goede methode wel een hulpmiddel zal zijn voor degelijk werk.
Een tweede punt waar ik het met jou eens bent, is dat er te veel wordt getheoretiseerd over methoden, vaak door mensen die nauwelijks echte praktijkervaring hebben met de discipline waarop de methode wordt toegepast.
Jouw opmerking dat een methode vaak bestaat uit een stukje plak-en-knip werk uit andere methoden, vaak een voor elke dominante stakeholder, is zeer herkenbaar. Dat is ook het drama achter TOGAF.
Groet,
Daan.
Frank,
Dank voor jouw commentaar, met name jouw idee van een maturity model voor methoden. Ik merk alleen dat na die rechtszaken (puntje 2) sommigen gewoon doorgaan op de oude weg, onder het motto: ‘liever het risico van een rechtzaak dan up front investeren in een succesvolle methode’.
Ik ben het met je eens dat een gepubliceerde en geaccepteerde methode een bundeling en vastlegging is van kostbare kennis en ervaringen. Maar daar is een ervaren professional voor nodig om die kennisbron situationeel toe te passen.
Voor het aanstormend talent (de jonge mensen die het nog moeten leren) en de uitgebluste oude professionals (die zich willen indekken) is de methode nuttig als looprekje (of de zijwieltjes op de fiets).
Groet,
Daan.
Winfried,
Interessant is jouw opmerking over IT-projecten. Tenzij men een totaal nieuw systeem moet ontwikkelen, is het feit dat je een IT-project start wellicht een teken van zwakte. Men heeft het actieve onderhoud (evolutionaire ontwikkeling) zo zwaar verwaarloosd dat er een projectmatige inspanning nodig is.
Met die extra kolom tussen bedrijfsvoering en IT ben ik het roerend eens. Dat is in feite ook wat je ziet in het 9-vlaks model van de Universiteit van Amsterdam. Maar 3 bij 3 is heel wat complexer dan 2 bij 2 (Henderson / Venkatraman), toch?
Groet,
Daan.
Daan,
Leuk weer eens iemand te zien die een lans breekt voor de methode. Zoals het bij alle professionele vakgebieden is: een methode zonder vakman is net zo schadelijk als een vakman zonder methode. Het gaat dus om de combinatie van de twee. Een deel van het vankmanschap is m.i. juist het correct inzetten en aanpassen van de methode op het probleem. Bijvoorbeeld, welke stappen sla je over (of doe ik impliciet) bij een kleine klus.
Wordt de creativiteit onderdrukt door de methode? Ik denk het niet, de creativiteit zit in het eindresultaat (kijk naar het Eye gebouw in Amsterdam), niet in de methode. Ik durf wel te stellen dat bij zo’n bijzonder creatief gebouw er juist veel een gedetailleerd wordt gedocumenteerd. Alles wordt drie keer gemeten voor er een zaag bij wordt gehaald.
Maar het hoeft niet de creatief zelf te zijn die de methode volgt, het is een team-effort. Elk team zou een duck-tape ontwikkelaar moeten hebben voor de simpele oplossingen voor ogenschijnlijk onmogelijke problemen. Dit zij veelal niet de methodische mannen en dienen dus een goede plek in een gestructureerd team te moeten hebben ter ondersteuning van die creativiteit.
Aan het einde stel je iets dat mij treurig stemt: “De essentie van alle methoden is vroeger al bedacht”. Hoewel oude rotten in het vak over het algemeen alle nieuwe ontwikkelingen afdoen als “Oude wijn in nieuwe zakken”, houdt ik mij toch vast aan de gedachte dat er nog meer te ontdekken valt. Om te beginnen met meer automatisering in de methode.
Groet, Peter
“Automatiseren is in essentie niets anders dan documenteren. Hiermee bedoel ik dat ‚Äì na het noteren en ordenen van de praktisch geformuleerde eisen en wensen van de gebruikers ‚Äì de verdere arbeid voornamelijk neerkomt op: schrijven, structureren, herschrijven, herschrijven en nogmaals een aantal keren herschrijven. Automatiseren is dus een stapsgewijs concretiseren van vage behoeften geformuleerd door mensen, naar eenduidige beschrijvingen die kunnen worden ge√Ønterpreteerd door computers (processors).”
Wat m.i. opvallend in je verhaal ontbreekt is het woord “ontwerpen” (als in “een applicatie-architectuur ontwerpen”). Zoals jij het hier opschrijft is het een heldere top-down activiteit van behoeftes naar resultaat. Maar zo eenvoudig is het niet, en alle methodes die daar (meer of minder) op gebaseerd zijn, zijn m.i. gedoemd te mislukken zodra de situatie omvangrijk en complex wordt.
Niet alleen is de vraag niet altijd helder, hij is soms fundamenteel onhelder (b.v. als aspecten als privacy, ethiek, etc. langs komt bij patientendossiers). IT zelf is strikt logisch, de wereld waarin de IT gebruikt wordt is dat meestal niet. En zelfs in situaties waar de wereld die IT moet ondersteunen strikt logisch is, dan is de complexiteit vaak zodanig dat exact uitwerken niet gaat. En voeg daar dan nog de veranderlijkheid in de tijd bij, en je hebt een wereld die je niet als een wiskundig probleem kunt benaderen (ook al dacht oom Edsger van wel).
Aan de andere kant zijn er de uiterst vrije en iteratieve methodes. Daar ook geldt dat de aandacht voor “ontwerp” vaak ontbreekt. Dat geeft grote risico’s van suboptimalisaties en grotere problemen op de lange termijn.
De kern is denk ik dat je moet nadenken over ontwerp (architectuur). En die architectuur moet in ons vakgebied een levend object zijn, die meebeweegt met de ontwikkeling. Een van de belangrijkste uitdagingen (naast inhoudelijke kwaliteit) daarbij is dat zoiets niet eenvoudig past in de ‘plan&control” filosofie van onze organisaties en daarom erg moeilijk uit te leggen en te verkopen is.
Peter,
Belangrijk is dat jij benadrukt, dat de methode ook een afstemmingsinstrument is binnen het team.
Veel methodisch werk heeft een mechanische (ik bedoel ‘routinematige’) component en vergt een zeer grote mate van discipline.
Computers zijn bedoeld voor mechanisch werk. En, laten we eerlijk zijn: de computer heeft meer discipline dat de meeste mensen.
Groet,
Daan.
Gerben,
Natuurlijk behoort tot dat structureren ook ontwerpen, hoe zou je anders kunnen structureren.
Het enige wat ik met mijn door jou aangehaalde statement wil onderstrepen is dat automatiseren een zeer hoge mate van discipline vergt.
Ik ben het niet me jou eens dat automatisering geen exacte wetenschap is.
Trouwens elke complexiteit is op te losse door een vakbekwame architect. Een architect zorgt voor orde en samenhang, een passende beleving en slimme constructies.
Ik ben het met je eens waar je stelt dat architectuur steeds moeilijker wordt in een wereld die steeds onvoorspelbaarder zal worden. Lange-termijn-architectuurplaatjes worden minder belangrijk dan een degelijke ‘integratiearchitectuur’.
Groet,
Daan.
Daan,
Wat ik me afvraag is of het echt zo is dat de vakbekwaamheid in de IT nog steeds omlaag gaat. Het komt mij over als een particuliere en subjectieve mening. Ik zou net zo goed het tegenovergestelde kunnen beweren.
Ik zou het wel toejuichen als hier wetenschappelijk onderzoek naar werd gedaan. Dat is wel lastig, want hoe kwalificeer en vergelijk je ‘vakbekwaamheid’ en hoe baken je ‘in de IT’ af? En hoe vergelijk je dat met vroeger? De omstandigheden zijn radicaal veranderd. Veel basale processen zijn ondertussen wel geautomatiseerd en de technologie van nu maakt ondersteuning van veel complexere processen mogelijk.
Maar natuurlijk is elke aandacht voor verdere professionalisering in het vakgebied meer dan welkom! Hulde daarvoor.
Walter,
Tijdens mijn vele ervaringen als IT-auditor constateer ik dat de vakbekwaamheid omlaag gaat, zie mijn artikel ‘Toen was vakbekwaamheid nog heel gewoon’ in 2008 gepubliceerd in het maandblad Informatie.
Daarnaast zie ik het onbegrip tussen businessmanagers en IT’ers (dat al 50 jaar bestaat) nog niet oplossen, ondanks de studies BIK die wij vorige eeuw aan aantal universitaire instellingen hebben zien ontstaan.
Ik denk dat er best objectieve criteria zijn waarop je de vakbekwaamheid kunt meten. Het aantal fouten per 1000 regels code, de inconsistenties in (advies)rapporten etc. Probleem is dat we dat nooit hebben bijgehouden. Wellicht zou een ervaren kwaliteitsmanager daar eens iets over kunnen zeggen.
Groet,
Daan.
Vwb. software-ontwikkel-methoden: executie is veel belangrijker dan ontwerp, planning en documentatie. Zie ook het feit dat bijna alle grote software trajecten (mn. obv. waterfall) buiten budget en buiten tijd geraken.
Ik werk recent veel met mini-Scrum (mijn term) met goede resultaten. Kenmerk is geen FO (functioneel ontwerp) maar beknopte lijstjes wensen/eisen die in korte sprints met key-users op het scherm worden uitgewerkt, met focus op minimum ipv. maximum functionaliteit.
De grote software huizen kunnen (en willen) dit niet omdat het onverwacht meerwerk beperkt, wat juist hun core business is. Zij bestaan immers door uurtje-factuurtje, dus uitloop is winst. Voor mij kan je daarom de meeste grote software huizen op een hoop gooien met grote banken: afslag gemist!
Soms denk ik ook wel eens dat voor architecten iets dergelijks geldt. Waar dus behoefte aan is is zoiets als Scrum voor architecten. Maar dat zal ook wel weer een religieus dik boek worden, dus dank je, hoeft niet voor mij!
Wouter,
Scrum is een zeer interessante, veelbelovende ontwikkelstrategie. Mijn observatie bij (potentiële) klanten is dat er (te) vaak Scrum wordt bedreven uit de losse pols. Ik vind echter dat een exploratieve ontwikkelstrategie nog meer discipline vergt dan een lineaire, zeer zeker op het gebied van systeemdocumentatie.
Je hebt gelijk dat bij Scrum meer van architecten wordt geëist dan bij een lineaire systeemontwikkeling omdat zij niet rustig en uitgebreid kunnen nadenken. Van hen wordt bij Scrum verwacht dat zij tijdens de sprints direct en alert reageren.
Groet,
Daan.