Kunnen we bij het ontwikkelen van software voor het web en voor andere platforms in opkomst leren van fouten die ontwikkelaars twintig jaar geleden al maakten? Ze gebruikten toen andere technieken, andere ontwikkelomgevingen en kwamen uit op andere gebruikersinterfaces.
De commandoverwerking was bij softwareontwikkeling vroeger nauw aan de gebruikersinterface gebonden. Tot de GUI’s (graphical user interface) kwamen, en de client/server-applicaties. Toen moest de software geheel opnieuw geschreven worden.
In die client/server-software werd ook nog veel business-logic dichtbij de gebruiker ingericht, want het was een krachtig platform en dat was de eenvoudigste oplossing. Niemand zag dat anders. Maar ook het client/server-tijdperk ging voorbij en weer moesten applicaties nieuw geschreven worden.
Nu… het web
De huidige stand van zaken is: stevige lokale (persoonlijke) applicaties én de thin clients, verbonden met het web. Maar er zijn al visionaire ontwikkelaars die denken aan servicegeoriënteerde architecturen (de afkorting soa gebruiken wij niet zo graag!) Niet alleen de pc trekt hun aandacht, maar ook pda’s en mobiele telefoons.
Hoe kunnen we er zeker van zijn dat we niet dezelfde fouten maken als in het verleden? We hebben in ieder geval geleerd dat de gebruikersinterface onvermijdelijk aan veranderingen onderhevig is en dat we er dus het beste aan doen deze interface gescheiden te houden van de feitelijke dataverwerkingsprocessen. De huidige generatie ontwikkeltools biedt daar echter onvoldoende garanties voor.
In 1995 werkte ik voor een bedrijf dat een topproduct had, dat echter niet meer verkoopbaar was. Waarom? Het product had een character-based gebruikersinterface op ouderwetse terminals met monochrome beeldschermen. Naar de maatstaven van toen en nu zag het er niet uit. Het product voldeed weliswaar feilloos op tal van plaatsen, maar dat maakte niets uit voor degenen die een gelikte vormgeving veel belangrijker vonden dan een goed programma.
We moesten hier een antwoord op vinden en wel vlug ook. En dus maakten we snel een GUI, niet voor het hele programma, maar alleen voor die delen waar potentiële gebruikers op letten. Nou, snel… Het duurde veel langer dan verwacht en het zag er niet goed uit ook. We misten ook een andere kans. Webbrowsers begonnen op de markt te komen en die konden meteen al veel. We maakten toen een prototype van een browserinterface. Dit initiatief werd van hogerhand afgeblazen, want we moesten een Windows GUI hebben of niets.
Vervolgens lieten steeds meer klanten ons product vervangen door software van de concurrent met een browser-GUI. Toch draait onze oorspronkelijke applicatie nog steeds, ook al is die meer dan twintig jaar geleden geschreven en wordt die al de helft van die tijd als verouderd beschouwd.
We leren hieruit dat een software met een typische levensduur van vijf jaar in de praktijk vaak nog eens vijf jaar geprolongeerd kan worden. Dit onder het motto: If it ain’t broke, don’t fix it… Dingen veranderen, ja, maar hoeven dat niet (altijd). Maar áls ze dan veranderen – we kunnen zelfs als ontwikkelaars de toekomst niet voorspellen – moeten we er wel op voorbereid zijn. Dat wil zeggen: we moeten onze applicaties kunnen aanpassen, zonder ze volledig opnieuw te hoeven schrijven. De verwerking van data blijft; we moeten vooral de gebruikersinterfaces aanpassen. De regels en datastructuren die de processen in het bedrijfsleven beschrijven, veranderen niet.
Dan zúllen we misschien voor nieuwe technieken moeten ontwikkelen, zoals voor webbrowsers en we beginnen nu iets te begrijpen van mogelijk de volgende generatie interfaces, zoals pda’s en mobiele telefoons, maar wat daarna komt, weten we niet.
Om daar met succes aan te kunnen werken is een grondig begrip nodig van zowel de applicatiearchitectuur als de fysieke architectuur waarop deze applicatie ons wordt aangeboden. Slechts weinig ondernemingen beschikken over ruime bekwaamheden op beide gebieden. Op het opnieuw uitvinden van het wiel zit echter niemand te wachten, want ook daaraan zijn opnieuw de kinderziekten verbonden, die men in de ‘oude applicatie’ al overwonnen had.
SODA
De nauwe verbondenheid van de character-based interfaces met de business logic had – achteraf bezien – beter geanalyseerd en in discrete functies opgesplitst moeten worden, voordat men met de nieuwe GUI en de nieuwe van de grond af aan opgebouwde nieuwe applicaties was begonnen. Elke functie die voor informatie op het scherm van gebruiker nodig was, had men oproepbaar moeten maken. Waar dit werkstroomproblemen opleverde, had men meer in detail moeten kijken en mogelijk een nieuwe werkstroom moeten creëren.
Met andere woorden: we hadden al in 1995 naar een SODA (Services Oriented Development of Applications) moeten overgaan. Dan had de overstap van de ene GUI naar de andere ons minder kopzorgen gekost. Bouw de formulieren en roep op de juiste plaats de al beschikbare functies op. En voor écht nieuwe ‘business logic’ die een link naar de GUI vereiste, had men ook hetzelfde principe kunnen volgen.
Dit zou minder gebruikersondersteuning hebben gevraagd en minder inspanning voor verbeteringen. Want die verbeteringen hadden we slechts op één plaats aan hoeven te brengen.
Technologie
Het zal u opgevallen zijn dat ik nog geen enkele techniek bij naam heb genoemd. Technologie was en is dan ook het probleem niet. In de meeste gevallen waren database, serveromgeving en ontwikkeltaal ook in 1995 al in staat elke oplossing te bieden. Het ontbrak echter aan toekomstvisie.
Ook al is de technologie voorhanden, de hulpmiddelen en ontwikkelprocessen die velen gebruiken, dragen ook bij tot het maken van minder goede keuzes.
De meeste ontwikkelprocessen bevorderen allereerst het ontwerpen van de gebruikersinterface en dan pas de ‘business logic’. Bijna elke specificatie begint met het tonen van de scherm-layout als de eerste bron van informatie, in plaats van een gedetailleerde beschrijving van de vereiste ondernemingsprocessen met hun data-interacties. Geen wonder natuurlijk, het produceren van scherm-layouts is nu eenmaal gemakkelijker dan het beschrijven van processen. Beginnen met makkelijke dingen – die ook nog zichtbaar zijn (gebruikersinterfaces) – is een heel gangbare gedragswijze.
Dezelfde fouten worden ook nu nog gemaakt bij het ontwikkelen van browserinterfaces. Bestaande systemen zijn ontwikkeld zonder echte scheiding van ‘business logic’ en gebruikersinterface en nieuwe versies blijven deze trend volgen. Hoe kunnen deze systemen zich aanpassen aan nieuwe gebruikersinterfaces, die onontkoombaar gevraagd zullen worden, over vijf of tien jaar, ook al hebben we geen idee hoe die eruit zullen zien.
Ok, het is waar, de server doet de verwerking en de browser zorgt voor de presentatie, maar bedenk wel dat telkens als we data van de browser naar de server zenden, het gaat om een specifiek http-pakket, dat ook typisch als zodanig wordt verwerkt. De business logic is nauw gekoppeld aan het verwerken van scherminformatie.
Hoe zou ik het doen?
Ik zou het anders doen. Kijk nog even naar het voorbeeld: tekstinterface versus grafische interface. Dat gaat hier ook op. We hebben een ‘laag’ nodig tussen browser en de business logic die op de server de verzoeken van de browser afhandelt en deze vertaalt in standaard-functieaanroepen. Deze laag zou ook verantwoordelijk moeten zijn voor het oppakken van de informatie die deze functies opleveren en voor de wijze waarop het geheel in de browser wordt weergegeven.
De webontwikkeltools van tegenwoordig ondersteunen deze benadering in theorie, maar in de praktijk maken zij het er niet gemakkelijker op. Door ons één uniforme ontwikkelomgeving voor te zetten, zowel voor de gebruikersinterface als voor de business logic, kan men heel gemakkelijk het spoor bijster raken van waar welk codesegment wordt uitgevoerd. En zolang het werkt, wie maakt zich er dan zorgen over? Dit is helaas slechts een andere oorzaak van hetzelfde oude probleem, waar we mee begonnen.
Ik reken web services hier ook bij – hoewel het eigenlijk geen gebruikersinterface is. Het is een interface naar de business logic waar andere systemen gebruik van maken. Deze opzet wordt, naar ik verwacht, steeds meer gangbaar. In de meest eenvoudige vorm betekent het echter ‘re-packaging’ van afzonderlijke functies als Web Methods in een SOAP-service. Het lijkt er dan op dat we aldoor aan een service oriented architecture hebben zitten werken.
Ik weet niet welk gebruikersinterface we over vijf of tien jaar nodig hebben, behalve dan dat ik verwacht dat we alle huidige gebruikersinterfaces dan (ook) nog zullen gebruiken. Maar wat het landschap voor het applicatiegebruik ook zal zijn, ik ben ervan overtuigd dat een SODA-benadering van applicatieontwikkeling de beste manier is om elke nieuwe gebruikersinterface te ondersteunen en om de fouten van het verleden te vermijden.
Dit kan overigens ook gedaan worden met de huidige ontwikkelgereedschappen. Het vraagt echter wel de nodige discipline en inspanning. Applicaties moeten vanuit de business logic geschreven worden naar zowel de database als de gebruikersinterface. En niet toegeven aan de verleiding om toch met de gebruikersinterface zelf aan de slag te gaan, hoe gemakkelijk dat ook lijkt. Het samenvoegen van datatoegang en business logic kan het leven wel veraangenamen. Het neemt weliswaar theoretisch de mogelijkheid weg databaseonafhankelijk te zijn, maar over dat verlies is heen te komen – ik heb tot nu toe in de praktijk nog nooit een echt databaseonafhankelijke applicatie gezien. Onafhankelijk zijn van de gebruikersinterface blijkt veel belangrijker!
Alain Houf, Intersystems