Tagarchief: Architectuur

Project Risicobeheer uit de Praktijk #1

Gezamenlijk een e-book project risicobeheer schrijven, maakt dat we allerhande ervaringen  uitwisselen. Daarom, onder het motto “al doende leert men” en “er is geen falen, alleen maar feedback”, hier een gevalletje waterschade.

De situatie
Een projectteam is druk in de weer om een vastgelopen softwareproject weer op de rit te krijgen. Er is inmiddels een nieuwe gedragen visie, een helder plan van aanpak en een kansrijke software architectuur. Er is succesvol een aantal proof of concepts ontwikkeld. Het projectteam pakt de zaken wel iets anders aan dan men is gewend binnen de lijnorganisatie. Zo wordt op een iteratieve multidisciplinaire manier gewerkt. Ook zijn vele taken, die normaal handmatig worden uitgevoerd geautomatiseerd, waaronder automatisch bouwen, deployen en testen. Binnen een paar weken gloort er onder de projectteamleden na maanden van stilstand zowaar iets van hoop. En natuurlijk is er ook een risico log opgesteld. So far so good!

Opmaat voor problemen
Anders werken dan ‘normaal’ kan weerstand oproepen bij mensen die niet direct onderdeel zijn van het projectteam. Zeker als het projectteam zaken voor elkaar krijgt die al jaren niet voor mogelijk worden gehouden. Denk aan een eigen projectruimte, nieuwe ontwikkeltools, nieuwe ontwikkelmachines en controle op test- en acceptatieomgevingen. Daar bovenop werkt het projectteam met een ontwikkelaanpak die verdacht veel lijkt op standaard die door een groot deel van de organisatie als niet werkbaar wordt beschouwd. Tot slot doet het projectmanagement team goed werk, want het projectteam ondervindt vooralsnog geen last van deze weerstand. Met de resultaten in de hand weet het projectmanagement team dat ze het gelijk aan haar kant heeft, maar er is een verschil tussen gelijk hebben een gelijk krijgen.

Het probleem
Het projectteam heeft de software architectuur gestabiliseerd.  Meer dan 50% van de functionaliteit is inmiddels gereed en het projectteam is fluitend op weg naar de eindstreep. En dan wordt de projectmanager op het matje geroepen bij de directie. Het hele pand weet wat er aan de hand is, behalve de projectmanager en het projectteam. Wat is er aan de hand. De architectuurafdeling heeft geconstateerd dat het projectteam totaal verkeerd bezig is. Er wordt niet onder architectuur gewerkt en het systeem mag op deze manier nooit operationeel worden gemaakt. Alle software waarbij sprake is van communicatie met andere systemen, moet helemaal opnieuw worden geschreven. Het projectmanagement team heeft geen idee waarop deze constatering is gebaseerd en heeft alle vertrouwen in een goede afloop. Omdat het probleem op straat ligt, lukt het het projectmanagement team echter niet om de rust te bewaren binnen het projectteam. Sommige projectteamleden vallen  terug in oude gedragingen en anderen geven de hoop op. Gaat het toch weer mislukken?

Het verweer
Het lukt om alle constateringen inhoudelijk van tafel te vegen. De architectuurafdeling heeft namelijk iets over het hoofd gezien. Het projectteam ontwikkeld namelijk geen web-client maar een desktop-client en daartoe zijn andere communicatieprotocollen nodig. Verder is de gekozen oplossing extern getoetst door de leverancier van de middleware. Er valt geen spelt tussen te krijgen en het projectteam krijgt groen licht om door te gaan.

Gevolgschade
Je zou kunnen denken: “Eind goed, al goed”, maar niets is minder waar. Het duurt drie weken voordat het projectteam weer op volle snelheid ligt en de relatie met de directie en de architectuurafdeling is geschaad.

Leerpunten
Terugkijkend was de relatie met de architectuurafdeling vanaf de start van het project niet goed. Ze hadden geen tijd en ze vonden de oorspronkelijke software architectuur prima. Het projectteam had ze inhoudelijk gezien ook niet nodig. Maar een project dat zich gedraagt als een speedboot tussen de olietankers, trekt natuurlijk wel de aandacht. Vanuit het oogpunt van project risicobeheer kun je zeggen dat de slechte relatie met de architectuurafdeling is genegeerd. Had het anders gekund?

Achteraf is alles makkelijk maar we hadden ook:

  1. De slechte relatie met de architectuurafdeling kunnen erkennen als projectrisico
  2. Als vermijdende maatregel de software architect consequent de architectuurafdeling formeel en informeel te laten betrekken of informeren over de besluitvorming en de voortgang
  3. Als beperkende maatregel de senior supplier (stuurgroep) een exceptie te laten voorbereiden, om indien nodig, met de eerste versie van het systeem te mogen afwijken van de referentie software architectuur

Met een kleine investering waren we in gesprek gebleven, onze energie nuttiger  kunnen gebruiken, een hoop euro’s bespaard en had niemand gezichtsverlies hoeven lijden.

P.S.
Mocht je meer willen weten over het project risicobeheer e-book, klik ->>hier

There is No Architecture, Only Business

Ik had de eer de afsluitende keynote te mogen doen op het Agile Software Architecture Symposium op 11 september 2013.  In tegenstelling tot mijn naamgenoot uit Amsterdam die huizen en gebouwen ontwerpt, ben ik geen architect en durf ik mezelf ook geen software architect te noemen. De vraag was dus wat kun je 100+ (software) architecten vertellen over hun vak. Na wikken en wegen werd het een zoektocht op basis van mijn eigen ervaringen met (software)architecten. De uitdagende titel van de presentatie is:
There is No Architecture Only Business.

Tijdens de presentatie ga ik in op de volgende onderwerpen en/of stellingen:

  • Het imago en veel voorkomend onwenselijk gedrag van software en enterprise architecten
  • Wat architectuur eigenlijk is en welk doel het dient
  • De onzinnige tegenstelling tussen Emerging Architecture vs. Big Design Upfront
  • Potentiële negatieve gevolgen van ontwikkelen op basis van Agile/Scrum voor Total Cost of Ownership (TCO)en Cost of Quality (COQ)
  • Waarom (software) architectuur in isolatie geen bestaansrecht heeft
  • Waarom over feedback als verbeter- of optimalisatiemiddel alleen niet afdoende is
  • Dat architectuurinitiatieven altijd een business doel dienen

Wanneer je nieuwsgierig bent naar de slides, volg dan de link
==> There is No Architecture Only Business.