Een veel gebruikt middel bij softwarebouw is het zogenaamde functioneel ontwerp. Voordat overgegaan wordt tot het implementeren van een stuk software, worden functionele eisen en wensen in kaart gebracht in een centraal document. De stelling die ik bij deze wil poneren is dat functioneel ontwerp, zoals dat vaak vroeg in automatiseringstrajecten wordt toegepast, niet bijdraagt aan een betere oplossing.
Automatisering van delen van bedrijfsprocessen is een middel dat tot doel heeft om de processen efficiënter te maken. Hoewel er met behulp van software veel (en steeds meer) optimalisatiemogelijkheden zijn, is het niet per definitie gezegd dat software altijd de beste oplossing is. Vaak gebeurt het echter dat juist helemaal aan het begin van deze trajecten gedacht wordt in termen van automatisering. De functioneel ontwerper wordt vaak in een vroeg stadium betrokken. Vaak worden functioneel ontwerpen al in dit vroege stadium voorzien van bijvoorbeeld detaillistische schermontwerpen die te vroeg beperkend werken en dus niet leiden tot een efficiënt eindresultaat.
Wat is dan het alternatief? Zet in het voorstadium van auotomatiseringstrajecten eerst nog eens een stapje terug. Probeer overzicht te krijgen over het gehele (wel of niet) te automatiseren domein, en probeer de essentie ervan te vatten in verifieerbare modellen. Op het moment dat een meer volledig beeld ontstaat, is het voor vakmensen makkelijker om onderbouwd beslissingen te nemen wat wel en wat niet te automatiseren.
Deze benadering is verre van nieuw. In software engineering is sinds een paar jaar de benadering van Eric Evans, te weten 'domain driven design', erg in opmars. Daarnaast is er het contextual design van Beyer en Holzblatt. De praktijk wijst uit dat de combinatie van deze twee werkwijzen, die in elkaars verlengde liggen, leidt tot veel beter bij de business passende oplossingen.
Andre, als je dit vertaalt naar disciplines dan is eerst de discipline Business process modelling aan de slag. In een goed project of juist voordat een goed project start zijn de gewenste processen uitgewerkt en de te automatiseren onderdelen in kaart gebracht. Dit wordt in samenwerking met andere disciplines uitgevoerd die zich aan de voorkant bevinden zoals programmamanagement en enterprise architectuur.
In het project heb je in moderne software ontwikkelingen geen FO’s meer. Je constatering is ook correct: Voordat je aan de schermen begint werk je eerst een Use Case Model (het wat) uit waarin de actoren en activiteiten van die actoren op het systeem in kaart worden gebracht. Use cases worden nog verder gespecificeerd met o.a. activity diagrams, ook een soort processen, maar dan op gedetailleerder level. Dan gaat een software architect/analist aan de slag met het Analyse Model (het hoe). Hierin worden de use case specificaties vertaald daar software componenten. Bijvoorbeeld webservices en schermen. Dus dan pas komen de schermen aan bod. Deze drie modellen worden enigszinds gelijktijdig ontwikkeld maar wel in de genoemde afhankelijkheden. Alles kan je dan nog iteratief doen of in waterval.
Dus resume: Ja, ben eens met de stelling, en binnen moderne software ontwikkeling is hier volgens mij ook een goede andere werkwijze voor om daadwerkelijk op te leveren wat door de business wordt gevraagd.
Goed punt. FO bestaat nu een jaar of 40-45 en er zijn inderdaad alternatieven mogelijk. Ook in Nederland zijn daar al oplossingen voor. Waarbij inderdaad de business centraal staat. Ik sta open om elkaar eens te ontmoeten.
What’s in a name?
Het nut van een functioneel ontwerp is dat je in meer functionele termen met je (interne of externe) klant / opdrachtgever kunt praten over wat je nu gaat ontwikkelen. En technisch ontwerp is vaak dusdanig technisch en gedetailleerd dat dit onleesbaar is voor de klant / eindgebruiker. Dat is immers geen IT-er.
Dat in de loop van de tijd de inhoud van een FO en de wijze waarop deze tot stand komt verandert, is logisch. We zijn immers (gelukkig) een vakgebied dat zich ontwikkeld en aanpast aan veranderde omstandigheden en nieuwe inzichten.
Om meteen te stellen dat het FO niet bijdraagt aan een betere oplossing is alleen naar mijn idee gevaarlijk. Je loopt het risico dat veel IT-ers voor wie het denken in business termen een uitdaging is, nu denken geen FO meer te hoeven maken en alleen in voor de business onbegrijpelijke technische termen een oplossing beschrijven. Op enig moment in het project zal er echter overeenstemming moeten zijn tussen business en IT over wat er moet worden gerealiseerd. Dat kan alleen in voor de business begrijpelijke termen. Ter ondersteuning van deze afstemming is een document bedacht met de naam functioneel ontwerp. Dat we met voortschrijdend inzicht er achter zijn gekomen dat dit FO beter op een andere manier tot stand kan komen, wil niet zeggen dat de bijdrage van een FO aan een goede oplossing ter discussie moet worden gesteld. Ik ben het eens met de geconstateerde tekortkomingen, de te snel gemaakte keuzes en het nut van bijvoorbeeld use cases. Maar om meteen te stellen dat het FO geen bijdrage levert aan de kwaliteit van de oplossing gaat wat ver.
De kwaliteit van de oplossing wordt naar mijn idee namelijk niet bepaald door een FO (dat eigenlijk alleen de functionele beschrijving van de oplossing is), maar meer door het samenspel van IT en business bij het vaststellen hoe business processen het beste kunnen worden verbeterd en al dan niet kunnen worden ondersteund met IT. In een te vroeg stadium keuzes maken die beperkend werken, zegt meer iets over de tekortkomingen in dat proces dan over het nut van een FO. Het FO is en blijft volgens mij nog steeds een onmisbaar middel om gedurende het project afstemming te krijgen tussen business en IT over de op te leveren functionaliteit. Het proces om tot een FO te komen is helaas echter in de praktijk nog voor veel verbetering vatbaar, getuige de voorbeelden in het artikel van André.
De stelling dat detaillistische ontwerpen beperkend werken is te boud: in de agile projecten die ik doe werkt het juist vaak heel erg verhelderend om deze tegen gebruikers aan te houden. Al die modellen en diagrammen zegt hen juist niks. Dat geldt vaak ook voor het FO: een brij aan tekst die -alles bij elkaar- zo veel informatie bevat dat “nee” zeggen moeilijk is en “ja” zeggen leidt tt onaangename verrassingen in de acceptatietest.
Ik zou voorstellen dat we niet weer een model, methode of aanpak gaan hanteren om betere software te realiseren, maar vooral dicht tegen eindgebruikers aan gaan zitten en onze communicatie op de ontvanger afstemmen in plaats van andersom.
Ik ben het op een aantal vlakken eens met André, maar zeker niet met zijn conclusies. Ik onderschrijf de reactie van Rick en Anko dat een FO een belangrijke stap is om vanuit de business over te gaan naar de techniek. Dat er verkeerde FO’s geschreven worden is helder, maar om dan daarmee meteen de hele stap overboord te zetten is wat te drastisch.
Ik las het artikel met interesse en toen ik las dat André voorstelt een stap terug te doen, dacht ik: eindelijk. Yes. Weer iemand die het begrijpt. Maar helaas pakt de schrijver nog niet ver genoeg terug. Natuurlijk moet je het geheel beschouwen. Maar ook dat brengt je niet bij de kern. Veranderen doe je niet voor de lol. Je wil iets bereiken! Iets dat je zonder de verandering niet zou bereiken. Daar ligt dus de kern van het terug stappen: Waarom moet er veranderd worden? Wat is dan het doel van de business en waarom wordt dat niet bereikt? De grootste belemmering in het bereiken van het doel is het grootste probleem van de organisatie en dat moet je opruimen.
Het FO is het de beschrijven van de oplossing op dat probleem. En dat is een onmisbare stap in elk project!
@Anko Tijman
Ben het helemaal met je eens. Juist de User Centered Design methode is volgens mij de juiste manier tegenwoordig. Een vroege en continue focus op de (eind)gebruikers en hun taken, emperische metingen van het gedrag en iteratief design.