Fragmentatie .NET baart ook Microsoft zelf zorgen
“Omdat frameworkteams bij Microsoft zoveel sneller managed-code-software kunnen ontwikkelen dan ze ooit met C++ zouden kunnen, zijn hun inspanningen fors versneld. Ze hebben niet langer de tijd om met andere teams te coördineren, omdat dat een bottleneck zou worden voor het de deur uit krijgen van hun eigen inspanningen. In een cultuur als die van Microsoft, waarin het gereed krijgen van software boven alles gaat, wordt zo’n bottleneck snel gepasseerd.” Het resultaat is een geheel dat te groot en te complex wordt voor .NET-ontwikkelaars om nog te kunnen bevatten, meent Hollis. Wellicht moet Microsoft te zijner tijd nog een extra abstractielaag boven op .NET zetten, suggereert hij.Maarten Sikkema, technisch directeur van Microsoftpartner Macaw, ziet die abstractielaag niet komen. “Dat lijkt mij niet nodig.” Toch herkent hij zich wel in het verhaal. “We merken dat er in de loop der tijd verschillende stijlen en patronen worden toegevoegd, waarbij je echt moet gaan kiezen.” En dat kiezen wordt steeds lastiger, stelt Sikkema. “Er zijn voor sommige problemen heel veel verschillende oplossingen. Datatoegang, webservices, de userinterface. Daar komen allemaal steeds meer frameworks en toevoegingen voor die dan een bepaald type probleem heel mooi oplossen, maar misschien een ander type probleem minder mooi.” Sikkema noemt als voorbeeld LINQ to SQL, het Entity Framework en ADO.NET. “Heel mooie technologieën die op een volledig andere manier ongeveer hetzelfde proberen op te lossen.”Bij Macaw wordt daarom enigszins gestandaardiseerd. “Als je kiest, hoef je niet alles te ondersteunen en alles te kennen. Zo proberen we de onderhoudbaarheid en de overdraagbaarheid zo goed mogelijk te houden. En je hoeft ook niet alles te gebruiken.”Ook Dick Dijkstra, softwarearchitect bij Getronics, vindt het een “heel herkenbaar” verhaal. “Microsoft heeft bijvoorbeeld Workflow Foundation uitgedacht in .NET 3.0. Een hele mooie manier om workflows te maken. Maar daarvoor hadden we ook al Biztalk. Dat overlapt deels en het is best lastig daar een keuze in te maken op het moment dat je in een project een workflow moet gaan bouwen.”Zijn aanpak is vervolgens vooral navragen hoe anderen ermee omgaan. “Workflow Foundation past meer bij menselijke interactie en de orkestratie van Biztalk meer bij procesautomatisering. Maar aan die informatie zijn we gekomen doordat we er zelf een beetje mee geëxperimenteerd hebben en door informatie vanaf internet of partners.”Een nieuwe abstractielaag over .NET heen lijkt Dijkstra op termijn wel een goed plan. “Neem het Windows Communications Framework. Er waren veel verschillende manieren om met elkaar te communiceren – webservices, MSMQ en noem maar op – en Windows Communication Framework als abstractielaag maakt dat een stuk eenvoudiger. Als ze hetzelfde kunnen doen over .NET heen, dat zou het ons werk vergemakkelijken. Maar het klinkt wel heel ambitieus; ik zie het eerder ontstaan voor onderdelen, zoals workflow.”Een toenemende specialisatie in onderdelen van het .NET-platform is onontkoombaar, ervaren zowel Dijkstra als Sikkema. “Het wordt ook in toenemende mate een uitdaging om onze projecten goed te blijven organiseren,” zegt Sikkema. “Je moet op een andere manier met je mensen omgaan. Een groep mensen naar een klant sturen waar ze alles doen, dat gaat in toenemende mate niet meer werken. Je moet de juiste specialist op het juiste moment in het juiste project zien te krijgen. Dan hoeft hij misschien maar een paar dingetjes te doen, maar als iemand anders het doet, ben je daar misschien weken tijd aan kwijt.”Ook Dijkstra merkt dat. “Biztalk-specifieke zaken zijn bijvoorbeeld wezenlijk anders dan Workflow Foundation. Stel dat je heel goed bent in het maken van Biztalk-orkestraties, dan hoeft dat helemaal niet te betekenen dat je ook Workflow heel goed kunt doen. Dat brengt natuurlijk nogal wat problemen met zich mee op het gebied van training.”