'Rup en UML moeten in hapklare brokken'

20 december 2007

Ericsson zette hij aan tot componentgebaseerde softwareontwikkeling, waarmee hij het fundament legde voor het succes van de telecomgigant. Bij Rational stond hij aan de wieg van Rup en UML. Nu heeft Ivar Jacobson een eigen adviesbureau en probeert hij de softwarewereld zijn visie op het nieuwe ontwikkelen bij te brengen. Sioux Embedded Systems haalde de Zweedse goeroe naar Eindhoven in het kader van de Hot-or-Not-lezingencyclus. Bits&Chips sprak met hem.

Toen Ivar Jacobson halverwege de jaren negentig de eerste versie onder ogen kreeg van wat later UML zou worden, krabde hij zich even achter de oren. Unified Method 0.8 heette het voorstel van zijn collega’s Grady Booch en Jim Rumbaugh bij Rational Software, maar meer dan een verzameling notaties was het niet. ‘Het was geen methodologie, geen taal, het waren alleen maar dingen die je kon tekenen. Ik ging ermee naar de baas van Rational en zei tegen hem: ‘Dit is heel onprofessioneel. Hier wil ik mijn naam niet onder zetten.’ We hadden dus gelijk al een harde noot te kraken. Wat gingen we doen? Wilden we notaties of een echte taal? Uiteindelijk besloten we voor het laatste en om die beslissing kracht bij te zetten, veranderden we de naam van Unified Method in Unified Modeling Language.’

Van de ‘Three Amigos’, de geuzennaam die het Rational-trio later zou krijgen, was Jacobson echter de enige die verstand had van taalontwerp, gepromoveerd als hij was op taalbouwstenen voor realtime systemen. Booch en Rumbaugh waren methodologisten. ‘Ze konden diagrammen tekenen en hadden een voorstelling in hun hoofd van wat die betekenden, maar de semantiek was niet expliciet. Ik vond echter dat als we een taal gingen ontwerpen, dat we dan ook de klassieke technieken daarvoor moesten volgen. Dus eerst formeel een concrete syntax beschrijven waarin je de vorm van de taal vastlegt, dan een abstracte syntax maken, vervolgens in de statische semantiek zeggen wat de taalvormen betekenen en ten slotte in de operationele semantiek aangeven hoe een computerprogramma dit moet uitvoeren.’

Alles formeel beschrijven, zagen Booch en Rumbaugh niet zitten. ‘Dat vonden ze te complex. Daar heb ik me toen bij neergelegd. Sommige gevechten moet je niet willen aangaan en dit was er zo eentje. Ik heb wel nog even mijn ongenoegen geuit tegenover onze baas, maar die zei: ‘Ivar, het gaat hier om business.’ Toen hebben we dus UML 1.0 gemaakt. Grady en Jim hebben daarbij 80 procent van de klus gedaan. Ik kon niet werken zo, dus ik zag er vanaf de achterbank op toe dat niet alles in de soep liep. En ik zorgde ervoor dat de dingen erin kwamen die ik belangrijk vond: mijn eigen use-cases en subsystemen bijvoorbeeld. Heel snel, in drie, vier maanden, hadden we het af.’ Begin 1997 boden ze de specificatie aan aan de standaardenclub Object Management Group (OMG).

Na aanvankelijke positieve geluiden zwol de kritiek langzaam aan, vooral van concurrenten die soortgelijke initiatieven hadden ontplooid. Op dat moment werkte IBM met Object Time bijvoorbeeld aan een eigen ontwerp. ‘Zij vonden onze taaldefinitie zeer onprofessioneel en weigerden haar te adopteren. Schoorvoetend kwam mijn baas me toen zeggen dat we misschien een beetje professioneler te werk moesten gaan en ook Grady en Jim erkenden dat ik toch wel gelijk had. In negen maanden hebben we de heleboel vervolgens geformaliseerd volgens mijn oorspronkelijke voorstel. Alleen voor de operationele semantiek bleek dat te lastig. Dat zou bovendien allemaal op mijn bordje terechtkomen en daar had ik ook weer geen zin in. Dus heb ik voor dat deel toen genoegen genomen met goed gestructureerd Engels. In september 1997 hadden we UML 1.1.’

Groeien en groeien

Het resultaat noemt Jacobson ‘fantastisch’. ‘De acceptatie was volkomen. Van de 26 verschillende methodologieën die er waren vóór UML 1.1 heeft geen enkele het overleefd. Onze taal heeft ze allemaal om zeep geholpen.’ Toch is niet alles goud wat er blinkt, erkent hij. ‘Uit wiskundige hoek klinkt nu de kritiek dat UML niet echt goed is gedefinieerd. De bekende informaticaprofessor David Parnas noemt het zelfs de ‘Undefined Modeling Language’. Ik denk dat hij overdrijft. Zo erg is het niet. Maar wat we deden, was een compromis en dat wisten we. Om een blijvertje te zijn in de softwarewereld zullen ook academici UML moeten accepteren. Daarom verwacht ik dat we de boel op een gegeven moment weer op de schop nemen.’

Versie 2.0 van drie jaar geleden is een stap in de goede richting, meent Jacobson, alhoewel de weg ernaartoe ‘echt verschrikkelijk’ was. ‘Dit keer lag de regie bij een speciale OMG-werkgroep, waarin ongeveer twintig mensen uit de industrie zaten. Hun oorspronkelijke mandaat was slechts om te repareren wat er stuk was. In plaats daarvan deden ze een volledig herontwerp, waarbij iedereen zijn eigen stokpaardje inbracht. Ze veranderden te veel. Zo vernam ik op een kwade dag dat mijn use-cases op de schopstoel zaten. De term moest wel blijven, want die was populair, maar ze wilden er een andere invulling aan geven. Uiteindelijk moest Rational dreigen met terugtrekking uit het hele UML-initiatief, voordat ze de beslissing terugdraaiden.’

Desondanks gaat Jacobson voor de meest recente versie, als hij moet kiezen tussen UML 1.1 en 2.0. ‘Maar dan nog zou ik zeggen: gebruik er niet meer dan 20 procent van. Beschouw de andere 80 procent als iets dat je alleen nodig hebt bij zeer speciale problemen. Sommige onderdelen zul je waarschijnlijk nooit gebruiken. UML 2.0 heeft zeker goeds in zich, maar er zit te veel in. Als product van een community is het maar blijven groeien en groeien zonder goeie reden. Over twintig jaar zal UML er nog steeds zijn, en gebruikers zullen het nog steeds waarderen, maar ze zullen moeten kiezen wat ze ervan toepassen.’

Zelf zou Jacobson UML aanzienlijk versimpelen, overigens zonder de semantiek wezenlijk te veranderen. ‘Het zou goed zijn om het te herdefiniëren zodat het gestructureerder is en toegankelijker. Nu beslaat UML zo’n duizend pagina’s. Die gaat niemand allemaal doornemen, behalve misschien de toolverkopers die de taal ondersteunen met gereedschap. Ik heb zelf al die bladzijden nooit gelezen en ben dat ook niet van plan. Ik had graag een veel kleinere kern gezien en daarbovenop gebouwd, de sleutelideeën geïdentificeerd en dan andere zaken toegevoegd in de vorm van aspecten, zodat de kern ongewijzigd blijft. Aspectoriëntatie is heel succesvol in China en Japan. Sony zegt zijn kosten daardoor met meer dan 70 procent te hebben teruggebracht. In de westerse wereld is het echter nog niet erg aangeslagen.’

Kaartspel

Ook het Rational Unified Process (Rup), het andere wereldberoemde kindje van Jacobson, is uit zijn voegen gebarsten. ‘Vanuit technisch oogpunt is Rup misschien wel de meest succesvolle ontwikkelmethodologie die we ooit hebben bedacht. Zo succesvol dat iedereen met een idee dat er op een gegeven moment in wilde hebben. Daardoor werd het proces steeds groter, te groot. Inmiddels beslaat Rup maar liefst zesduizend bladzijdes. Ook die gaat niemand allemaal lezen. Maar experts willen er nou eenmaal alles in stoppen dat ze kunnen. Zo is de natuur.’

Met zijn adviesbureau, dat hij begon na zijn vertrek bij Rational in 2003, werkt Jacobson nu aan een manier van software ontwikkelen die een stuk behapbaarder is. Essential Unified Process (Essup) heet de methode, die het goede van Rup verenigt met het beste van Agile en Capability Maturity Model Integration (CMMI). ‘Als eerste hebben we het Unified Process herontworpen in wat wij practices noemen: goede ontwikkelgewoontes. Wij spreken over ‘gewoontes’, over manieren van werken, omdat ‘proces’ zo’n beladen woord is geworden. Die practices hebben we gecombineerd met patronen voor social engineering uit Agile. Zo hoef je niet alles te documenteren wat je doet, waardoor een lichte werkwijze ontstaat. Verder hebben we ideeën toegevoegd uit het CMMI-kamp. Daar hebben ze geen oplossing voor het bouwen van goede software, maar weten ze wel hoe ze processen moeten meten en verbeteren. Het resultaat is een verzameling practices waaruit je er zo veel kunt kiezen als je nodig hebt. Vind je use-cases leuk, gebruik je die. Zoniet, dan gebruik je bijvoorbeeld featuregedreven ontwikkeling of user-stories.’

Belangrijkste feature van Essup is dat gebruikers ideeën van over de hele aardbol kunnen halen en kunnen koppelen aan hun manier van werken. Om dit te faciliteren, hebben Jacobson en zijn consultants het Esswork-platform ontwikkeld waarop de wereld haar practices kan publiceren. ‘De beste gewoontes vind je nooit binnen één bedrijf. Daarom besloten we de deuren open te zetten. Op Esswork kunnen mensen hun ideeën uitwisselen. We hebben niet de illusie dat we iedereen op dezelfde manier kunnen laten werken, maar het is goed om te documenteren hoe je doet wat je doet, zodat anderen dat kunnen bestuderen en vergelijken. Met Esswork als gemeenschappelijk raamwerk kan die kennis zich verspreiden. Het zou geweldig zijn als het platform uitgroeit tot een wereldwijde knowledge base.’

Essup heeft in ieder geval al aardig wat medestanders gevonden. ‘Microsoft heeft het geïntegreerd in zijn Visual Studio Team System. Ook zitten we al in Eclipse en Web 2.0.’ Jacobson benadrukt dat hij zich niet wil binden aan één partij, zeker niet als het gaat om ondersteunend gereedschap voor het proces. ‘Voor onze practices leunen we niet op een specifieke toolverkoper. We zijn volledig agnostisch. Toolverkopers hebben vaak de neiging om hun klanten gevangen te houden. Als ze je te pakken hebben, kom je er niet meer weg. Dat is een van de grote makkes in de softwarewereld. Onze methodologie kun je gebruiken zonder vast te zitten aan specifiek gereedschap. We bieden wel bruggen, adapters, naar tools van bijvoorbeeld Microsoft of Rational, maar de strakke integratie laten we over aan anderen.’

Esswork draait nu proef bij twaalf bedrijven. ‘Op dit moment werken we alleen nog met geselecteerde klanten. Die zitten over de hele wereld: in China, in Groot-Brittannië, in de Verenigde Staten, in Zweden. Zij passen Essup toe boven op Esswork, dat daarbij dient als infrastructuur waarop ze een breed scala aan tools integreren. Dit vergt een flinke investering in hun ontwikkelorganisatie. Zo krijgen ze van ons een stevige training in het gebruiken en bouwen van practices. De eerste resultaten verwacht ik over een paar maanden.’

Als de proef slaagt, wil Jacobson Esswork gratis gaan aanbieden. Gebruikers betalen alleen voor de consultancy die nodig is om hen op weg te helpen met het nieuwe ontwikkelparadigma. ‘We willen het zo snel mogelijk verspreiden. Mijn idee is dat het allemaal downloadbaar wordt. Nieuwe gewoontes maak je je eigen via e-learning, op het moment dat het jou uitkomt. Om een practice toe te voegen aan jouw manier van werken, gebruiken we in Esswork een generiek spelbord en elektronische kaartjes. Eerst breng je jouw werkwijze in kaart door de kernaspecten daarvan op eigen kaartjes te schrijven en deze uit te leggen op het bord. Voor de gewoonte die je wilt toevoegen, kun je vervolgens van Esswork een standaard kaartenset met kernaspecten halen en die integreren op het speelveld. Op dit moment hebben we acht sets beschikbaar, maar daar komen er voortdurend bij. Met een van onze klanten werken we bijvoorbeeld aan een Scrum-practice.’

Jonge hond

Het had weinig gescheeld of de softwarewereld was geheel verstoken gebleven van Jacobsons kunsten. Dat we die nu toch kunnen aanschouwen, hebben we te danken aan zijn tante, die de jonge Ivar eind jaren vijftig aanmeldde voor een studie elektrotechniek aan de Chalmers University of Technology in het Zweedse Gotenburg. ‘Toen ik van de middelbare school kwam, had ik geen idee wat ik wilde doen. Mijn beste vakken waren natuurkunde, scheikunde en wiskunde, maar zelfs daar haalde ik niet al te hoge cijfers voor. Ik denk dat ik een van de laatsten was die ze in mijn jaar toelieten op Chalmers. Van de zes-, zevenhonderd was ik tweede reserve of zoiets.’

‘Ik had ook helemaal geen zin om mijn geboorteplaats Ystad te verruilen voor het driehonderd kilometer noordelijkere Gotenburg. Ik had andere interesses: handbal, voetbal, ik hield van dansen. Maar mijn tante heeft me min of meer gedwongen’, lacht Jacobson. ‘Zo zorgde ze er bijvoorbeeld persoonlijk voor dat ik mijn baantje als leerling-elektricien kwijtraakte. Toen mijn baas van haar hoorde dat ik was toegelaten op Chalmers, wees hij mij prompt de deur om mij te dwingen te gaan studeren.’

Op de universiteit raakte Jacobson dan toch besmet met het techniekvirus, maar niet nadat hij er eerst een tijdje tussenuit was geknepen om als gids te werken in Griekenland. ‘Chalmers heeft mijn interesse voor techniek gewekt, maar na twee jaar ging ik me toch vervelen. Soms heb je een pauze nodig, want toen ik terugkwam van mijn Griekse avontuur, had ik meer motivatie dan ooit. Vooral onderzoek trok me. In mijn derde en vierde jaar heb ik naast mijn studie zelfs parttime gewerkt als researcher voor de universiteit. In 1962 ben ik afgestudeerd.’

Via een vriend belandde hij bij Ericsson in Stockholm. ‘Ik had ook gelijk kunnen gaan promoveren, maar ik besloot om eerst even van het buitenschoolse leven te gaan proeven en een jaartje bij een of ander saai bedrijf te gaan werken om erachter te komen hoe dat was. Dat saaie bedrijf werd Ericsson. Na een jaar was het me duidelijk: dit was wat ik wilde. Ik hield ervan projecten te leiden en als snel werd ik projectmanager. Als zodanig belandde ik een paar jaar later bij de afdeling Stored Program Control System, waar vijfenzeventig man werkte aan de volgende generatie telefoonswitches. De toekomst van Ericsson.’

In plaats van de brave projectmanager te spelen, zorgde Jacobson daar voor een kleine aardverschuiving. ‘Met mijn achtergrond in de hardware had ik verstand van systemen, maar geen kaas gegeten van software. Dus studeerde ik ’s nachts op de assemblercode die mijn ontwikkelaars produceerden om de volgende dag uitleg te vragen bij wat ik niet snapte. Toen ik na drie maanden het gevoel had dat ik het begreep, stapte ik naar mijn baas en zei ik tegen hem: ‘Dit wordt nooit een product. Je gooit je geld weg.’ Mijn leidinggevende kreeg schrik en nam me mee naar zijn chef, die me weer doorverwees naar zijn superieur, de eerste met verstand van techniek. Die vroeg me of ík dit kon oplossen. Jonge hond als ik was, dacht ik natuurlijk van wel. Maandagmorgen wilde hij mijn rapport op zijn bureau hebben. Dat zei hij op vrijdag.’

Verkleefd

Dat weekend schreef Jacobson een vijfentwintig pagina’s tellend document waarmee hij een revolutie ontketende die Ericsson de koppositie zou bezorgen in telecom. ‘Ik had een nieuwe methodologie bedacht, alleen wist ik dat toen zelf nog niet. Ik had gewoon een architectuur ontworpen, op basis van componenten met zowel code als data.’ Daarbij incorporeerde de Zweed technieken die nu nog steeds actueel zijn. ‘Activiteitsdiagrammen, sequentiediagrammen en toestandsdiagrammen, het zat er allemaal al in. Veel daarvan hebben we later overigens weer gebruikt in de nog altijd populaire SDL-taal, en natuurlijk in UML.’

De resulterende componentaanpak viel de softwaremensen koud op hun dak. ‘Die waren gewend om de data in een aparte database te stoppen en vervolgens code te schrijven om de gegevens te manipuleren. Probleem daarmee is dat een verandering op één plek oncontroleerbare effecten heeft op andere delen van de code. Mijn oplossing: stop code en data in componenten en maak de gegevens alleen toegankelijk via messaging. Dan houd je de interface stabiel en de evolutie van een systeem controleerbaar.’

Voor de nieuwe methodologie maakte Jacobson dankbaar gebruik van zijn hardwareachtergrond. ‘Als ik een softwareman was geweest, dan had ik ongetwijfeld vastgehouden aan de bestaande manier van werken. Maar nu had ik lak aan wat we in het verleden hadden gedaan. Mijn doel was hergebruik en dat zag ik niet gebeuren met de manier waarop wij software bouwden. Dus greep ik terug op mijn kennis van de hardwarewereld. Daar ontwikkelden we toen al componentgebaseerd: eerst identificeerden we dozen en vervolgens de interfaces daartussen. Dat kopieerde ik naar de software. Voor informatici bleef het echter een manier om hardware te maken, en dus ouderwets. Veel steun hoefde ik van hen dan ook niet te verwachten.’

Ondanks de aversie uit softwareland sloeg de benadering aan. Met steun van anderen ontwikkelde het vuurtje van Jacobson zich tot een uitslaande brand. ‘Rond 1972 konden we over componenten spreken tot op het niveau van de firmware, inclusief het besturingssysteem en het databasebeheer. Terwijl mensen aan het bellen waren, konden we de onderliggende managementsoftware wijzigen zonder het telefoontje te verstoren. Dit gaf Ericsson een voorsprong en uiteindelijk de overwinning in de telecommarkt. Later is de componentaanpak ook opgepikt in andere toepassingsgebieden, maar het is begonnen in de telecom.’

Naar de zin van Jacobson bleef de methodologie binnen Ericsson echter te veel verkleefd met het product. ‘De enige manier waarop ik de aanpak naar buiten toe kon uitleggen, was door het te hebben over het product. Mijn volgende missie was dan ook om dat te scheiden door de methodologie in onafhankelijke bewoordingen te definiëren. Het bedrijf heeft me toen geld gegeven om daar een promotieonderzoek naar te doen. In 1985 mondde dat uit in een proefschrift over taalconstructen voor grote realtime systemen. Daarin heb ik de basis gelegd voor UML.’

Pensioen

Veel waardering voor zijn revolutionaire ideeën kreeg Jacobson aanvankelijk niet van Ericsson. ‘Tijdens mijn laatste functioneringsgesprek vroeg mijn baas, die nota bene mijn promotie had betaald, of ik een alternatief had voor mijn werk. Toen ik daarop bevestigend antwoordde, raadde hij me met klem aan om die kans te grijpen. Op de werkvloer was de stemming niet anders. Ik kon het voelen, ik kon het ruiken als ik door de gangen liep. Sommige mensen zeiden me niet eens gedag omdat ze vonden dat ik hun toekomst aan het verwoesten was. Ericsson verdiende nog altijd bakken met geld aan een product dat ik vijf, zes jaar eerder al had opgegeven.’

In 1987 moest Jacobson dan ook zijn biezen pakken, officieel omdat het bedrijf financieel in zwaar weer verkeerde. Erg rouwig was hij er niet om. ‘Ik was ervan overtuigd dat ik geld zou verdienen zodra ik ook maar een stap buiten de deur zou zetten. En dat was ook zo.’ Hij startte zijn eigen bedrijf Objective Systems, een naam die hij later veranderde in Objectory. Dat liep zo goed dat Ericsson vier jaar later alweer op de stoep stond om hem op te kopen, en gelijk weer voor een nog betere prijs van de hand te doen aan Rational Software.

Jacobson stond niet bepaald te springen om een overgang naar Rational. ‘Dat waren Ada-jongens. Ada, ouderwets Ada. Bovendien hadden ze niks met objectoriëntatie en nog minder met processen. Goed, Grady Booch werkte er en pushte objecten. En ook hadden ze net Jim Rumbaugh in dienst genomen. De enige reden waarom ze mij wilden hebben, was om ons drieën samen te krijgen. Uiteindelijk namen ze echter zowat het hele businessmodel van Objectory over met de driedeling tools, processen en diensten.’

Toen Rational in 2003 in handen kwam van IBM, was dat het sein voor Jacobson om te vertrekken en kwam er een einde aan de samenwerking tussen de Three Amigos. ‘Dat waren toch mooie jaren. Ik wilde ook niet weg, maar ik had geen keus. Er waren te veel tegenstrijdige belangen. Ik bruiste van de ideeën en Rational wilde daar wel in meegaan. Maar bij IBM ging het er niet om dat je managers achter je stonden, maar dat de mensen van human resources en de advocaten het met je eens waren. Dat zag ik niet zitten.’

Met Ivar Jacobson Consulting, dat hij kort na zijn vertrek bij Rational startte als onderdeel van Ivar Jacobson International, heeft de inmiddels 68-jarige Zweed weer de vrijheid om te doen en laten wat hij wil. Aan zijn pensioen denkt hij voorlopig niet. Zijn werk is nog niet af. ‘Bij de oprichting van Objectory in 1987 kreeg ik de vraag hoeveel procent kans ik dacht dat we hadden om de softwarewereld te veranderen met onze ideeën. 3 procent, antwoordde ik toen. Daarna ben ik me dat blijven afvragen en in 1995, bij de overname door Rational, zat ik op 100 procent. Toen wist ik zeker dat we impact hadden op de manier waarop mensen software ontwikkelen. Als je het me nu vraagt voor Essup en Esswork, dan zeg ik: we zitten nog lang niet op 100 procent, maar wel ruim boven de 3 procent. Het is ongeveer 30 procent, en groeiende.’

Op 5 november sprak Ivar Jacobson in Eindhoven tijdens de Hot-or-Not-lezingencyclus van Sioux Embedded Systems, waarmee het bedrijf de embedded-gemeenschap bewust wil maken van nieuwe ontwikkelingen in het vakgebied. In 2008 gaat de cyclus verder met goeroepresentaties van Alan Cox over de toekomst van Linux (5 maart) en Alistair Cockburn over het Agile Manifesto (12 juni). Meer informatie is te vinden op: www.jouwontwikkelingtelt.nl.

Nieke Roos

Terug naar overzicht