Efterhånden er næsten alt, en forretning har brug for, tilgængeligt som services. Lige fra klassisk it-drift og infrastruktur over online reklame, CRM, salgsstyring og lønudbetaling til økonomi- og produktionssystemer. Fra simpel delt lagerplads á la Dropbox til hele forretningsområder i form af whitelabel-services, som kun venter på vores logo, og en underskrift, før vi er i luften.
Anything-as-a-service området er kaotisk, har typisk en højere udviklingshastighed end in-house systemer og kan virke ret umodent for den uindviede - og såmænd også for den erfarne. Begrebet skygge-it dækker over én af de udfordringer, der er ved området.
Her har nogle organisationer eksempelvis ad bagvejen taget Dropbox eller lignende i brug til udveksling af fx personfølsomme oplysninger om kunder, hvilket må give enhver sikkerhedsansvarlig nervøse trækninger (om ikke før, så i 2018 når EUs Persondataforordning træder i kraft).
Der er da også rigeligt for en arkitekt at være usikker på og utilfreds med: Organisationens data flyder mellem flere eksterne aktører uden at vi kan overskue service-levels eller, som nævnt, sikkerheden. Arkitekten mister indflydelse på arkitekturen bag de mange services og mister dermed også indsigt i deres naturlige styrker og begrænsninger.
Specialtilretningen, skræddersyet til virksomheden, er heller ikke længere mulige. Måske frem for alt, mister arkitekten den dybe indsigt han tidligere havde om opbygningen af systemerne nede i serverrummet.
Vi kan vel alle kan være enige om, at løfterne i anything-as-a-service hypen endnu er langt fra indfriet. Men samtidigt må vi også spørge os selv, hvad vi skal gøre anderledes, når nu udviklingen går den vej.
Jeg oplever, at flere organisationer kan få glimrende og billige løsninger anything-as-a-service, men også at arkitekter nogle gange er modstandere af udnyttelsen af eksterne services, baseret på et snart forældet verdensbillede af hvordan organisationens it bedst indrettes.
En af arkitektens klassiske kerneopgaver er design og kontrol af integrationer mellem arbejdsprocesser og mellem systemer. Opgaven får flere arkitekter til, noget lavpraktisk, at ville tvinge interaktionen mellem systemerne ind over ens egen ESB. Det er ikke nødvendigvis en gangbar løsning i en as-a-service situation.
I stedet skal arkitekten sidde med ved bordet som CIO’ens forlængede arm ude i forretningen, når beslutninger træffes om nye services – og sætte sig ved bordenden, når aftaler om integrationer og interfaces indgås mellem de forskellige parter.
Behovet for masterdata management er heller ikke længere det samme som at skulle eje en datakværn i et serverrum. Opgaven håndteres med klassisk begrebsmodellering men suppleret med ekstra vægt på dokumentation fra og aftaler med de eksterne service-udbydere.
Den gode nyhed er, at den direkte kontrol med mere trivielle sager som performance, driftsstabilitet, servere og netværk ikke længere er arkitektens bord. Men ansvaret er i hvert fald delvist fortsat hans, og han skal kende sine nye værktøjer: Velafbalancerede SLA’er og gode aftaler med leverandørerne.
Alt dette betyder et skifte i arkitektens opgaver væk fra teknik og systemer og hen imod mere forhandlinger og aftaler. Juristen er god at have som ven her, da han eller hun ikke bare er god til kontrakter, men også kan være trænet i forhandlinger.
Juristen har ofte øje for sjældne, men vigtige scenarier, som at vi skal kunne få udleveret data i tilfælde af aftalens ophør eller leverandørens konkurs. Juristen kan også hjælpe med at navigere i det ofte asymetriske styrkeforhold mellem ens egen organisation.og den meget store service-leverandør.
Nogle af de mere ambitiøse it-afdelinger planlægger da også efterhånden egentlige leverandørstyrings-teams med både jurister og arkitekter på holdet til erstatning for interne udviklingsafdelinger.
Arkitektens, og for den sags skyld it-chefens, potentiale for at blive værdsat som partner for forretningen vokser med modningen af markedet for anything-as-a-service.
Anything-as-a-service er gode nyheder for arkitekter – og nogle af de services er allerede nu gode nok til, at de for alvor kan løfte vores organisationer, så det er bare om at tage fat.
Det gode miks af services vil i stigende grad definere virksomhedens design og bestemme dets handlemuligheder. Arkitekten har god muligheder, som den måske bedst positionerede i virksomheden, for at blive central i formidling og etableringen af disse nye services.
anything-as-a-service, er super spændende. Og noget vi omfavner i stor stil. Godt emne :-)
Jeg kan dog ikke helt afkode hvad du mener med dette:
Vi kan vel alle kan være enige om, at løfterne i anything-as-a-service hypen endnu er langt fra indfriet.
Hvad er det for nogle løfter? Og hvem er det der skal indfri dem?
Undskyld mig.. men med de praktiske erfaringer jeg har med SOA,SOD, SIAM, xAAS og alle de andre dejlige forkortelser, der relaterer sig til Services, så mener jeg at bloggen er lidt ramt ved siden af, set i forhold til den virkelige verden.
Juristen er jo så absolut i de fleste tilfælde ikke IT-arkitektens ven. Og nej juristen har ikke
...ofte øje for sjældne, men vigtige scenarier, som at vi skal kunne få udleveret data i tilfælde af aftalens ophør eller leverandørens konkurs.
Det er i virkelighedens verden som regel arkitekten der har det fokus. Og i RIGTIG mange tilfælde så har arkitekten først mulighed for at komme med sådanne indvendinger efter at kontrakten er underskrevet. For det hører ikke til reglen at man laver et TQA af kontrakter i erhvervslivet. Juristen er som regel mere obs på, at der kan placeres et ansvar. Og har som regel ikke forståelsen for, hvad datatab har af konsekvens for virksomheden. Så budskabet burde mere IMHO være "Jurist din bedste ven er IT-arkitekten (helst en EA)".
Og Design, Governance, Gode kontrakter, Dokumentation og en Org. der understøtter EaaS er endnu vigtigere nå man begynder på en Everything as a Service strategi.
Det jeg har set i Virkeligheden er at det forstår din Enterprise Arkitekter, typisk også dine Forretnings arkitekter, dine Senior tekniske arkitekter m.m. Men det er der mange andre dele af org.'en der så absolut ikke gør.. eller vil gøre.
// Jesper
Hvad er det for nogle løfter? Og hvem er det der skal indfri dem?
Allan, dem er der jo mange af - som markedet forventes at levere. De kan vel sammenfattes til hurtig implementering af sammenhængende forretningsprocesser, leveret billigt (eller gratis) og med løbende udvikling af world-class funktionalitet uden ulemper. Eller noget i den retning. Virkeligheden er nok at vi er i den spæde begyndelse på en lang rejse mod opfyldelse af løfterne.
Enig i at der i praksis indgås mange aftaler hvor juristen måske ikke har helt det rigtige blik for hvad, der er vigtigt for virksomheden. Så, jo, arkitekten er (eller bør være) god at have med for juristen.
Min pointe er også, at arkitekten fremover ikke kan udføre sit arbejde uden hjælp fra juristen, og derfor bør betragte juristen som en ven, der er vigtig at få!
Allan, dem er der jo mange af - som markedet forventes at levere. De kan vel sammenfattes til hurtig implementering af sammenhængende forretningsprocesser, leveret billigt (eller gratis) og med løbende udvikling af world-class funktionalitet uden ulemper. Eller noget i den retning. Virkeligheden er nok at vi er i den spæde begyndelse på en lang rejse mod opfyldelse af løfterne.
Jeg er stadig ikke helt sikker, på hvad du mener. Det lyder som om at du mener at det er anything-as-a-service leverandørene, der ikke kan levere det der skal til. Er det dem der har givet løfterne og dem der skal indfri dem?
Min oplevelse er at anything-as-a-service leverandørene leverer præcis hvad der står på æsken og ofte overleverer ifht vores forventninger. Dem der mangler at indfri noget er, i min optik, virksomhederne der kunne bruge anything-as-a-service, men ikke formår det.
Jeg er stadig ikke helt sikker, på hvad du mener. Det lyder som om at du mener at det er anything-as-a-service leverandørene, der ikke kan levere det der skal til. Er det dem der har givet løfterne og dem der skal indfri dem?
Det du spørger efter, er hvor hypen for "anything-as-a-service" stammer fra. Det er vel ret sigende at der nu kommer en "serverless" hype bølge, som bruger samme argumenter som "cloud" bølgen gjorde og udtaler sig i absolutten om hvordan verden bliver.
Der kan være rigtig mange velovervejede årsager til at verden ikke vil have "anything-as-a-service". Dropbox der ikke sletter filer, giver liv til nogle af de argumenter. Teknologien kan sagtens være smart og overlegen, men det gør den ikke nødvendigvis til det rette valg.
Min pointe er også, at arkitekten fremover ikke kan udføre sit arbejde uden hjælp fra juristen, og derfor bør betragte juristen som en ven, der er vigtig at få!
Jeg mener stadig, at det er omvendt. IT er i stigende grad en mere og mere central del af virksomhederne. Så enten må virksomhedens juridiske afdeling gøre brug af en IT-arkitekt eller så må man hyre (ansætte/eller hyre externt) IT-jurister. Det er ikke Juraen der breder sig til IT-området, det har altid være der, når man har med eksterne parter at gøre.
En IT-arkitekt bør ikke have problemer med at forstå IT-delen af en kontrakt der omhandler IT. Og slet slet ikke være i tvivl om den service man køber passer ind i designet. Det er jo en arkitektens job.
Det jeg derimod har set er katastrofale kontrakt ændringer, og 'Direktør løsninger', hvor de IT-faglige øjne har manglet. Jeg husker en kontrakt opdatering et sted hvor jeg arbejde engang, hvor kunden ønskede at afregne kapacitet i en anden enhed. Ingen Problem.. ud over at man (Juridisk afdeling) ikke konsulterede nogen der forstod at den nye afregnings enhed svarede til at går fra at afregne i Liter til Gallons, og at enhedsprisen derfor skulle justeres. Det betød et tab på 1 MUSD per år.
// Jesper
Det du spørger efter, er hvor hypen for "anything-as-a-service" stammer fra. Det er vel ret sigende at der nu kommer en "serverless" hype bølge, som bruger samme argumenter som "cloud" bølgen gjorde og udtaler sig i absolutten om hvordan verden bliver.
Ja hvis løftet er, at hele verden kan blive på en måde og den er bedre for alle, så giver jeg dig fuldstændig ret i, at det ikke kommer til at ske.
Jeg ser en masse muligheder som ikke rigtig bliver udnyttet. Som helt sikkert er blevet oversolgt ind i mellem.
Jeg tror ikke vi er så uenige, Jesper. Dog mener jeg klart at det er arkitektens (it-arkitektens eller enterprise arkitekten) som har interesse i, og egentligt også en pligt til, at tage initiativet til at møde juristen.
Anything as a service er super hypet, og en fantastisk indgangsvinkel til konsulent virksomheder for at få solgt en masse gode konsulent timer til kunder, som bare skal med på toget inden det er for sent.
For sådan er det jo med alle disse "nye" teknologier, som overhovedet ikke er nye, men er rebranding af gl. kendt metodikker. De genopfindes og relanceres som den endelige løsning på ethvert problem... lige ind til den næste nye fantastiske endelige løsning dukker op.
Jeg er helt med på at SOA (service oriented architecture) generelt er en god ting. Jeg er dog meget bevidst om at det bør holdes i kort snor, så man har helt styr på hvad er hvor og hvorfor og med hvilke rettigheder tingene skal tilgås og bruges.
Som det benyttes rigtig mange steder, er anything as a service simpelthen en ny variation af de gode gamle BASIC programmer, hvor en myriade af ting og sager klistres sammen af GOTO og GOSUB. Der er vel ingen som rigtig ønsker sig tilbage til den tid igen?
Jeg synes ofte at se at når man bare klasker "Open Source" og "Service oriented" tags på en funktion eller et program, så følger det standarden og er by default fuldt acceptabelt at blive klistret sammen med noget andet "Open Source" og "Service oriented" blackbox kode i et stort kludetæppe, hvor performance, sikkerhed, resource forbrug, maintainability, readability, debugability etc. og den dejlige læresætning "KISS" (keep it simple stupid) er gået 100% fløjten.
Men selvfølgelig... så er der flere konsulent timer at hente bagefter.
mvh Kim Bo (konsulent)
@Kim Ud over at du har en rigtig god pointe, så er SOA jo som arkitektur princip, et virkefelt der er større end bare 'code'. Og her har Peter (bloggeren) jo en glimrende pointe, nemlig at en IT-arkitekt nemt kan miste overblikket når nu, han/hun sidder med en løsning som er bygget op på 5-10 forskellige lag af services, der alle er connectede på tværs af organisationen, partnere, kunder og leverandører.
// Jesper
Ud over at du har en rigtig god pointe, så er SOA jo som arkitektur princip, et virkefelt der er større end bare 'code'. Og her har Peter (bloggeren) jo en glimrende pointe
Jamen jeg er helt enig i den pointe. Jeg ønskede bare at gøre det helt klart hvordan SOA efter min opfattelse ofte bliver misbrugt, og anything as a service er i særdeleshed med til at eskalere det misbrug.
mvh Kim Madsen
