Kvaliteter i Enterprise software

I större IT-intensiva organisationer stöter man ständigt på dilemmat om man ska “bygga själv” eller “köpa in”.

Utvecklarna vill gärna bygga själv (att bygga ting är ju faktiskt vår profession) och kan vara mer än lovligt anstrukna av “not invented here”-bias. Andra delar av organisationen menar att det ur olika aspekter är långt mer fördelaktigt att köpa in.

De senare åren har det utkristalliserat sig en modell, s.k. Software-as-a-Service (SaaS), där organisationen inhandlar ett system som körs som en tjänst hos en extern leverantör, i “molnet”, utan behov för driftning lokalt on-prem (“on premises”).  SaaS är en fin modell i många sammanhang, men för systemer:

  • inom satsningsområden som ska differentiera organisationen från konkurrenter och därmed kräver mycket utveckling och tillpassning
  • som omfattas av regulatoriska krav vad gäller t.ex. utländsk lagring av data
  • inom väldigt specifika domäner där standardlösningar saknas

kan den vara mindre tillämpbar. Man står då gärna igen med valet mellan att antingen köpa eller bygga något som kan driftas on-prem.

När ting ska köpas in eller byggas själv avhålls i regel en mer eller mindre formaliserad process där behov identifieras, mandater skrives, Gartner-rapporter studeras, referensgrupper möts och liknande. Har man otur så slutar i processen i att det gås till anskaffelse av en typ av köpe-system som kan kallas för Enterprise software.

Den här blogposten handlar om en rad kvaliteter som Enterprise software tenderar att inneha.  

Enterprise software…

Fyller alla behov

…som intressenterna definierade i anskaffelseprocessen.

I praktiken

Är många av behoven som definierades i anskaffelseprocessen inte längre aktuella när systemet  omsider (efter en smärtsam, utdragen, dyr och leverantörskonsult-understödd process) äntligen kommit i produktion. Detta eftersom landskapet helt enkelt hunnit ändra sig i mellantiden.

Då fokuset vid anskaffelsen låg på uppfyllelse av de mer eller mindre viktiga krav som upplevdes som aktuella vid anskaffelstidspunkten (s.k. Bullet-point engineering) snarare än  systemets anpassningsbarhet till nya möjligheter kan det visa sig vara svårt eller omöjligt att uppfylla dagens behov.

Har grafiska pek-och-klick konfigurationsanvändargränssnitt

…för att systemet ska vara enkelt att konfigurera för en stor grupp av superbrukare gärna från business-sidan.

I praktiken

är användargränssnittet, om än grafiskt, så komplicerat att förstå att det krävs specialistkompetens, gärna i form av leverantörskonsulter, för att ändra på någon som helst konfiguration. För andra är leverantören behjälplig med prisvärda kursmöjligheter i in- och utland, certifieringar, leverantörsspecifika (mersäljdrivande) konferenser och liknande.  

Det grafiska konfigurationsanvändargränssnittet har i en del fall undanträngt mer generiska former av konfigurationsmöjligheter som textfiler, och det blir därigenom i princip omöjligt att industrialisera och versionskontrollera rutinerna kring installation i olika miljöer.

Som alternativ utvecklas det i organisationen gärna långrandiga dokument, som med screenshots och pek-och-klick punktlistor, desperat prövar att dokumentera de manuella installationsrutinerna och minska den helt upplagda risken för fel och olikheter mellan miljöer (jämför snowflake server). Både de själva manuella rutinerna, och de fel och påföljande felsökning de utlöser, är ren och skär waste som sinkar och suger livslusten ur organisationen under hela systemets livscykel.

Tar lång tid att starta upp, vilket inte spelar någon som helst roll

…eftersom instansen ska “alltid” köra i produktion och “aldrig” behöva startas upp från scratch. Man kan göra genomgripande ändringar i funktionaliteten genom installation/uppdatering av plug-ins, andra självständigt deployerbara artefakter etc. utan att systemet behöver startas om.

I praktiken

är inte plugin-systemet tillräckligt pålitligt så i produktion måste man re-installera och starta om hela systemet i förbindelse med alla typ ändringar. Automatiserad testning och byggtider lider och stora mängder värdefull arbetstid förspills på väntning att systemet helt enkelt ska behaga att starta upp.

Är en plattform

…som det är möjlig att implementera och innovera ovanpå. Systemet är “utvecklarvänligt” och leverantören bistår med grafisk utvecklingsmiljö. Gärna i form av en plugin till Eclipse.

I praktiken

Brinner plattformen och det är omöjligt att gå i livbåtarna.

Utvecklarna är strandade på plattformen hänvisade till en utdaterad utvecklingsmiljö av låg kvalitet – olika typer hårda kopplingar mellan system och utvecklingsmiljö gör det svårt eller omöjligt att ta i bruk de moderna och mer lättviktiga verktyg. Systemet är nogsamt implementerat som en plattform/framework med Hollywood-principens “Don’t call us, we’ll call you” mantra som garantist för stenhård vendor-lock-in mellan allt som implementeras ovanpå systemet och systemet själv.

Den sista delen av alla systems livscykel, “End of life”, blir så avskräckande att relationen med leverantören gärna varar fram till pensionsålder för samtliga inblandade.

Vi opererar i en miljö starkt präglad av en ständigt accelererande teknikutveckling. Vart den kommer föra oss är omöjligt att förutse, att arkitekturkvaliteter som kort time-to-market och adaptability bara kommer växa i betydelse är däremot rätt självklart. Då kan man behöva se upp för en del säljare!

JavaZone Lightning Talks: Enterprise programvare! Vart du skræmt no? Vidar Moe