Arkitekturprincipper, som fortæller forretningen hvilken teknologi de skal eller ikke må bruge, er under angreb i flere organisationer.
For arkitekturprincipper kan skade mere end de gavner.
Arkitekturprincipper bruges ofte til at beskytte en tidligere investering i it. En sådan beskyttelse kan være nødvendig i forskellige tilfælde, men det er sjældent de giver værdi for forretningen. Et eksempel er princippet om at bruge en bestemt database-teknologi, fx Oracle i stedet for MS SQL eller omvendt. Det princip eksisterer for it-afdelingens skyld og for at beskytte afdelingens budget og database-folk.
Forretningen tages som gidsler for principper, de ikke forstår. Tag eksemplet igen med princippet om at bruge databaseplatform X. Det lyder jo … uigennemskueligt for forretningen, men måske umiddelbart fornuftigt, så forretningen accepterer at det princip gælder for fremtidige it-investeringer. De kan ikke gennemskue at ½ år ude i fremtiden diskvalificeres det pragtfulde CRM-system, som præcist rammer deres behov, af it-afdelingen med henvisning til princippet som forretningen jo selv har vedtaget. Forretningen er blevet gidsel. Den slags principper giver ikke nytte og undergraver troværdigheden af it-afdelingen i løbet af kort tid.
It-afdelingen misforstår rollen, hvis vi tror vi skal være gatekeepers og det udførende centrum for al it i organisationen i stedet for at facilitere sourcing af it, evt. ud af huset.
Arkitekturprincipper skal bruges med varsomhed. Der er nyttige varianter af arkitekturprincipper derude, det gælder om at finde dem i stedet.
Hvis du vil høre hvordan Danske Spil har valgt at håndtere behovet for it-principper, så kom med på Dansk ITs konference Enterprise Achitecture 2012 i morgen i København.
"Oprør mod DÅRLIGE it-arkitektur principper på vej", ikke?
Hvis man som it-arkitekt laver principper som artiklen beskriver som skræmmeeksemplet, så vil jeg godt have genindført gabestokken.
Lige så vel som man i hine tider puttede kvaksalvere der solgte "medicin" i en sådan, vil jeg som arkitekt gerne af med de folk, der smykker sig med en titel, de ikke er værdige til...
For ganske nyligt havde vi på datalogistudiet i Aalborg gæsteforelæser fra Nykredit. Han fortalte, at de havde mange friheder mht. løsninger, mens jeg tilføjede: "...så længe det er skrevet i Java."
Det er efter min mening en stor begrænsning, at man er tvunget til at udvikle systemer i ét bestemt sprog :-)
Du vil måske blive overrasket over hvor mange steder hvor man har et " princip" .
Når det er sagt, kan der være gode grunde til den type principper, netop for at beskytte investeringer, connectivity og it-kompetencer i afdelingen. Eller hvis der reelt er valgfrihed mellem konkurrende teknologier. Eller hvis man ønsker at tvinge eksempelvis en service-bus igennem, kan der være et princip om at servicebussen skal anvendes.
Men de er sjældent specielt befordrende for forretningsudvikling eller forretningsagilitet. Pricipperne af den slags skal kun bruges hvis de faktisk understøtter forretningsstratgien og ikke blot hjælper it-afdelingen i den daglige dont.
Netop store it-tunge virksomheder er tit tvunget til at beskytte en meget betydelig investering i den eksisterende platform. Så hvis it-afdelingen primært egenudvikler er det sikkert et fint princip som ikke spænder ben for forretningen.
Men hvis it-afdelingen pr. princip afviser indkøb af systemer for at beskytte de indre linjer, er det vel et bedre alternativ at købe systemerne som en service i stedet.
" Et eksempel er princippet om at bruge en bestemt database-teknologi, fx Oracle i stedet for MS SQL eller omvendt"
Hvis dette valg er med i et arkitektur dokument, skal forfatteren have tæsk med en spegepølse.
Dette er en strategisk beslutning om valg af samarbejdspartnere, og intet andet.
Hvis it-afdelingen nægter per princip er det vel oftest fordi der ikke følger passende mængde penge med en opgave alt efter hvor besværlig den er. Jeg forestiller mig at det er meget typisk for en afdeling hvis den drives som et cost-center. Forhåbentlig kan it-afdelinger i fremtiden henvise til hvad de gør billigere end eksterne leverandører (f.eks. i form af *AAS) og så udelukkende lave de opgaver. Det giver vel også økonomisk set mere mening.
Det er jo i sig selv fascinerende, at bare ved at kalde noget for et "arkitektur-princip", så får man en hammer som slår hårdere end sunde økonomiske argumenter ;-)
Enhver virksomhed bør sikre sig at alle i virksomheden har fokus på at anvende virksomhedens ressourcer bedst muligt til at fremme virksomhedens mål.
Derfor bør enhver investeringsbeslutning (hvad it-aktiviteter jo i bund og grund er), baseres på analyse af hvordan beslutningen udføres med det størst mulige resultat, til færrest mulige midler (i investering hh drift osv).
Så det interessante ville være at omdøbe ethvert "arkitektur-princip" til "Investerings-princip", og spørge interessenterne "I hvilke situationer og under hvilke forudsætninger er dette det bedste Investerings-princip vi har ved hånden".
Det kan under givne forudsætnigner give god mening at konsolidere en given slags IT-projekter på en given eksisterende teknologisk metode og platform. Og under andre forudsætninger vild et være økonomisk galimatias at gennemtrumfe samme teknologiske metode og platform.
Så mit bedste bud - omdøb ALLE IT-arkitektur artefakter og aktiviteter til "Investerings"-ditto - og se hvad der kommer ud af den nye tankegang.
Bolden er givet op
Det var meget firkantet Nils. Selvfølgelig skal et valg af en platform, det være sig database platform, hardware platform eller programmerings sprog da dokumenteres i et arkitektur dokument, formodentlig i et selvstændigt dokument der netop dokumenterer arkitektoniske valg, herunder også valg af faktiske produkter.
Hvis man ikke dokumenterer et valg, og grundene for dette valg, så glemmes disse grunde jo netop over tid, og det bliver til et 'sådan plejer vi at gøre' eller det der er værre.
Den her kløft mellem forretningen og leverings apparatet (produktionen) er cirka lige så gammel, som det første firma. Måden at løse det på er fleksibilitet, samarbejde, og forståelse for hinandens fagområder. Problemet er nok at de sidste par år er det forretningen, der har haft overtaget, med dertil følgende stigende udgifter.
// Jesper
@Jens Jakob Andersen Jeg er 100% enig i at ethvert arkitektonisk princip skal bunde i en TCO betragtning, det burde være logik for burhøns, ok det er det så ikke mange steder hvor der er BetonIT :)=
Problemet er bare også, at forretningen som regel ikke har, pardon my french, en fløjtende skid forstand på IT. Og når de får lov til at lave IT beslutninger, så er det først at tingene begynder at koste kassen.
Selvfølgelig er der undtagelser. En del af IT folkene i min omgangskreds, inklusive mig selv, er i dag mere involveret med 'forretningen' fordi vi bevæger os i gråzonen mellem forretningen og IT. Og generelt er vi sku ikke imponerede over det faglige niveau i 'forretningen'.
// Jesper
Ofte i en lidt større virksomhed defineres strategiske samarbejdspartnere med baggrund i forretningsmæssige mål, leverandørers evne til at overbevise top ledelsen om hvorfor de kan være med til at drive forretningen videre, ... Dette drives normalt af en procurement afdeling, hvor arkitekturafdelingen har aktie i at give input/godkende de valg som er blevet taget. Er en leverandør først inde som hovedleverandør, så må arkitekturafdelingen ofte blot agere dem som skriver under på at de næste løsninger fra samme leverandør er ikke sikkerhedsmæssige problemer. Det hedder strategiske partnerskaber og handler ofte mest om kost-optimeringer på anskaffelsespris (herunder kontraktforhandlinger) samt operational support. Jeg har endnu ikke set et arkitekturprincip katalog som indeholder valg af databaseleverandør - hvad vil man skrive i rationalet? Procurement afdelingen/IT-chefen har valgt leverandøren? Teknologivalg vil ofte optræde i technology platform documents eller technology standard documents. Hvis du vil diskutere det egentlige bagvedliggende spørgsmål, så er det ikke arkitekturprincipper du skal kikke på. Det er spørgsmålet om hvordan skaber man strategiske partnerskaber uden, at de bliver en hinkesten om halsen - altså hvordan kan man lave stordrift samtidig med at organisationen evner at omstille sig i forhold til udfordringer/løsninger der opstår et behov for[1]. Det afhænger af din virksomheds business operational model, som skal føde dine arkitekturprincipper.
[1] - hvis det skal blive konkret. Standard problem - virksomhedens ledelse laver en IT strategi beslutning om, at være et Microsoft hus; Microsoft teknologier skal vælges frem for andre leverandøres. Fordel: du kan få optimeret dine omkostninger til kompetencer (kendt teknologi i marked), support (igen, kendt teknologi), udviklingsomkostninger idet der findes mange systemer som understøtter Microsofts software, samt løsningstilgange. Ulempe: det er svært at skalere din teknologi når en SQL server koster et to-cifferet tusinde tal. Du bliver i din løsningsarkitektur ramt af operational cost-cutting princippet og mange procestrin i infrastrukturbestilling processen designet til at fjerne ønsket om at få flere databaser, mv.... Det vil have været nemmere, at benytte en gratis NoSQL server i (hvis ikke alle) din arkitektur, da licensfolkene ikke vil brokke sig over licenskosten. Desværre strider det imod strategisk leverandør valg, samt at du skal have bygget de tilsvarende skills (=$$) op i organisationen..... Så du bliver altså holdt tilbage i at levere en løsningen til forretningen, idet IT-afdelingen forsøger at lave stordriftsfordele (qua deres KPI'er). Hvordan vælger man det rigtige valg nu? og samtidig evner, at omstille sig hvis forretningen pludselig kræver et produkt hvor man skal hurtigt skal kunne skalere i IT-løsningen? I mit hoved leder mange efter noget i retning af cloud for at angribe dette problem, men det er en helt anden snak.
Jeg har oplevet det samme princip i flere virksomheder jeg har været ude i. I 2 eksempler har jeg oplevet at man har haft et princip om at databaseløsningen skal være Open Source og gratis og nå ja helst MySQL fordi den ved IT-afdelingen hvordan man administrerer.
Gratis-princippet er fuldstændig hul i hovedet når man samtidig hyrer dyre konsulenter til at stå for udviklingen (I dette tilfælde en BI løsning). Med den rigtige database som fundament kunne udviklingstiden have været skåret ned til det halve og man havde stået med en bedre løsning - istedet ryger man ud i en masse dyre (i specielt tid) nødløsninger. Prisen for en SQL Server licens betyder nul og niks i den her sammenhæng - om den så kostede 100k ville det være et ligegyldigt beløb holdt op imod totalomkostningen for projektet.
Jeg har også oplevet at man har haft et princip om ikke at køre Windows-servere, men har invisteret i et rapporteringsværktøj hvor serveren er skrevet i .NET til Windows (Det er nu engang svært at få gode BI værktøjer til Linux) - men hvor nogen så har fået den fantastiske ide at køre det igennem et tool der på meget skummel vis konverterer .NET assemblies til Java hvori det så ovenikøbet afvikles via en java-konverteret Mono runtime (!) ... Blot fordi man insisterede på at det skulle kunne køre under Linux, Apache og Tomcat (Well, det virkede - men tør man virkelig drifte et system man er afhængig af på en sådan hacket løsning?).
Der begåes rigtig mange af den her slags dumheder i specielt de store virksomheder.
Hvis det var i relation til hvad jeg skrev, så er jeg glad for du blot understøtter mit udsagn. Det er ligegyldigt, om du som IT-afdeling ansvarlig laver et strategisk partnerskab med IBM, Oracle, Microsoft, Accenture, Deloitte eller ruderkonge leverandøren af en LAMP løsning for at minimere dine udgifter ved drift og udvikling (f.eks. igennem minimering af kompleksitet i arkitekturlandskabet). Du kommer stadig til at håndtere den problemstilling i at de kan blive hinkesten omkring halsen, hvis de forhindrer forretningen i at få løsninger til tiden og den rigtige pris. IT-afdelingen kan dog ikke ignorere stordrifts princippet i den konstante kamp i at drive omkostningerne ned, så der er et svært valg i at lægge det rette snit. En pris på 100k for en SQL server licens kan fjerne muligheden for at lave en skalerbar løsning, hvis indtægten ved en løsning ikke matcher tilsvarende. Vi kan alle finde på grus der kan sparkes op i luften for derved at få 100k til at se lille ud (man kan som regel altid danne en positiv ROI på hvilket som helst, hvis man selv må bestemme regnemetoden og aspekter der tages med ind i beregningen), men summa 100k er stadig en hamper pris for en database licens for de fleste firmaer. Sandsynligvis af samme grund indgår der ofte store rabatter i loyalitetsprogrammer (=stordrift) fra de ovennævnte softwareleverandører.
Nej ud med arkitekterne og lad os få managers til at bestemme teknologi ud fra hvad de er blevet bildt ind af smarte provisionslønnede sælgere.
I de arkitektur principper, eller reference arkitekture, jeg har stået for. Har der altid været en indledning i retningen af:
Teknologivalgene og principperne i dette dokument kan godt fraviges, hvis der er en god grund til det. Men der skal spørges om lov først og argumenteres for det.
Principperne er gode at have, så alle udviklere ikke lige finder diverse open source komponenter på nettet og bruger dem, uden at koordinere centralt. Principperne bliver hurtigt indført, når du har oplevet smerten ved at vedligeholde (og ultimativt omskrive) løsninger, baseret på tilfældigt valgte komponenter af lav kvalitet.
Mads: I dette tilfælde var der tale om at dyrere databaseløsninger understøttede kritiske features, som kunne have lettet udviklingsarbejdet betragteligt og gjort det lettere at integrere med eksterne løsninger, men på ledelsesniveau har man truffet beslutning om at man kun vil understøtte en bestemt database som man tidl. har erfaring med at drifte (hvilket jeg sagtens kan se rationalet i, men det er farligt at ophøje til en principsag kun baseret på dette argument).
Når man holder det op imod at hver udvikler på projektet kostede mere om måneden end en licens til en database der ville kunne opfylde kravene, så skal der altså ikke spildes meget tid på at lave krumspring omkring manglende features før end at regnestykket ikke længere går op.
Problemet er at udgiften til en dyr databaselicens er en meget upfront og håndgribelig udgift, hvorimod antal mandetimer det koster er et sværere regnestykke at gøre op i kroner og ører - men det er grundlæggende farligt at lade sig forblænde af at en licens til noget der udgør fundamentet i et system til 2-3 mio. kr er dyr fordi man føler 100k er mange penge for et stykke software.
"Et vidunderligt CRM-system", der kun kan køre på èt proprietært database-system, så det er svært at integrere med andre systemer i virksomheden.
Jeg er enig med Casper Bang: Tøv en kende inden i lader sælgerne invadere virksomheden.
Sååh hvem skal bestemme hvilke systemer, organisationen skal have? Foreslår du at det er it?
Det må vel være forretningens beslutning - it's opgave må være at forretningens beslutning sker på et oplyst grundlag.
it's opgave må være at forretningens beslutning sker på et oplyst grundlag.
Det er lige præcis kernen i spørgsmålet. Jeg vil hævde at den vigtigste årsag til at indføre et arkitekturprincip er at det får resort-chefen til at tage IT med under indkøbsprocessen. Hvis ikke den slags foreligger, bliver IT ikke orienteret før der er lavet aftale om hvornår en tekniker kommer og installerer systemet.
Nej ud med arkitekterne og lad os få managers til at bestemme teknologi ud fra hvad de er blevet bildt ind af smarte provisionslønnede sælgere.
Og resultatet vil være en virksomhed, der har 5 forskellige databaser på 10 forskellige os'er, der er grundlag for 17 systemer, skrevet i 6 forskellige sprog.
Jeg ved ikke med jer, men jeg gad ikke arbejde der ..
Til gengæld er der sikkert mange konsulenter, der vil se en sådan virksomhed som en absolut guldgrube.
Sååh hvem skal bestemme hvilke systemer, organisationen skal have? Foreslår du at det er it?
Jeg foreslår en vekselvirkning imellem det strategiske og pragmatiske; management ved hvor virksomheden gerne vil hen, og IT ved hvordan det kan lade sig gøre i praksis.
Det kan jo ikke nytte noget at management, efter at have været til en præsentation hos Microsoft, kommer til sine Java udviklere og forlanger at nu skal der skrives i F#, Linux skal udskiftes med Windows, Oracle med SQLServer etc. etc.
Hvorfor skal management intereserer sig for motoren i maskinen; den skal vel bare køre stabilt og understøtte forretningen?
Nu er principper jo ikke det samme som en facitliste. Principper er vejvisere og guidelines, når de enkelte strategiske valg skal træffes, således at man ikke starter fra bunden af hver gang. Så enig i at man ikke laver et princip om at man bruger database X. Det vil jo være et helt forkert scope at have på sine principper.
Så når Peter direkte spørger om hvem som bestemmer hvilket systemer forretningen skal have, er det et - og hold nu fast - samarbejde mellem forretningen og IT, der benytter de stadfæstede principper til at træffe valget og igen ud fra en TCO betragtning. Dette er desuden en opgave som typisk havner hos arkitekter.
Hvis ikke valget bliver baseret på principper er det følelser, religioner, farver på knapperne og blinkende rapporter som bestemmer - eller måske hvem som kommr tættest på pinden på hul 9 ;-)
Det lyder som den helt rigtigt tilgang. En ting er hvis it-afdelingen laver principper for egen skyld (det kan nogle gange retfærdiggøres).
Men hvis it-afdelingen, uden en forretnings-sponsor og på eget initiativ via sine principper, påtager sig ansvaret for de længererækkende konsekvenser af et givent indkøb, så er der lagt i kakkleovnen til udsagn som "it siger altid nej", "it er bagstræberisk" osv.
Det må være målet at få forretningen (eller i praksis "nogen i forretningerne") til at tage det ansvar.
@Peter Nørregaard
Det basale problem er jo, at typisk har forretningen og tit også dennes rådgivere, jo ikke en fløjtende fis forstand på 99% af de aspekter der er i IT. Selvfølgelig er det dem der typisk skal vælge hvilken forretnings applikation, de mener bedst understøtter forretningen. Men resten af løsnings stakken neden under bør de overlade til eksperterne.
Desuden er problemet at magtbalancen i virksomheden typisk hedder 90/10 i forretningens favør. Forretningen bliver typisk også målt anderledes end IT. Hvis vi snakker en salgs funktion har de typisk mål der hedder uge/måned/kvartal/måske årlige mål. Det skal man holde op med en IT funktion der typisk skal forholde sig til solution lifecycles der strækker sig over årevis.
Hvilket betyder at forretningen har et TCA fokus, og IT har et TCO fokus. Now that is a disaster waiting to happen.
Derfor ser man typisk at projekter, sat i gang af forretningen, har deres egne IT budgetter, og selv skal afholde de udgifter der nu skal være til IT. Og selv om det er meningen at IT delen skal følge IT strategien, så igen har forretningen så meget magt, at den som regel får lov til at gøre, som den vil.
Og så er det serversprawl, knopskydninger, 'you name it we've got it' happens.
Og det betyder så at TCO'en ryger i vejret, da forretningen fokuserer på TCA. Og IT står med aben og er den skyldige part.
// Jesper
