Inledning

Många organisationer som försöker omorganisera sin arkitektur förlitar sig starkt på IT-avdelningar och stödjande arkitekturteam för att driva och hantera arkitekturinitiativen. Till exempel i SOA-världen leder arkitekturdiskussionerna ofta till diskussioner om tekniska och organisatoriska utmaningar snarare än om affärsvärden. IT-personal tenderar att fokusera mer på produkter än på processer. De tittar ofta på ”kompletta” tekniklösningar, inklusive hårdvara, programvara och tjänster som ska tillhandahållas av deras befintliga leverantörer. Det är naturligtvis lättare att vända sig till samma kända leverantör som man redan har en relation med och få hela SOA-stacken från dem, än att se sig om efter olika lösningar och gå igenom detaljerade krav, analyser och design med någon annan.

Dessutom tillåter de organisationer som arbetar med sina befintliga leverantörer att leverantörerna utformar och definierar deras lösning, oavsett vilka behov eller krav de har. Arkitekterna sluter ett avtal med en leverantör i hopp om att de ska få någon teknik som gör att deras (ibland dåligt definierade) arkitektur mirakulöst fungerar. Härifrån är det ganska nära att falla i fällan att låta leverantörerna driva arkitekturen.

I de följande styckena beskriver vi för- och nackdelar med den leverantörsstyrda arkitekturen.

2. Leverantörsdriven arkitektur – varför inte

2.1 Det goda

Låt oss säga att du känner din leverantör. Du är på väg att ändra din arkitektur, så du tittar naturligtvis på den befintliga leverantören. Du har en bra relation med dem och känner dig bekväm med att ha att göra med samma personer och plattform. Du behöver inte anstränga dig för att lära känna några nya aktörer. Sedan låter du dem styra din arkitektur, bara för att det är enklare på det sättet. Därefter köper du deras produktstack och får eventuellt rabatter på flera produktpaket och gratis support. Om de kommer med någon innovativ lösning kan du till och med bli en pionjär, en tidig användare av den nya tekniken, vilket kan ge dig konkurrensfördelar. Naturligtvis blir du låst till leverantörens lösning, åtminstone tills standarder skapas för den nya tekniken.

2.2 Det dåliga

Att förlita sig för mycket på leverantörer kan vara en katastrof. Leverantörens mål är att sälja så mycket som möjligt till dig. Ditt mål bör dock vara att implementera arkitekturen på ett framgångsrikt sätt och ge ditt företag maximala fördelar till minimala kostnader.

Leverantörerna kommer att försöka sälja sina tekniska lösningar till dig, oavsett vilka dina krav är. Även om leverantörerna kan vara kunniga när det gäller en arkitektur i allmänhet, begränsas deras kunskap alltid av deras eget perspektiv. De kommer att ge dig råd, men det kommer alltid att vara ur deras synvinkel. Du bör specificera dina egna behov och försöka validera ditt arbete med hjälp av oberoende experthjälp. Det är därför det är så viktigt att först förstå sina egna problem och specificera tydliga och detaljerade krav, och först därefter börja leta efter alla möjliga tekniska lösningar.

En annan aspekt av att förlita sig på att leverantörerna ska styra arkitekturen är att de flesta företagsarkitekter arbetar utifrån sin erfarenhet, som inte alltid är så bred som den borde vara. Ju mindre mogen arkitekten är, desto mer benägen är han/hon att följa leverantörens råd. Det finns alltid en risk att han/hon inte fokuserar tillräckligt på kärnverksamhetens problem och inte lyckas anpassa tekniken till verksamheten i tillräcklig utsträckning. Bara det kan leda till stora förluster av produktivitet och pengar i det långa loppet.

Fastna inte i leverantörens produktstack. Du kan missa möjligheter till effektiviseringar som kan komma från andra tekniker. Förvänta dig inte att leverantören som bygger din arkitektur ska råda dig att välja någon annan teknik – det ligger helt enkelt inte i deras intresse att göra det. Vad de bryr sig om är att sälja sin egen teknik, och det är inget fel med det. Det är upp till dig att vara smart, hålla dig till dina krav och göra din research.

När du implementerar en arkitektur som SOA får du inte glömma bort dess principer: att leverera dina applikationer med smidighet, flexibilitet och återanvändbarhet. Men när du låter leverantörerna styra din arkitektur kan dessa principer gå förlorade. Det kan sluta med att du blir instängd i leverantörens lock-ins, blir mottaglig för dyra tjänster, bunden till proprietära tekniker och produktbegränsningar. Din SOA kanske bara blir JBOWS (Just a Bunch of Web Services) -arkitekturen.

Leverantörsdriven arkitektur, som kännetecknas av leverantörslåsning, är särskilt viktig att vara medveten om vid utformningen av molntjänster och integration. Det som leverantörerna av molntjänster lovar är att man ska slippa de initiala kostnaderna för licenser och hårdvara och bara betala för uppmätt förbrukning. Problem uppstår när du inte har en tydlig exitstrategi och leverantören höjer sina priser, tar bort support för något som tidigare supportats eller ändrar några andra villkor. På grund av bristen på standardiserade gränssnitt, öppna format för datautbyte och andra molnrelaterade standarder är det också mycket svårt att integrera tjänster från olika molnleverantörer samt molnresurser med interna system. De enskilda molnleverantörerna erbjuder icke-kompatibla underliggande tekniker och proprietära standarder, vilket gör att kunderna blir inlåsta hos den nuvarande leverantören på grund av höga kostnader för att flytta applikationer och data till en annan leverantör samt juridiska och tekniska begränsningar.

3. Slutsatser

Leverantörerna ska inte styra arkitekturen. En mogen strategi för att driva arkitekturen bör styra bort från de leverantörsstyrda, svårförändrade behoven i affärsarkitekturen och från den därmed sammanhängande leverantörsinlåsningen. Det som leverantörer kan göra är att förse dig med vissa verktyg eller lösningar som behövs för att implementera din arkitektur. Tänk dock på att det kan vara ett stort misstag att bara välja en ”rätt” tekniklösning och binda sig till bara en leverantör, vilket kan leda till onödiga kostnader på kort och lång sikt. Din arkitektur, SOA eller annan, är (som man säger) något du gör, inte något du köper, så ”one stop shopping” kanske inte fungerar här, eftersom det alltid finns olika affärskrav, olika processer, olika tjänster som kräver olika tekniska lösningar.

Arkitektur handlar om att på ett holistiskt sätt beskriva systemet med människor, processer och teknik utifrån din organisations specifika behov, och det är något som leverantörer – som främst agerar i eget intresse – kanske inte kan tillhandahålla på ett objektivt sätt.