Komponentarkitektur, med kanter av stål eller gummi.

Mitt förra blogginlägg kring arkitekturens ”450 miljarder kronors fråga” visade ett lönsamt exempel där Ulrich Hackenbergs produktarkitektur blev ett vasst strategiskt konkurrensverktyg för företagsledningar i bilindustrin. Hans idé om en flexibel ”megaplattform” plus flexibla komponenter är ganska universell, oavsett ”gammal” industri, mjukvaruindustri, eller tjänstesektor, och oavsett 100, 1000, eller 100 000 anställda.

Plattformstänkandet medför att vissa av arkitekturens kvalitetsattribut (framförallt förändringstålighet/modifierbarhet) hakar in i förprogrammerade, testade variabilitetsmekanismer. Därför byter vi nu glasögon och antar ett läge där ni, i likhet med Hackenberg, är färdiga med förankringen internt och har grönt ljus.    

Innehåller produkten och plattformen en hög andel mjukvara så jämför man gärna styrkor och svagheter hos olika arkitekturmönster (t ex Broker vs Peer2Peer, MVC vs MVP, decentraliserad SOA vs Task Service, osv).

Utöver produktplattformar och typer av modularitet har tillverkande industri även delat in komponenter i kategorier, ibland utifrån kravställarens eller offertberedarens perspektiv, ibland utvecklarens. Gradskalan av flexibilitet här (baserad på min bok Growing Modular plus UML-klassdiagram från Informatorkursen T2715 Agil Modellering med UML) är vinklad åt krav- och offert-hållet, men samtidigt relevant även för tekniksidan:

1. Standardkomponenter (en design, “one size fits all”, komponentkanter ”av stål” bildligt talat). I mjukvara oftast en ”black box” komponent där endast gränssnittet visas utåt. Många tidiga komponentsamarbeten (även inom mjukvara) var ganska låsta vid detta, vilket höll nere antalet möjliga komponentkombinationer och produktvarianter, och därmed även återanvändbarheten (se nyckeltalen i min förra gästblogg).

2. Modifierbara standardkomponenter (komponenten själv går att enkelt konfigurera om, för att passa nya krav från kund). Vanligt inom hård- och mjukvara. Både komponentens och konfigureringsmekanismens gränssnitt visas utåt, resten är en svart låda.

3. Parametriserade komponenter där både komponentens och parametermekanismens gränssnitt visas utåt. En vidareutveckling/standardisering av de modifierbara. Passar där man behöver många men ganska närbesläktade komponentvarianter.

Storlek m fl designparametrar går att variera (”tänjbara kanter”):

a) per order före driftsättning, eller

b) löpande från fall till fall, i drift, som t ex när e-boxen får bilmotorn att löpande anpassa sig till en ständigt varierande blandning av olika bränslen, eller ”Typ” i typparametrisering (även kallad Generics) i OO design och UML, som ger önskade varianter av en klass vartefter de behövs.

4. Komponenter som utformas per kategori av krav eller kunder (kanter av ”gummi”, bildligt talat). T ex Scanias hållfasthetsklasser med olika egenskaper för att passa in i olika produktkonfigurationer (där en del kunder kör tung stålplåt, medan andra kör lätta postpaket) eller abstrakta ramverksklasser i mjukvara som ärvs ner till (olika) applikationsspecifika subklasser. Passar där man behöver ett begränsat och förutsägbart antal komponentvarianter som är så olika att enbart parametrisering inte åstadkommer alla skillnaderna.

Även om ”O:et” i SOLID (Open/Closed principen) klargör poängen med skillnaden mellan att ändra insidan och att utöka (bygga på) en komponent, så får man ut mer flexibilitet när ”att utöka” blir en gradskala där varje trappsteg har tydliga spelregler för utökningar.

Jag är den första att medge att denna gästblogg betonar likheter i olika branschers komponentarkitektur och tonar ner olikheter, men tänkvärt för Informators läsare är att olikheterna är något oftare till vår fördel (dvs mjukvarans) än till nackdel. Gränssnitt i sig medför ju en extra kostnad (utöver eventuell prestandaförlust) för utveckling och test (i alla branscher), tillverkning (försumbart inom mjukvara), och störningar efter driftsättning (oftast försumbart inom mjukvara) orsakade t ex av:

rost, väder och vind m fl kemiska påfrestningar på fästen och kontaktdon

temperaturpåfrestningar

vibrationer m fl mekaniska påfrestningar

materialutmattning mm.

Däremot är fördelarna med gränssnitt och välavgränsade komponenter inom mjukvara snarlika andra branscher: smidigare offertberedning, kostnads- och prisberäkningar, projektorganisation, utveckling, test, felsökning/support, service, uppgraderingar, inskolning, mm. Även om t ex besparingar i reservdelslogistik oftast är försumbara inom mjukvara, så landar slutsumman av alla för- och nackdelar på ett klart plus.

Milan Kratochvil

konsult, Kiseldalen.com

Huvudförfattare: Growing Modular: Mass Customization ofComplex 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 i februari 2013 höll han också Informators fullsatta Frukostseminarium om användningsfall.