VSTS en RUP

Op mijn blog van 27 mei over VSTS en RUP heb ik vandaag een reactie gekregen van Eddy. Mijn antwoord op zijn vraag zou eigenlijk een blog kunnen zijn, dus hier komt ie nog 's voor die grote groep lezers. Eddy's vraag was hoe we momenteel kijken tegen de integratie van RUP met VSTS:

Behalve een beeld van de integratie zijn we momenteel zelfs zo ver dat we een RUP-variant (onze) inmiddels als een process template in VSTS hebben opgenomen en daarmee nu ervaringen opdoen. Die ervaringen zijn, zoals te verwachten, nogal dubbel. Aan de ene kant kun je in Team System op basis van de work items best wel heel goed use case driven en iteratief werken, en met een beetje moeite kun je ook de fasen en iteraties wel benoemen en daar naar leven. Maar het blijft lastig dat je a. een workitem niet kunt opsplitsen in sub-items voor het miniteam dat conform RUP hoog interactief met dat workitem aan de slag moet en b. natuurlijk dat het deel Requirements Engineering, Analysis & Design (het conceptuele stuk, met UML) niet is geintegreerd. Je moet dus nog steeds buiten de sterke integratie om aan het werk en dat verzwakt, in een puristische RUP omgeving, de kracht van VSTS enorm.Op dat laatste punt anticiperen we nu met dat we een onderzoeksproject hebben gestart om Borland's CaliberRM aan Team System te koppelen. Wellicht dat we dan nog meer integratie kunnen realiseren en dus ook RUP meer kunnen invullen dan nu.

Afterthought

Dit was het dan, de Teched Europe 2005. Ik heb helaas niet alles kunnen meemaken en heb ook maar 1 gadget kunnen 'scoren'. Toch was het weer een geweldig event dat onze grijze cellen weer aardig heeft mogen trainen. Voor velen is het maandag weer back to reality. Ik ga straks lekker op vakantie en kom pas over 3 weken weer terug. Het worden mijn eerste drie weken zonder Internet sinds 1996 geloof ik. Duim voor me.

Interview met David Vaskovitch

Vanmiddag hadden we, de Teched Bloggers, de gelegenheid om met David Vaskovitch te praten en hem vragen te stellen. We hebben eerst zijn keynote van gisteren onder de loep genomen. David was eigenlijk verbaasd door onze kritische kanttekeningen. In de keynote vertelde hij bijvoorbeeld dat 17000 mensen bij een airline eigenlijk overbodig werk deden en dat dat allemaal geautomatiseerd moet worden. Wat doe je nu met die mensen? (Antwoord David) Ander, slimmer en leuker werk aanbieden en misschien wel bij die zelfde vliegmaatschappij. Interessante gedachte. In zijn visie wordt software overigens niet makkelijker, maar juist complexer. Niet in de zin van het 'domme' werk zoals repeterend programmeren (dat moet je weer automatiseren), maar door de diversiteit die we steeds meer gaan krijgen. Smartphones, home theaters en digitale camera's zullen straks naadloos moeten kunnen communiceren.

Team System nu ook voor Eclipse?

"The VSTSEclipse project started with a conversation about how Eclipse users could utilize Visual Studio Team System, Microsoft's software-development lifecycle solution. In this article, I introduce the VSTSEclipse project, state its goals, and explain how it can impact the development community. I then examine two major components of the project. In future articles, I will detail specific development issues and components. But first, a little background.”, aldus Joe Sango, initiatiefnemer van het VSTS-Eclipse Project. Je kunt het artikel (bijna) vinden op http://www.ddj.com/documents/s=9825/ddj0508e/0508e.html.

En toen was het party

Een party in de RAI? Ik had nog nooit een Teched party meegemaakt van de Teched Europe, dus was vol verwachting naar de zaal gegaan met een aantal collega's. Verwend door de catering in Orlando en San Diego, waren de verwachtingen duidelijk iets te hoog. In Europa heeft men het liefst frietjes met een hamburger en ketchup op tafel! Een hele ervaring.
Verderop werd volop getapt en dat maakte weer een hoop goed (tappen kunnen ze in de US niet ...). Toen de muziek begon, moest ik helaas het battlefield weer verlaten, want er was nog een A2 Racer in het verschiet en morgen mogen we nog een keer. Misschien dat ik dan ook even tijd heb om nog een paar gadgets te scoren in de Exhibition Hall en wie weet scannen ze m'n naam wel en win ik nog een nieuwe baan (de recruiters schijnen op iedere hoek te loeren ...)

CHT028 Performance, Scalability and Availability

Vlak voor het feest nog "even" een Chalk-and-Talk meemaken met Arvindra Sehmi en Ingo Rammer. Het werd een aardige interactieve discussie over het hoe en waarom testen en bewaken van met name performance en schaalbaarheid van applicaties. Er werd hier en daar wat over code geroepen en ook werd er soms op een architectuur niveau over gesproken. Er waren dus duidelijk twee groepen mensen in de zaal. Bottom-line was mijns inziens dat performance heel erg belangrijk is en dat de verantwoordelijkheid bij de architect ligt, maar dat hij heel erg afhankelijk is van de diepe technische kennis van zijn professionals (developers). Wie wil er nog zeggen dat een architect een makkelijk baantje heeft?

Een heel aardige bijkomstigheid, maar volgens mij ook een van de meest waardevolle kenmerken van een CHT, is dat een Noorse collega straks naar huis gaat met een hele rij goede tips van andere deelnemers. Ik wens hem veel succes.

ARC411 DSL tools

Ik mocht vanochtend weer absent zijn voor de sessies, maar gelukkig was ik op tijd om mee te maken hoe de laatste stand van zaken is rond de DSL tools. Een toolkit om toolkits te maken die een toolkit zijn voor het maken van applicaties. Het gaat hier inderdaad om hogere wiskunde. Steve Cook heeft ons er professioneel door heen geloodst, maar klaar is het inderdaad nog niet.
Ik denk wel dat het concept van de DSL's erg veel mogelijkheden en deuren opent om de software ontwikkeling aanzienlijk te professionaliseren, maar ik mis toch ook nog weer dat hogere conceptuele level (waar David Vaskovitch het ook nog even over had in zijn keynote) dat programmeren op den duur overbodig moet maken. DSL automatiseren delen van de code, maar maakt die code nog wel... Wanneer zal "code" dezelfde status gaan krijgen als Assembly Language dat anno 2005 heeft?

Nog een keynote die (niet) inspireerde

Sander Gertz vat de keynote van David Vaskevitch goed samen (see here), maar toch ook nog een paar tekortkomingen van mijn kant.

Het verhaal begon eigenlijk best wel goed, inspirerend en veelbelovend eigenlijk ook wel. Eerst even terug, maar liefst 50 jaar, en dan de quote van Steve Balmer van vorig jaar nog even herhalen (zie ook mijn blog entry van ###). Toen begon het voor mij helaas weg te vervagen. De komende 10 jaar? Vijf dromen? Ik heb er wel 10 per dag, vooral tijdens een event als de Teched. Wie zit er dan niet vol met al die nieuwe mogelijkheden die we nog moeten uitwerken, waar we van gekkigheid niet meer weten wie dat ook al weer wanneer gezegd had en in welke context. Dromen dromen, mogelijkheden en maandag weer op kantoor komen en verbaasd aangekeken worden door je collega's dat het wellicht heel interessant is geweest, maar nu weer terug op aarde a.u.b. Maar goed, David noemde 5 dromen, hoge droomkunde dromen, want tenminste 1 had ook nog subdromen (heb je die ook wel 's, heel erg verhelderend ...).
Als het inderdaad zo is dat onze dromen gaan leiden tot het vervagen of zelfs verdwijnen van het mens-mens contact, omdat we geen geld meer aan de balie willen pinnen, niet meer met dat aardige meisje in de boekwinkel willen praten over dat goede boek dat je samen zoekt in de nissen van de winkel (wie wil dat niet), alleen nog met enterprises willen lunchen waar nog maar 17.041 - 17.000 = 41 medewerkers in dienst zijn, dan stap ik vandaag nog uit deze branch en wordt, ja wat eigenlijk, ... Dat heeft David een beetje verzuimd, wat is onze toekomst eigenlijk in die "new world of work".

Morgen mag ik ook bij het interview met David zitten. Ik heb al een paar aardige vragen voor hem klaar liggen. To be continued.

Een dag zonder sessies, maar wel een hele leuke Dutch Drink

Ik zag dat ik het door de files niet ging redden om de eerste sessie nog op tijd mee te maken, en omdat ik om 12 uur al weer richting kantoor moest voor het geven van een cursus, is het helaas een dag geworden zonder extra kennis. Gelukkig werd ik bijgepraat op de goed bezochte Dutch Drink in Cafe Helden. Er was lekker eten, een heerlijk toetje, goede bediening (!) en natuurlijk alle verhalen over wat ik heb mogen missen. Vooral de sessie over Indigo had indruk gemaakt, want die kwam vaker naar voren.

Nou, morgenmiddag ben ik weer van de partij.

Lunch met Steve Cook

Na zijn sessie over de Software Factory hebben we een lunchgesprek met Steve Cook gehad in een restaurant direct naast de RAI (Vis aan de Schelde, zeer aan te bevelen). Steve heeft daar gepassioneerd verteld hoe je een Software Factory moet aanvliegen, waar moet je beginnen etc. Zijn verhaal kwam er op neer dat een Software Factory een geautomatiseerde ontwikkelstraat is en dat je die moet laten aangroeien. Begin heel klein door iets wat je vaker ziet, in een module te stoppen, te automatiseren en breidt dat incrementeel uit. Pas als je een aardig eind op weg bent met het automatiseren van delen van je applicaties, is het tijd om een DSL er bij te bedenken. Misschien is dat wel niet nodig, maar het advies was vooral, ga niet top-down aan de slag met het ontwerpen en uitontwikkelen van een DSL en vooral niet als actiepunt 1.

Op de vraag of een Software Factory ook geschikt is voor een niet softwarebedrijf, bijvoorbeeld een verzekeraar, was het antwoord volop "ja", maar wel met de aantekening dat het er dan heel anders uit zou moeten en gaan zien dan voor een ISV. Een softwarebouwer zou vooral business functies of logische onderdelen willen automatiseren, een IT-afdeling van een enterprise heeft vaker te maken met unieke applicaties en zou bijvoorbeeld voordeel kunnen halen uit het automatiseren van interfaces of bijvoorbeeld security, logging etc. Genoeg voer weer om over na te denken.

Tussendoor hadden we overigens nog een discussie over UML en MDA. Steve is daar heel expliciet over. Hij noemde 4 definities van MDA en gaf daarbij aan dat Microsoft (nog) niet van plan is om het programmeren over te slaan (MDA definitie #4), maar dat het maken van software vergemakkelijkt en gestructureerd moet worden door bijvoorbeeld automatisering van de 80% ontwikkelwerk dat we al 's eerder gedaan hebben.
Zoals je zult merken aan de onderwerpen was de lunch niet voorbij toen m'n volgende sessie zou starten. Die dus maar overgeslagen...

ARC302 Building en using a Software Factory

Steve Cook en Annie Matthewman hebben een demonstratie gegeven van een zeer kleine Software Factory waarbij met een DSL een smart client gebouwd kon worden die een database benadert via een wizard. Je kunt zo iets bedenken als je geen restricties hebt... Het verhaal was erg duidelijk als je het boek van Steve al 's doorgelezen hebt en je al wist wat de GAT tool is. Deze tool maakt een Software Factory template en schema, zodat je daadwerkelijk code kunt genereren uit de DSL en uit de extra artefacten die je daarvoor nodig hebt (zoals wizard pagina templates). GAT staat voor "Guidance Automation Toolkit" en kan hiergevonden worden. Ik weet zelf ook nog niet de ins en outs van deze tool, maar vergeet vooral ook niet naar GAX te kijken, dat zijn de extensions.

Keynote niet zo inspirerend

Met "Inspiration shared" wordt de Teched samengevat. Je zou dus verwachten dat Lees vooral inspirerend zou zijn en de zaal zou gaan inspireren met het een of ander. Maar weinig van dat. Er was een aardige performance van de Information Worker, de IT Pro en de Developer met een modererende rol van wat je zou kunnen noemen de projectleider. Wel aardig, maar dat er nu echt inspiratie gedeeld werd ... nee. De aankondigingen waren ook mager, hoewel een setje Visual Studio en SQL Server natuurlijk altijd een aardig kadootje is (vooral als je dat al hebt via je MSDN subscription). En ja, de geweldige demo met RFID. Die ging in Orlando al mis met een robot die binnengereden werd, maar geen tracking op het scherm opleverde; is ie zoveel weken later ook nog steeds nep. Nee, dit kwam bij mij niet goed over.
In Orlando werden dezelfde demo's gehouden, dezelfde dingen verteld (het kadootje was anders) en dezelfde vergelijkingen gemaakt met IBM en Oracle. Ik vond dat Lees het beter deed dan Steve B., maar goed ieder z'n talenten.

De eerste dag: een halve bootcamp over SOA's

De eerste dag begon al goed met het te laat komen voor de eerste sessie van de pre-conference. Ik had besloten om de sessies van Navindra Sehmi te volgen "Architecture Bootcamp". Na de gemiste kans om een overview te krijgen van de architectuur van Connected Systems, was ik gelukkig wel op tijd om een verhandeling te volgen over het Business Capability Model en over de door Microsoft ontwikkelde Motion Methodology. Het werken met het concept van Capabilities vind ik zo gek nog niet, het raakt heel erg de wereld van diensten bieden en krijgen (SOA's dus) en het geeft een frisse andere kijk op dezelfde business die in veel gevallen al een eeuwenlange historie heeft..

Het Capabilities Model werd dus gepositioneerd als een aanzet tot het inrichten van SOA's en toen gebeurde het onwaarschijnlijke: de sessie werd na een kwartier (het was tenslotte een bootcamp) opgevolgd door een volgende sessie, waarin, na een verhandeling over WSDL's, overgegaan werd tot het beschrijven van een business met use cases en, en toen gebeurde het ongeluk, dit werd vereenzelfigd met services !!!!
Ik ontspoorde volledig!! Er werd een applicatie neergezet met 12 use cases die leidden tot 36 services en die services werden onderverdeeld in 5 typen (process, data, activity, infra en event). Weg Capabilities, weg autonomie, weg architectuur.
Het kan natuurlijk, een applicatie bouwen op basis van webservices en je druk maken over hoe die verschillende kleine servicesjes met elkaar babbelen. Maar voor mij is dat een ander spoor, misschien zelfs wel met een andere spoorbreedte, dan services zien op de granulariteit van Capabilities.

Mij vraag is nu welke granulariteit hoort nu bij de SOA of is het misschien wel allebei (en dan geloof ik niet meer in die architectuur). En wanneer praten we over Connected Systems, als we "connected" components hebben?
Ik denk dat ik Navindra maar 's ga uitnodigen voor een Red Hook.

Helaas moest ik door verplichtingen in Utrecht na de lunch ook weer verstek laten gaan, ik heb het echt technische deel nog mogen missen ook....

Interview met Steve Cook over DSL's

Omdat ik nogal wat vraagtekens heb bij het inrichten van DSL's en hoe dat ingrijpt op het proces van software ontwikkelen, wat ga je bijvoorbeeld een organisatie adviseren om eerst te doen. Eerst je DSL op orde stellen (hoe?) en dan pas Team System introduceren op basis van die DSL, of moet je het juist andersom aanpakken: eerst leren TeamSystemen met wat er nu is aan DSL's en vooral het proces onder de knie krijgen en dan gaan professionaliseren met je eigen DSL's? Het boek van Jack Greenfield dat ik nog steeds beschouw als de refentie, doet hierover wonderbaarlijk ook geen duidelijke uitspraak over. Redenen genoeg dus om Steve Cook die volgende week ook in Amsterdam is, hierover 's uitgebreid te bevragen. Zoals jullie wellicht weten is Steve Cook een van de architecten van de DSL's en zou dus hierover ook het een en ander moeten weten. Ik heb de stoute schoenen aangedaan, hem een mail gestuurd en gevraagd om een interview. A.s. dinsdag gaan we lunchen. Omdat ik ook al een partner meeneem, lijkt het niet handig nog meer mensen aan te haken, maar als je specifieke vragen hebt voor Steve en je wilt dat ik ze meeneem dan zie ik die graag tegemoet.

Forum discussie over Software Factories

Op vrijdagmiddag om 13.45 in het Auditorium wordt een forum discussie gevoerd met de Microsoft Architecten over het hoe en waarom van Software Factories. Je kunt de mannen ook vragen stellen via de web site. Erg leuk, ik heb me al laten verleiden twee te stellen:

Hoe maak je dat een DSL generiek genoeg is dat het door requirements engineers nog voldoende ruimte voor functionele creativiteit biedt en specifiek genoeg dat het gaat leiden tot verbeterde productiviteit dmv code generatie

Hoe bewaak je in een Software Factory het requirements management? In een Team System team voelt iedereen de voordelen van het collaboreren, maar de requirements engineers komen daarbij niet expliciet voor en juist zij moeten (leren) collaboreren met de ontwikkelteams.

Ik ben erg benieuwd naar de reacties.