Aan belangstelling voor op componenten gebaseerde applicatie-ontwikkeling (‘component based development’) is geen gebrek. De beloften zijn immers aanlokkelijk: snellere ontwikkeling, betere kwaliteit en dat alles tegen een lagere prijs. Welk bedrijf wil dat niet? Inmiddels is ook de kritiek losgebarsten op het cbd-proces. En is er verwarring ontstaan over wat er onder een ‘component’ wordt verstaan. Volgens twee specialisten op dit gebied – Ernest Angles-Isern en René van de Looij – zijn de voordelen van deze ontwikkelmethode echter pas dan te realiseren wanneer er een duidelijke visie bestaat op wat componenten zijn. Zij schetsen tevens de weg die moet worden gevolgd om deze in de praktijk te realiseren; de organisatietheorie kan daarbij helpen.
Veel organisaties worden nu geconfronteerd met de vraag of de complexiteit van hun ICT-systemen geen rem is op hun groei. Voor de uitvoering van hun primaire proces zijn zij immers rechtstreeks afhankelijk van hun ICT-systemen. De veranderende eisen die vanuit de bedrijfsvoering worden gesteld, dienen dan telkens vertaald te worden naar die ICT-systemen. Vaak is dit ingewikkeld en tijdrovend. Vooral bedrijven die al over een complexe ICT-infrastructuur beschikken, hebben te maken met dit vraagstuk.
Wie flexibiliteit en snelheid wil in het ontwikkeltraject zal eerst de verschillende aspecten van een ICT-systeem moeten ontkoppelen. Door deze ontkoppeling kunnen essentiële functionaliteitgebieden – ofwel componenten – worden geïdentificeerd. Naast flexibiliteit en snelheid door parallelontwikkeling wordt het hierdoor mogelijk om voor elk stuk functionaliteit de beste oplossing in te zetten. Zo is het belangrijk om de procesgang te ontkoppelen van de uitvoering van taken. Dat is nuttig, omdat een verandering in het proces dan geen gevolgen voor de specifieke uitvoering. Ook het ontkoppelen van functionele deelgebieden is een onderwerp waaraan aandacht geschonken moet worden, zodat wijzigingen in een specifiek deelgebied geen rechtstreekse invloed heeft op andere gebieden.
Een juiste keuze van de componenten – de onderdelen waaruit het ‘systeem’ van de organisatie bestaat – is doorslaggevend voor het succes. De eerste indeling zal moeten plaatsvinden op businessniveau op basis van de functionele deelgebieden. Deze ‘businesscomponenten’ tezamen vormen het uiteindelijke systeem. Maar wat is een component precies en hoe kan worden bepaald wat de omvang ervan is?
Groot en klein
Op de vraag wat een component is zijn net zoveel verschillende antwoorden te geven als er vragenstellers zijn. Hier gaan we uit van de volgende omschrijving: ‘een softwarecomponent is een unit met een ‘contractueel’ afgesproken interface die bepaalde taken kan uitvoeren en door andere componenten of applicaties kan worden aangeroepen’.
Ook op de vraag naar de optimale omvang bestaat geen standaard antwoord. Iedere bedrijfssituatie is anders en de omvang van een component kan per deelgebied anders worden bepaald. In de componentenwereld wordt de term granularity gebruikt om aan te geven hoe groot of hoe klein een component is. De keuze voor ‘groot’ of ‘klein’ is afhankelijk van zowel de soort applicatie als de doelgroep, dat wil zeggen de organisatie die ermee moet gaan werken.
Applicaties, die als componenten kunnen worden benaderd, worden over het algemeen aangeduid met large-grained componenten. Een voorbeeld van een large-grained component is Microsoft Word. Deze applicatie kan door andere applicaties of componenten worden aangesproken via interfaces waarvan de specificaties openbaar zijn. Op deze manier kan iedereen vanuit een eigen applicatie functies van Word aanroepen, bijvoorbeeld de spellingscontrole.
Mid-grained componenten zijn vaak de zogeheten business-componenten. Deze bevatten een aantal business regels die door verschillende applicaties worden gebruikt. Dit kunnen bijvoorbeeld componenten zijn voor het berekenen van een hypotheek of een polis. Om deze componenten voor een specifieke situatie aan te passen is het nodig een eigen component maken die van deze basis-componenten gebruik kan maken.
Bij het ontwerpen van een nieuw informatiesysteem kunnen er goede redenen zijn voor het samenbrengen en scheiden van functies in componenten. Als er bijvoorbeeld een functie nodig is om gegevens te versleutelen en te ontsleutelen, dan is het verstandig deze functie in een afzonderlijke component op te nemen zodat alle applicaties binnen een organisatie dezelfde versleutelingsmethode gebruiken.
Tenslotte zijn er de fine-grained componenten. Dit zijn componenten zoals een datumfunctie of een editbox.
Parallellen
Er bestaan grote overeenkomsten tussen het ontwerpen van componenten voor applicaties en het ontwerpen van functies in organisaties. Bij het inrichten van een organisatie zijn de volgende aspecten van belang: organisatorische stabiliteit; hiërarchie (taken, verantwoordelijkheden en bevoegdheden); capaciteiten van managers; complexiteit van processen; verwevenheid van operationele en strategische rollen; mogelijkheid tot vervanging en roulatie van functies (multifunctionele inzet); reikwijdte van controle (‘span of control’); informatiestromen (hoeveelheid, frequentie), planning & controle.
De volgende negen aspecten zijn, zij het met enige aanpassing, eveneens van toepassing op componenten: instabiliteit; hiërarchie; capaciteit van individuele componenten; complexiteit van processen; verwevenheid van functies in verschillende processen; mogelijkheden tot vervanging van componenten en multifunctionele inzet; reikwijdte van controle (overzichtelijke aansturing); informatiestromen (bandbreedte, communicatiefrequentie), en planning & controle.
Instabiliteit
Bij het ontwerpen van organisatiestructuren speelt – naast de inhoud van de functies – ook de diversiteit aan functies een rol. Het is immers moeilijk iemand te vinden die van alle mogelijke bedrijfsprocessen dermate veel weet dat hij deze met voldoende diepgang kan begrijpen. Vandaar dat het van belang is functies binnen een onderneming goed te scheiden.
Applicaties bieden steeds meer functionaliteit. Deze uitbreiding ligt niet alleen in het aantal verschillende functies dat wordt geboden, maar ook in de complexiteit van de individuele functies. Het is veelal niet haalbaar om diepgaande kennis te hebben van al deze functies. Dat betekent dat bij het wijzigen van een applicatie het moeilijk zal zijn – of zelfs onmogelijk – om een ontwikkelaar te vinden die over de benodigde kennis beschikt van alle functies binnen de applicatie.
Door het ontwerpen van specialistische, stabiele componenten kunnen applicaties worden gebouwd die eveneens stabiel zijn en als geheel meer kunnen en beter presteren. Dit wordt bijvoorbeeld bewerkstelligd door deze componenten te distribueren over verschillende machines.
Hiërarchie
In de meeste organisaties bestaat een duidelijke hiërarchie. Taken, verantwoordelijkheden en bevoegdheden worden duidelijk vastgelegd, al is de wijze waarop dit gebeurt niet uniform. Er kan gekozen worden voor een taakgerichte of procesgerichte structuur. Daarnaast kan het aantal niveaus verschillend zijn (platte of dikke organisatiestructuur).
Componenten kunnen zodanig worden ontwikkeld dat één component verantwoordelijk is voor het aansturen van andere componenten. Aansturing moet dan altijd via deze zogenaamde controller component gaan. Een component kan in dat geval dus nooit rechtstreeks met andere componenten communiceren. Een voorbeeld: een component die gegevens nodig heeft over de voorraad van een artikel moet dit via de component ‘artikel’ opvragen. Op zijn beurt roept de component ‘artikel’ de component ‘voorraad’ aan en die ontvangt de informatie over de huidige voorraad.
Binnen component gebaseerd ontwikkelen is altijd sprake van een cliënt (opdrachtgever) en een server (uitvoerder). Een uitvoerende component levert alleen op aanvraag. Door middel van toegekende rechten, zowel aan gebruikers als aan andere componenten, kan de beveiliging – zoals toegang tot data en functionaliteit – worden geregeld. Het aantal lagen kan hierbij dus sterk verschillen, al maken veel lagen de gehele applicatie onoverzichtelijk.
Capaciteit individuele componenten
In organisaties kunnen ervaren managers een eigen afdeling geheel zelfstandig besturen. Onervaren managers (en projectleiders) daarentegen hebben begeleiding (en controle/supervisie) nodig bij het aansturen van hun afdeling (of projecten) door een manager van een hoger managementniveau.
Door meer functionaliteit (vergelijk dat met de capaciteit van een manager) in een component op te nemen is minder aansturing nodig door andere componenten. Een kleine component met een beperkt aantal functies zal veelal aangestuurd moeten worden door andere componenten. Door bijvoorbeeld rechtentoewijzing en benadering van databases in aparte componenten op te nemen zal een andere component met businesskennis deze moeten aansturen. Een alternatief kan zijn om deze kleine componenten te integreren in een businesscomponent zodat veel minder communicatie tussen componenten nodig is. Een nadeel hiervan is weer dat deze grote componenten minder makkelijk te vervangen zijn dan kleinere componenten. De praktijk wijst uit dat vaak pas later kan worden bepaald welke functies moeten worden geïntegreerd in een component en welke componenten fysiek bij elkaar moeten worden geplaatst. Meestal heeft dit te maken met de prestaties en distributie van deze componenten.
Soms is het dan nodig om een aantal componenten tot een grotere component te integreren, zodat onderlinge communicatie niet meer via de communicatielaag loopt, maar intern in de component wordt afgehandeld. Ervaring en gezond verstand spelen een grote rol bij het maken van de juiste keuze hierin.
Complexiteit van processen
Bij het aansturen van afdelingen in een organisatie is het noodzakelijk dat de manager adequate kennis heeft van de primaire processen. Wanneer deze kennis ontbreekt, zal de manager zeer zwaar leunen op de mening van zijn medewerkers. De manager is echter verantwoordelijk is voor het totale proces. Fouten kunnen daarom nooit volledig worden afgewenteld op deze medewerkers. Wanneer geen of onvoldoende kennis van de onderliggende processen aanwezig is, kunnen deze processen dus ook niet worden bijgestuurd of worden verbeterd.
Voor het aansturen van componenten is het noodzakelijk dat de interne processen en functionaliteit van deze componenten bekend zijn. Wanneer deze kennis niet of slechts gedeeltelijk aanwezig is, kan onvoldoende gebruik gemaakt worden van de mogelijkheden. Door blind te vertrouwen op de functionaliteit van andere componenten kunnen fouten worden ‘geïmporteerd’. Wanneer onvoldoende kennis bestaat over de interne processen van andere componenten kunnen ook geen juiste aanbevelingen worden gedaan voor eventuele verbeteringen. Door te complexe componenten te bouwen zou het daarom kunnen gebeuren dat ze niet hergebruikt kunnen of zullen worden.
Verwevenheid van functies
Het is niet verstandig om in organisaties teams te formeren met zowel operationele als strategische taken. Bij operationele problemen worden strategische doelstellingen vrijwel altijd opgeofferd. Het korte termijn belang wint het dan van lange termijn belang.
Verder kunnen tussen de afzonderlijke teams en leidinggevenden verschillende relaties bestaan, die zijn in te delen in drie soorten communicatienetwerken: kettingnetwerk (hiërarchisch, dik, gecentraliseerd met overwegend formele contacten), sternetwerk (hiërarchisch, plat, decentraal met veel informele contacten) en volledig netwerk (matrix).
Binnen één component moeten gelijksoortige taken worden uitgevoerd. Daarnaast moeten de data van de business-logica worden gescheiden, vooral als er gegevens uit verschillende databases worden gebruikt. Verder is het vaak onwenselijk om externe applicaties rechtstreeks toegang te geven tot een database.
Bij de ontwikkeling van een component zal de aandacht op dat moment uitgaan naar dezelfde problematiek. De verschillende functies krijgen gelijke aandacht en zullen vervolgens qua kwaliteit sterk overeenkomen. Bij het ontwerpen van een applicatie kunnen verschillende architecturen worden onderscheiden: hiërarchisch versus matrix, dik versus plat, centrale aansturing versus decentrale aansturing en formele (static binding) versus informele communicatie (dynamic binding). Static binding vindt plaats op het moment van compileren, waarmee een snellere communicatie tussen componenten wordt gerealiseerd en ook type-checking plaatsvindt (er kan bijvoorbeeld geen tekst worden doorgegeven als de component een getal verwacht). Dynamic binding gebeurt tijdens run-time waardoor eventuele fouten pas bij het uitvoeren van de applicatie worden ontdekt. De keuze is voornamelijk gebaseerd op de snelheid, static binding is vaak tot veertig procent sneller dan dynamic binding.
Vervanging en multifunctionele inzet
Personeel in organisaties is in principe eenvoudig te vervangen. Ook is het herplaatsen van werknemers binnen een organisatie relatief eenvoudig. Door overleg tussen managers kunnen de capaciteiten worden vastgesteld en kunnen afwegingen over de specifieke inzet worden gemaakt. Afhankelijk van de specifieke kwaliteiten van een werknemer zal deze op een bepaalde functie op een bepaalde afdeling worden ingezet.
Door componenten te definiëren met specifieke, goed gedocumenteerde eigenschappen is het mogelijk deze op functionaliteit te vergelijken. Waar dit wenselijk is kunnen componenten worden vervangen door andere, vergelijkbare componenten. Hierdoor ontstaat een concurrentie op deelfunctionaliteit in plaats van op totale applicatiefunctionaliteit. Applicaties zijn zo op eenvoudige manier uit te breiden met nieuwe of verbeterde functionaliteit. Een component kan door verschillende componenten worden aangeroepen – waarbij iedere componentaanroep een andere betekenis kan hebben – en is daarom multifunctioneel. Een voorbeeld hiervan is een printcomponent. De printfunctie wordt afhankelijk van de instellingen op de PC aangeroepen en zal de output naar een printer of naar een bestand sturen. Het component maakt gebruikt van deze instellingen, ongeacht waar de output naartoe moet.
Reikwijdte van controle
Binnen de organisatietheorie bestaan regels aangaande de directe effectieve en efficiënte aansturing van het aantal werknemers door een manager. Dit aantal is afhankelijk van het soort en de complexiteit van het werk. Voor eenvoudig en uniform werk is dat twintig tot dertig personen. Voor complexe werkzaamheden met een grote mate van diversiteit is de reikwijdte veel kleiner, bijvoorbeeld acht personen.
Om het overzicht binnen een applicatie te bewaren en om prestatieproblemen te voorkomen moet het aantal componenten dat direct wordt aangestuurd door een andere component worden beperkt. Dit geldt eveneens voor het aantal interfaces dat door één enkele component beschikbaar wordt gesteld.
Informatiestromen
Informatie wordt over het algemeen beter uitgewisseld binnen een organisatie dan tussen organisaties. Hetzelfde gaat op voor informatie-uitwisseling binnen en tussen afdelingen. Hoe korter de fysieke afstand tussen zender en bron hoe beter de informatie-uitwisseling verloopt. Deze informatie-uitwisseling is deels formeel en gestandaardiseerd. Daarnaast is er het ‘wandelgangencircuit’. Twee personen die bijvoorbeeld veel moeten overleggen kunnen beter in dezelfde ruimte werken, omdat zij dan niet steeds hoeven te communiceren via de telefoon of e-mail.
Op het moment dat applicaties worden ontwikkeld die zijn opgebouwd uit componenten zal informatie tussen deze componenten worden uitgewisseld. Op het moment dat twee componenten veel met elkaar moeten communiceren kan het verstandig zijn deze samen te voegen (of hiervoor een speciale gegevensuitwisseling te definiëren). Dit voorkomt dat componenten via een extern middel (bijvoorbeeld het besturingssysteem of een conversieformaat) moeten communiceren.
Planning en controle
Processen binnen organisaties dienen periodiek gecontroleerd en getoetst te worden op efficiëntie en effectiviteit. Tijdschrijven en audits zijn middelen om hierin inzicht te verwerven. Wanneer een goed inzicht bestaat in de processen kunnen deze beter gestuurd worden.
Het is met name in de operationele testfase van een ontwikkeltraject van belang te weten waar de belastingen in het systeem komen te liggen. Dit kan aanleiding geven de applicatie aan te passen (bijvoorbeeld door het ontwerp aan te passen of te kiezen voor zwaardere hardware). Bij het werken volgens een CBD-methodiek zijn technieken (componenten) beschikbaar om dit meetbaar te maken.
Flexibiliteit
De organisatietheorie biedt goede parallellen om te komen tot het in componenten onderverdelen van applicaties en om te bepalen welke functionaliteiten in een component moeten worden ondergebracht. Net als in een organisatie vermindert dit de afhankelijkheid van een applicatie als geheel – een component kan immers relatief eenvoudig vervangen of opgewaardeerd worden. In dit stadium spelen de technische (on)mogelijkheden nog geen rol bij het vaststellen van de componenten. Net als bij een organisatie kan later, op het moment dat het ontwerp gereed is, uit praktische overwegingen toch voor een andere indeling (structuur) worden gekozen, waarna tot de daadwerkelijke bouw en assemblage van de componenten en applicatie kan worden overgegaan. Technische en financiële haalbaarheid kunnen dan vanzelfsprekend doorslaggevende factoren zijn.
Ernest Angles-isern René Van De Looij Cmg Finance
