Arkitektur mot Product Portfolio Mismanagement

variabilitet för att få storföretag mer agila.

Några veckor efter mitt förra blogginlägg (om Software product lines) kom Nyårsledigheten då man träffar en del släkt som man inte sett live på länge, vilket är extra kul med dem som råkar bo på andra sidan Klotet. Kalifornienkusinen och jag pratar fyra språk var, varav två gemensamma, men vi drev ändå mest iväg i nördiga IT-förkortningar (han är Senior Architect i Kiseldalen, på ett av världens fem största IT-företag). I år hamnade två saker i förgrunden.

Först, hur lite ”ny” ekonomi hittills lärt av produktarkitekturer och kravspecar i ”gamla” komplexa ingenjörsprodukter. Agreed - inte mycket att orda om. Sedan, agilt - mer att prata om.

- Hos oss har vi Agile project management, Agile devs som utvecklar agilt, osv osv. Men... Innan ett agilt projekt får sitt definitiva ”go” uppifrån, så sker en rad långtifrån agila beslut, som ska successivt godkänna den blivande produkten. Produktidén ska passera checkpoint 1, 2, 3, ...X, där olika roller på olika nivåer ska ge var sitt OK. Efter några checkpoints får den ”first go” och man gör en förstudie. Efter ytterligare ett antal checkpoints får produkten ”final go”.

- Hmm. Men vad baseras besluten vid de tidigaste avstämningspunkterna på?

- En löst och ostandardiserat beskriven idé. Det är ett Moment 22: de som fattar beslut före förstudien har knappt ett hum om vad det är de beslutar om.

- Blir det märkbart bättre i de avstämningspunkter som ligger efter förstudien?

- Måttligt. De tar fortsatt mycket tid av dyra och mycket upptagna roller.

- Du är inte den första som talar om problemet för mig. Ursäkta mina konsultyrkesskador, men detta är ett av flera knepiga problem som blir enklare med produktfamiljstänket, Software Product Line.

Jag klottrar en bild ur en Informatorkurs (på en vit servett, i bästa gamla dotcom-stil):

- Så hur förenklar det mitt problem?

- Framförallt kan du skapa en enklare agil gräddfil i godkännandeprocessen för allt som ligger ”within scope”. Dessutom är sådana produktförslag billiga att förverkliga m h a redan  förprogrammerade mekanismer, och kostnaderna mer förutsägbara, och idéerna lättare att förstå internt. Och, och...  Snarlika fördelar som vid offertberedning för externa kunder. Ju mindre ”promiseware” i produkten, desto lägre osäkerhet. Informator i Sverige kör för övrigt en kurs om Modular Product Line Architecture, T1430.

- Synd då att det är nio tidszoner mellan Mälardalen och The Valley...

//

Milan Kratochvil

konsult, Kiseldalen.com

Huvudförfattare: Growing Modular: Mass Customization of Complex Products, Services and Software samt UML Xtra Light: How to Specify Your SW Requirements

UML 2 Professional, OCUP Advanced Level (certifikatnivå 3 av 3)

Milan samarbetar med Informator sedan våren 1996 inom modellering, UML, krav, analys, arkitektur och design. Håller f.n. kurser i Arkitektur, i modellering (T2715, T2716), och 2013 höll han också Informators fullsatta Frukostseminarium om användningsfall.