Email
Like
Liked ×
Save
Private Content
Embed
Loading embed code…
We have emailed the verification/download link to "".
Login to your email and click the link to download the file directly.

To request the link at a different email address, update it here. Close
Validation messages. Success message. Fail message.

Check your bulk/spam folders if you can't find our mail.
Loading

+ Follow

MSDN Live 2010 - Solution Architecture

by Sondre Bjellås on May 10, 2010

1,886 views

Presentation from MSDN Live 2010 on Solution Architecture. Core ideas in the presentation is that we continue to fail in a large scale in the IT-industry and it's time to reduce complexity in our ...

Presentation from MSDN Live 2010 on Solution Architecture. Core ideas in the presentation is that we continue to fail in a large scale in the IT-industry and it's time to reduce complexity in our solutions and systems to improve the success ratio of IT-investements.

The slide decks are very simple and not a lot of content, therefor all the notes are included with the presentation. Suggest anyone reading this presentation to download the original file with full comments and notes.

Accessibility

View text version

Upload Details

Uploaded via SlideShare as Microsoft PowerPoint

Usage Rights

File a copyright complaint

8 Embeds 732

http://sondreb.com	694
http://localhost	19
http://www.slideshare.net	7
http://justatechblog.com	4
http://feeds.feedburner.com	3
http://www.lmodules.com	2
http://www.sondreb.com	2
http://gent.softcatala.org	1

More...

Statistics

Likes: 1
Downloads: 41
Comments: 0
Embed Views: 732
Views on SlideShare: 1,154
Total Views: 1,886

Hei og god morgen alle sammen! Utrolig hyggelig at så mange av dere har tatt fri fra jobben idag og kommet hit for å høre på oss. Jeg har gledet meg veldig til å komme hit og snakke med dere litt løst om løsningsarkitektur...Jeg har jobbet en god stund med å forberede dette innlegget. Opprinnelig tenkte jeg det kunne være interessant for dere å høre litt detaljer om løsningsarkitektur, metodikk, verktøy osv. Men etterhvert som jeg jobbet med foredraget ble det mer naturlig å se på et større bilde av tilstanden i vår bransje. Det finnes tusenvis av gode ressurser, tekniske artikler og foredrag dere kan finne på nettet i ettertid. Jeg har inkludert noen ressurser til slutten av foredraget som kan hjelpe dere å sette dere mer inn i detaljene for løsningsarkitektur.
Mitt navn er Sondre Bjellås og jeg bygger programvare. Bygge programvare er noe jeg er veldig stolt av og jeg synes det er kjempespennende å få muligheten til å prate med dere om hvordanman designerløsninger som løser viktige problemer i vårt samfunn!Jeg jobber som senior løsningsarkitekt hos Steria i Oslo. Vi er et internasjonalt konsulentselskap med kontor i Oslo og over 450 ansatte med en voksende Microsoft avdeling.
Jeg skal prate om tre ting..Hvordan ligger vi ann i IT-industrien og investeringer i prosjekter? Dere har alle hørt det før: Vi har en relativt lav prosentandel av suksess på IT-prosjekter. Har vi forbedret oss etter mange år med dårlige tall...Hvilke utfordringer har vi som systemutviklere? Hvordan har utviklingen vært de senere årene, har det virkelig blitt lettere å utvikle systemer?Til slutt vil jeg foreslå det jeg mener er én av flere løsninger, som kan hjelpe oss til å bli bedre med å gjennomføre prosjekter og redusere risiko.Hvaer dagens status?
6 billioner dollar, det er tallet som Roger Sessionsharestimertertaptekostnaderpga. feilet IT-investering. Detteinkludererprogramvare, maskinvareogtjenester... Han menerogså at dettetalletøkereksponensielt. Hvabetyrdet? Eksponensieltbetyr en fordoblingavproblemet over en begrensettidsperiode. Men hvaeregentligdettenummeret, detersåenormt at detervanskelig å forstå…
er at vi snakkeromtallet 6, med hele 12 nullerbakseg, hvis vi bryter det ned blir det...
500 milliarder dollar i måneden, i tapte penger pga. feilede IT-investeringer og prosjekter. Vi må nok sammenligne dette med noe for at det skal gi mening... Til sammenligning....
...brukte den amerikanske stat 787 milliarder dollar i hele 2009 på å hjelpe økonomien tilbake på beina. (700 i 2008).Hvilken annen sammenligning kan vi gjøre?
Dette er den splitter nye Dell Adamo XPS, en fantastisk nydelig ny bærbar som kommer snart, vil koste 1800 dollar. Dette er en fantatisk bærbar, den ser helt nydelig ut og den er supertynn! Den er tynnere enn én cm, tynnere enn MacBook Air! Hvor mange av disse kunne vi kjøpt med de tapte pengene?
278 millioner bærbare.... i måneden!
Hva betyr egentlig disse tallene? Hvorfor skal vi bry oss om usannsynlige summer?
Det representerer muligheten til å spare inn 11.5 millioner dollar i sekundet. Det er mye penger det og representerer enorme muligheter til nyskapning.
Siden 1994 har Standish Group utarbeidet en rapport for suksess og problemer med utviklingsprosjekter. Hvordan har vi gjort det siden 1994 tror dere? Har vi blitt flinkere?
Ja, vi hadde en forbedring fra -94 til -96, men etter det har vi ligget gjevnt på ca. 30%. Er vi fornøyde med dette? Hvorfor er det slik at vi ikke blir bedre?En ting er ihvertfall sikkert...
Kundene våre er ikke særlig fornøyde! Det burde vi ikke være selv heller, jeg er absolutt ikke fornøyd med denne statusen på vår egen bransje.Vi har hatt dramatisk utvikling innenfor mange andre områder i IT-bransjen, vi må få til lignende utvikling innenfor vår egen bransje, nemlig systemutvikling.... La oss se hvordan utviklingen har vært på andre områder...
Denne kurven viser utviklingen i lagringskapasitet. Disse tallene representerer en eksponensiell vekst, en kontinuerlig fordobbling av kapasiteten. Det er ikke slik at vi opplevere en normal vekst, hvor vi går fra 1GB til 1.1GB og videre til 1.2GB. Vi har en formidabel vekst hvor vi har gått fra 1GB til 2GB til 4GB osv.Når jeg først tenkte på dette med lagringskapasitet, hadde jeg tenkt å nevne at man i dag får kjøpt harddisker med fantastiske én terrabyte lagringskapasitet! .. For å være sikker på dette, sjekket jeg raskt en nettbutikk, og hva fant jeg? De største harddiskene i dag er faktisk TO TERRABYTE!Vi har i dag nok lagringskapasitet til å lagre hele livet vårt, vi kan spille inn lyd, bilde og all kommunikasjon med letthet.
Hva med Moore’s lov om økt antall transistorer på en integrert krets? Jo, den holder stadig grunn. Det har lengre vært en formidabel prosess med fordobling av antall trasistorer. I dag har vi prosessorer med over 2 milliarder transistorer. Skjermkort har enda mer, godt over 2 milliarder i enkelte tilfeller.
Did You Know? http://www.youtube.com/watch?v=cL9Wu2kWwSY
Håper disse tallene og grafene gir en rask bakgrunn for hvordan vi ligger ann i bransjen og hvilke muligheter vi har til å gjøre enda bedre enn det vi allerede gjør. Jeg tror det er ubegrenset med muligheter som har blitt realisert med utviklingen innenfor lagringskapasitet og ytelse, muligheter vi fortsatt ikke har utnyttet bra nok...Det var mitt første poeng, nå skal vi forsøke å se litt på årsaken til tingenes tilstand og hvilke utfordringer vi har, før jeg til slutt vil fortelle litt om hva jeg tror vi kan gjøre for å forbedre vår egen bransje...
En av de ledendeårsakenetil at utviklingsprosjekterfeilerer i all oversakénenkelårsak: KOMPLEKSITET!Rapportentil Roger Sessions viser at deter en sammenhengmellomprosjektersomfeilerogkompleksiteten.Kostnadererogsåproposjonelt i forholdtilkompleksitet.Detertreandreelementersomharomvendtproposjonalitet i forholdtilkompleksitet, demersomfølger:Smidighet, SikkerhetogVedlikeholdbarhet.Desto mer smidig prosjektene er, desto større sjans for suksess og redusert risiko.Desto mindre sikker en løsning må være, desto større sjans for suksess. Ja, sikkerhet er komplisert, ekstremt komplisert.Desto mer vedlikeholdbar en løsning er, desto større sjans for suksess. Det sier seg selv, men det er likevel noe vi aldri kan fokusere nok på.Jeg ønsker å grave litt dypere i noen av disse elementene, som sikkerhet.
Da jeg gjorde research for dette foredraget forsøkte jeg å finne noen som har kalkulert den økte graden av kompleksitet i programvare og teknologi, men klarte ikke finne noe. Det jeg derimot er overbevist om, er at vi ville sett lignende grafer på utvikling som vi har sett med lagringsplass, minnekapasitet og transistorer. Nemlig en graf som går rett til himmels.OK, så kompleksitet er en viktig årsak til at vi ikke har flere IT-prosjekter med suksess. Men hva ligger egentlig i dette, hvordan har kompleksiteten blitt større i dag enn den var tidligere? Hva er det vi har som utfordringer i vår jobb som systemutviklere og arkitekter?
Det er utrolig mange spennende utfordringer vi har som systemutviklere, vi kunne holdt et heltdagsseminar på hver og en av dem.Utfordringer som skalering.Utfordring som stabilitet.Utfordringer med feilhåndtering og loggføring.Utfordringer med interopabilitet på tvers av systemer.Utfordringer med sikkerhet ikke minst, og sikkerhet er det jeg ønsker å se litt nærmere på...
Sikkerhet er et kompliserende element. Desto mer sikkerhet du trenger, desto større risiko har du med inn i prosjektet. Desto mindre fokus man har på sikkerhet allerede i starten av et prosjekt, desto mer kostbart vil det bli utover i leveransen.Sikkerhet er et veldig tungt emne, det er i dag veldig krevende å være ekspert på sikkerhet. Med nye sofisikerte måter, angriper mennesker med negative intensjoner våre datasystemer. Ikke bare må vi slite med tusenvis av mennesker som bor i andre land, vi har også potensielt problemer med ansatte som ikke alltid gjør det dem burde.Det man lærer på skolen om sikkerhet er velge begrenset og det er langt ifra nok til å kunne lage sikre IT-systemer i dag. Hvordan vet DU at det du utvikler er sikkert? Har du noen gang utviklet kode som du med full bevisshet vet er usikker kode? Jeg har gjort det, og jeg gjør det hele tiden. Jeg vet selvsagt at ingen av dere i salen lager usikker kode, dere er alle sikkerhetseksperter som aldri gjør feil. Men det er mange andre der ute som ikke alltid vet hvordan man skal holde seg sikker...Kanskje dere er flinke til å sjekke all input fra brukerne, påser at det ikke kommer noen rare tegn inn i databasen med å bruke regulære utrykk og andre former for validering av input fra brukeren. Men hva med innholdet dere leser fra databasen? Sjekkes det? Hvordan kan man være sikker på at andre løsninger som lagrer til samme database, ikke har en sikkerhetsfeil? ...Dere har sikkert fått med dere at vi har fått flere og flere automatiske bomveier rundt norske byer. Jeg kan tenke meg at de har et grensesnitt som tar inn et registreringsnummer på ca. 5-6 tegn, litt avhengig om det er norskt eller ikke... Hva tror dere kommer til å skje, når jeg kommer kjørende med denne på veien inn til Oslo?
....Vil jeg slippe gratis igjennom uten å betale, eller sletter jeg hele databasen i systemet?
Sikkerhet er et områder som øker kompleksiteten dramatisk, og det er desverre et område som får for liten fokus og ressurser.Sikkerhet i IT-løsninger er som å gå på en line, det er en balansegang med uventede momenter og sterke sidevinder som kan ødelegge balansen og få oss til å falle.Det er en balanse av brukervennlighet. Sikkerhet er i mange tilfeller en motstridende faktor for brukervennlighet. Desto sikrere en løsning er, desto mindre brukervennlig. Fordi vi ikke har vært flinke nok til å bygge sikkerhet inn i våre egne utviklingsprosjekter, har aktører som Microsoft vært nødt til å sikre oss selv, mot oss selv. Vi utviklet programmer som krevde at brukerne var lokale administratorer på sin egen maskin, i veldig mange tilfeller var dette høyst unødvendig.Resultatet av dette var User Account Control, også kalt UAC eller som jeg liker å kalle det: UAC-a-mole! ... Heldigvis er mengden av disse dialogene redusert på Windows 7, men jeg føler fortsatt dem strengt tatt er veldig unødvendige.
Jeg har to eksempel til jeg ønsker å illustrere for å vise hvordan ting har blitt utrolig mye mer komplisert enn det engang var... Det første er dette eksempelet:
...Slik var det vi logget brukere inn i webbaserte systemer i «gamle dager». Da jeg begynte å jobbe med webdesign tilbake i 1998, var lagret vi brukernavn og passord i klartekst i databasen. Når brukeren kom til websiden, leste vi brukernavnet og passordet, sammenlignet dette med hva som lå lagret i databasen. Hvis det var en match, skrev vi en cookie til brukeren med bruker Iden slik at vi lett kunne identifisere brukeren mens han eller hun brukte løsningen.Hva tror dere enkelte gjorde? De åpnet cookie filen og byttet ut bruker ID eller brukernavnet. Whops, så var man pålogget som en annen bruker.Andre gjorde det på en enda enklere måte...
Med å fylle dette inn i brukernavn og/eller passord feltet, da kom man inn nesten uansett.SQL injection i «gamle dager» var mulig på så og si mulig på alt som røret på seg ute på nettet.Selv i dag, er det farlig mange nettsider som ikke gjør en skikkelig bra nok jobb for å beskytte seg. Det er ikke rart, for SQL-injection og andre web-angrep blir stadig mer sofistikerte.
Med eksempelet mitt i bakhodet, altså Response.Cookie for å skrive bruker Iden på brukerens PC, skal jeg demonstrere hvordan kompleksiteten for autentifisering av brukere har blitt med teknologier som Windows Identity Foundation – som dere får høre mer om i detaljer senere idag.DEMO: Vise demo av kallene som går frem og tilbake, all konfigurasjon som må til, cookies, osv.
Ting var litt enklere før?... Mitt neste eksempel handler om kommunikasjon mellom klient, server og tjenester. Dette er veldig aktuelt for de av oss som jobber mye med tjenesteorientert arkitektur aka. «SOA» og distribuerte løsninger.
En god kollega av meg, Johannes Brodwall, sa en dag vi hadde lunsj sammen: Hadde det ikke vært for at brannmuren ble oppfunnet, ville aldri SOAP blitt påtenkt. Kan dere tenke dere årsaken til at brannmuren ble oppfunnet? Jeg har en teori: Brannmuren ble oppfunnet fordi VI, du og jeg, ikke klarte å lagre sikre web-løsninger!Ugh, så SOAP ville sannsynligvis ikke eksistert hvis brannmuren aldri hadde kommet. Argh... Vi trengte SOAP fordi nettverksansvarlige sperret alle porter utenom HTTP port 80, porten vi bruker for webtrafikk.Man kan si hva man vil om SOAP, jeg liker i utgangspunktet SOAP, men det er unødvendig kompliserende. Det er også tungt og treigt, spesielt om man ikke benytter seg teknikker for komprimering o.l. Mange bruker SOAP hvor det absolutt ikke trengs, mange bruker SOAP på feil måte.Som en reaksjon på SOAP har vi fått REST. REST er en mye enklere protokol som også bygger på HTTP, men prinsippene og mekanismene er betraktelig enklere enn SOAP.Microsoft støtter REST i utstrakt grad og har full fokus på at REST skal være et likeverdig alternativ til SOAP på mange områder.Spørsmålet vi må stille oss selv, hvor mye annet interessant og spennende kunne vi kunne utviklet hadde vi bare gjort jobben vår skikkelig den første gangen?
Hvor begynte vi og hvor er vi nå? Vel, dette er et eksempel på en SOAP spørring. Den er relativt enkel.
Og dette er resultatet fra forrige spørring. Også ganske enkel å forstå... Men dette er selvsagt ikke slik du burde bruke SOAP. Dette eksempelet bruker forrige versjon av SOAP, det er ingen sikkerhet eller kryptering inkludert, det er mange måter disse meldingene kan manipuleres på uten at avsender eller mottaker vet noe om det.
I flere av prosjektene jeg har vært med på har vi benyttet SOAP og de senere årene er det Windows Communication Foundation som har vært det prefererte rammeverket for å lage tjenester. I de aller fleste tilfellene benyttes den mest elementære bindingen mellom klient og tjeneste, nemlig BasicHttpBinding.Denne bindingen er den enkleste, mest elementære og det mest utbredte formatet. De eksempelene jeg akkurat viste er den enkelte bindingen. Det er støtte av så og si alle kommunikasjonsrammeverk på alle plattformer du kan finne.Som jeg nevnte, det er derimot absolutt NULL sikkerhet i denne bindingen, all datatrafikk overføres i klartekst så lenge man ikke benytter SSL-sertifikat. Med BasicHttpBinding kan hvem som helst manipulere meldingen mens den beveger seg fra klient til tjeneste.Tidligere var WSHttpBinding default i WCF. Dette har blitt endret med Visual Studio 2010, hvor det faktisk er basicHTTPBinding som er default. De av dere som har jobbet litt med WCF kjenner nok til dette, men som en del i denne økte kompleksiteten vil jeg gjøre en rask demo for å illustrere et poeng.DEMO: Vise hvor mange SOAP-meldinger som faktisk overføres for ETT enkelt tjenestekall med wsHttpBinding.
Selv om kompleksiteten har økt betraktelig, har også abstraksjonsnivået og verktøyene blitt bedre. Man kan som jeg har illustrert, veldig enkelt skrive en WCF-tjeneste uten å tenke på hva SOAP er for noe. Men...På et prosjekt jeg jobbet på, brukte noen vanlig basic-binding og noen andre team brukte WS-binding. Dette fungerte greit når det var åpen kommunikasjon på tvers av serverene. Godt ute i prosjektet kom det endringer på infrastrukturen, en sikkerhets-gateway kom inn i bildet. All trafikk som gikk inn og ut mellom eksterne partnere skulle gå igjennom denne sikkerhets-gatewayen. Hva ble resultatet? At de mer kryptiske meldingene i oppstarten av en sikkerhets-utveksling mellom tjenester som brukte WS-binding feilet, sikkerhets-gatewayen forstod ingenting og resultatet ble at man måtte omgå gatewayen for å løse «problemet».
Det er en annen viktig årsak til at utviklingsprosjekter feiler, og dette er sannsynligvis den største årsaken og ikke kompleksitet. Det er estimering! Men jeg ønsker ikke å fokusere på estimering, fordi estimering er noe vi gjør feil hver eneste gang. Vi har hørt det hundrevis av ganger, vi har lest bøker, blogger og artikler, likevel klarer vi ikke å få til estimering.Mye vi kunne sagt om dette og jeg ønsker ikke å henge ut noen spesifikke roller. En ting er sikkert, vi er i felleskap ansvarlige for dette. Kommer tilbake til estimering i en utfordring jeg har til dere helt til slutt...
Er det noe annet som påvirker kompleksiteten? Ja, funksjonalitet!«Glass’s Law» som indirekte er etablert av Robert Glass i sin bok «Facts and Fallacies of Software Engineering» sier i all enkelhet: 25% mer funksjonalitet fordobler kompleksiteten!Kan det virkelig være så enkelt? Hvorfor presenterer vi ikke disse tallene for kundene når de kommer til oss og ønsker mer funksjonalitet? Hvorfor har vi tendensen til å glemme kompleksitetselementet når vi utvikler løsninger? Når vi estimerer en enkeltstående oppgave, tar vi skjeldent med i kalkuleringen kompleksitetfaktoren som før eller senere kommer til å koste prosjektet mer penger, mer tid og potensielt øke risikoen for at prosjektet ikke kommer i mål.Jeg synes denne loven og utregningen gjør alt mye klarer for meg, jeg synes det er helt fantastisk bra. Nå har jeg et konkret tall og referanse som grunnlag når jeg skal estimere.
Nå har jeg presentert noen eksempeler på hvordan kompleksiteten i hva vi gjør har vokst, den har vokst ganske dramatisk. Dere kjenner selv veldig godt til alle de andre områdene hvor kompleksiteten har vokst.Samtidig som kompleksiteten i teknologiene har økt, har også selvsagt verktøyene blitt mye bedre. Vi har større datakapasitet som gjør det mulig med abstraksjoner på et høyere nivå. Man kan lage WCF-tjenester uten å tenke over SOAP, man trenger aldri å se en eneste SOAP-melding og likevel fint klare å lage WCF-tjenester.Hva er løsningene på kompleksitetsproblemene vi står ovenfor? Hvordan kan vi begynne å bevege oss i en annen retning, fremfor å fokusere på økt funksjonalitet og mer kompliserte løsninger... Hva bør vi gjør?!
Hva er løsningene på disse utfordringene vi har i bransjen? Det er selvsagt et meget sammensatt bilde av utfordringer, som dere alle er veldig klar over. Jeg ønsker å foreslå en løsning som går på løsningsarkitektur og som det kun er vi som kan påvirke, løsningen er...
Er å streve mot er oppnå den minst komplekse arkitekturen, som gjør det mulig å realisere et forretningsproblem.Det er mye lettere sagt enn gjort. Bygge overkompliserte arkitekturer er kjempelett. Noen ganger forestiller vi oss behov og krav som egentlig ikke er realistiske. Kundene vi jobber med forstår ikke alltid deres egne behov og ønsker seg alltid en Rolls Roys på spesifikasjonen. Hvis du skulle kjøpt deg en splitter ny bil, ville du ønsket deg en gammel Lada eller en splitter ny Mercedes?En viktig ting å huske på er at man alltid må utfordre og tenke over designet, vi må aldri bli for tilfreds med arkitekturen og designet.
Hvem er det som kan løse utfordringene, hvem er det som kan bidra til økt suksess i utviklingsprosjekter?
Det er deg og deg og deg! Det er alle vi som må engasjere oss!Dette er et faktum vi ofte glemmer, et faktum som er godt dokumentert og beskrevet i en rekke bøker som omhandler systemutvikling. Det faktumet er at kvaliteten på MENNESKER, ikke verktøy og teknikker, som er den viktigste faktoren for suksess!(Software Engineering Economics, 1981, Barry Boehm)(Peopleware, 1999, Tom DeMarco og TImothy Lister)(Principles of Software Development, 1995, Alan M. Davis)
Vi bygger løsninger, det er det de fleste av oss her i rommet jobber med. Enten det er for vårt eget firma eller kunder.Hva gjør vi når vi bygger løsninger? VI FORBEDRER VERDEN! Vi forsøker i det minste...Det er nemlig det vi gjør som systemutviklere, enten vi er bevisste om det faktum eller ikke. Vi gjør verden til en bedre plass å være.Jeg elsker å programmere, utvikle løsninger for ideer jeg får i hodet og jobben med å realisere disse. Det er denne gleden, gleden man får av programmering som får meg opp om morgen og gjør at jeg gleder meg til å komme på jobb.
Det var en film med Will Smith som het "The Pursuit of Happyness" hvor han spiller ett individ som heter Chris Gardner. Han bodde på et toalett på t-banen i California med sin to år gamle sønn. Hver morgen tok han på sin eneste dress, slapp sønnen av på en mer eller mindre shabby barnehage og gikk på skolen for å bli aksjemegler. Han fullførte på toppen av klassen og ble millionær. Han sa en gang til en reporter om hvordan han fant styrken til å fortsette og han sa:"Finn noe du elsker å gjøre, så mye at du ikke klarer å vente til solen står opp og du kan gjøre det igjen og igjen."
Vi drømmer opp nye løsninger, i samarbeid med våre partnere og kunder bruker vi vår kreativitet, erfaringer og kunnskaper til å drømme opp løsninger og muligheter.Deretter utvikler vi løsninger, vi lager dem slik kundene og oss selv forestiller oss hvordan de skal lages.Dette gjør vi først og fremst for å realisere verdier for våre kunder ... og vi gjør det med lite mer enn våreegne hoder, hender og datamaskiner.
Hvorfor driver vi med systemutvikling og programmering? Hva er det som gjør at vi jobber med det vi gjør, fremfor noe annet?
Er det utfordringene som driver oss, som gir oss energi til å fortsette å kjempe mot de store problemene?
Eller kanskje det er lidenskap, lidenskap for systemutvikling som en kunstform, som en praksis som ikke krever mer enn noen enkle verktøy?
Kjærlighet? Føler dere kjærlighet til det dere jobber med? Jeg gjør definitivt det!
Det er selvsagt alle disse grunnene og mange andre som driver oss til å jobbe med systemutvikling. Selvsagt gjør vi det også for å få penger i lomme =)Mennesker i andre bransjer vil nok si det samme, men jeg er kjempeglad over å ha muligheten til å jobbe med noe som gir meg glede og med noe hvor jeg har det gøy, spennende og utfordrende, hver dag lærer jeg noe nytt.Disse grunnene gjøre at jeg ønsker å gjøre det bedre, jeg ønsker at vi i felleskap skal bli bedre til å gjennomføre prosjekter!
Det er et gammelt ordtak som sier: Hvis du er en hammer, ser alt ut som en spiker. For de som ikke ser hele illustrasjonen, det er to små roboter som forsøker å bruke en hammer for å drepe en liten flue. Verktøy er viktig, gode verktøy gjør det enklere å fullføre oppgavene vi har. Men for ofte lar vi verktøyene styre oss, fremfor å bruke prosesser og metodikk som har vært brukt i lang, lang tid.
Verktøyene vi har idag er fantastiske! Aldri tidligere har det vært så enkelt å utvikle kompliserte løsninger med enorme mengder funksjonalitet. Visual Studio 2010, SharePoint 2010 som derefår se senere idag. TFS 2010 har masse bra og ny funksjonalitet som gjør det enda bedre å jobbe sammen på å løse problemer og realisere verdier for våre kunder.Akkurat som Visual Basic åpnet opp muligheter for praktisk talt hvem som helst til å utvikle programmer, så kommer dagens verktøy med et stort ansvar på oss utviklere. Det er kjempelett åskrive en WCF-tjeneste som potensielt skal levere mange svar i sekundet, men det er som med alt annet i vår bransje: aldri så enkelt som man først forventer.
Hvorfor og hva betyr kvalitet i løsningene vi utvikler? Hvorfor er det viktig at vi fokuserer på å gjøre ting sikre, stabile, brukervennlige, osv.? Hvorfor er det viktig at vi bruker tid og ressurser på løsningsarkitektur?
Fordi programvaren vi utvikler er en del av livet til absolutt alle. Vi, du og jeg, utvikler løsninger som er essensielle for livet til de fleste på jorden. Hvis alle datamaskinene i verden hadde kollapset imorgen, hadde vi nok overlevd, men det er veldig få elementer i samfunnet hvor IT-løsninger ikke er essensielle for drift, vedlikehold og utvikling av samfunnet.
Hva er budskapet for dette foredraget? Hva er det jeg ønsker at dere skal gjøre når dere kommer tilbake på jobb imorgen?Det er å tenke mer på det store bildet! Det store bildet handler om løsningsarkitektur og hvordan løsningsarkitektur kan være en risiko-reduserende faktor i prosjekter.Det er beklageligvis for lite ressurser satt av til utviklingsprosjekter, det er kanskje ikke alltid like lett å konkretisere verdiene for kunden eller dem som sitter med pengegrisen.Med mitt innlegg i dag, ønsker jeg å få de av dere som har lyst til å gå mer over å gjøre løsningsarkitektur til å være med å bidra til opplysning og bevisstgjørelse av verdiene med mer ressurser dedikert til løsningsarkitektur. Jeg ønsket også å belyse noen dogmer som har eksistert mot arkitekter. Noen har den oppfatningen at en arkitekt sitter på en kongelig trone hvor han eller hun er fullstendig utilgjengelig og tar masse avgjørelser, bare for å gjøre livet surt for utviklerne...
En god løsningsarkitekt er ikke en som sitter alene med sine tanker og ideer, det er ikke en person som avviser andre og holder kunnskap for seg selv...
En god løsningsarkitekt deler av alt, av sine kunnskap og erfaringer, av sine visjoner, ideer og tanker for en aktuell løsning. En god løsningsarkitekt er også en som er med på prosjektet i forkant, under utvikling og i etterkant.
Denne gleden jeg får av min egen utvikling, den blir forsterket mangeganger når man jobber i team med andre. Som løsningsarkitekt får man se en større helhet av en løsning og det erfantastisk å se kreativiteten, kompetansen som andre besitter og hvordan ting og funksjoner skapes på alle kanter og vanligvis skjer uten at man må styre eller kontrollere. Det er inspirerende å erfare resultatet av andres arbeid!Effektiviteten til arkitekten og arkitekturen er mest begrenset av hvorvidt andre tar eierskap til hennes eller hans ideer. Dersom teamet ikke gjør ideene til sine egne, vil de kun forbli arkitektens, effekten og verdiene blir dermed begrenset.
Vi må jobbe sammen, utviklere og arkitekter, hjelpe hverandre til å yte bedre...
Jeg har vært med å laget veldig mange varierte løsninger, som hver for seg har hatt en unik arkitektur. Ingen løsning er lik en annen, selv med veldig like behov vil ofte sluttresultatet være ekstremt varierende.Dette er noe av det som er spennende med hva vi gjør: ting er aldri likt, verktøy forandrer seg, forretninger forandrer seg, kravene og teknikkene forandre seg.Men, det er i prinsipp lite forskjell på praksisen med utvikling i tidlig alder av programvareindustrien og hvordan vi jobber idag.Det er også viktig å huske at det ikke eksisterer ett riktig design for et gitt problem, det eksisterer alltid mange muligheter og det er umulig å vite om man har funnet den rette.
Hva må til for at vi skal forbedre dagens suksessratio på 31%? Hvis vi klarer følgende:
Her er en enkel algoritme som sier: Vi ønsker å oppnå en forbedring på 60%. Vi ligger i dag 31% ... Hvis vi har en forbedring på 8% hvert eneste år, som er det siste tallet, hvor lang tid tar det før vi faktisk har kommet helt til 60% suksessratio for IT-prosjekter?
Det vil ta mindre enn 9 år for oss å oppnå 60% suksess!Nå er jeg skeptisk til at vi kan klare hele 8% forbedring, men potensialet ligger der og utsiktene til forbedring ser veldig gode ut...La oss nå oppsummere hva vi har hørt...
Status:- 6 billioner dollar tapt pga. feilet IT-investeringer.Fortsatt bare 31% suksess på utviklingsprosjekterSpare 11.5 millioner dollar i sekundet.
Utfordringer:Ledende årsak til problemener er kompleksitetDet er mange problemområder i vår bransje, jeg gikk litt inn på sikkerhet.Viktig å huske på loven: 25% mer funksjonalitet fordoblet kompleksiteten.
Løsningene:Da jeg pratet om kompleksitet som årsak tidligere, nevnte jeg tre elementer som er viktige faktorer i forhold til kompleksitet: Smidighet, Sikkerhet og Vedlikeholdbarhet. Dette er de tre viktige områdene vi må jobbe mer med. På smidighet har vi kommet ganske langt, vært mye bra arbeid lagt ned i smidig prosesser og utvikling, vi har egen smidig konferansen her i Norge med mange deltakere. Regner med at mange her i rommet er Certified Scrum Masters?Sikkerhet trenger mer fokus, som jeg har vist er sikkerhet komplisert og sannsynligvis overkomplisert av utviklere som har en tendens til å gjøre ting mer kompliserende enn de nødvendigvis trenger. Derfor må vi streve mot å oppnå den minst komplekse arkitektur og løsning for å realisere forretningsbehovet.Vedlikeholdbarhet er også viktig faktor, og den er det dere som er utviklere som har mest kontroll over. Med å fokusere på ryddig kildekode, riktige abstraksjonsnivåer og design patterns, kan dere redusere dette problemenet.Dere burde også nå fått med dere at det er vi, som mennesker, som er den viktigste faktoren til å forbedre dagens status. Hvordan vi kan utgjøre en forskjell til forbedring.Ikke minst er det viktig med godt samarbeid mellom utviklere og løsningsarkitekter.La oss forsøke å gå for 8% forbedring og realisere 60% suksess for utviklingsprosjekter innen 9 år!
Noen ressurser som kan være nyttig for å lære seg mer om løsningsarkitektur og konseptuelle begreper innenfor arkitektur.
Som veldig mange titler i ulike bransjer har løsningsarkitekt en relativt bred rollebeskrivelse, enkelte arkitekter jobber utelukket med konseptuelle skisser og modeller og programmerer ingenting selv. Kanskje man var utvikler for mange år tilbake, men er ikke lengre like mye oppdatert på teknologien.Jeg er selv en løsningsarkitekt som i aller høyeste grad programmerer fortsatt, det gjør at jeg er mer fleksibel i hvilke arbeidsoppgaver jeg kan utføre i prosjekter. På enkelte prosjekter kan det godt hende man er en løsningsarkitekt som kun tegner opp en løsning, men ikke blir en del av det utførende teamet som i ettertid skal realisere en løsning. Dette er etter mine erfaringer noe man bør forsøke å unngå, det er viktig at løsningsarkitekten, om han er en programmerer eller ikke, har god kontakt med både kunden og utviklerne i et prosjekt. Løsningsarkitekten bør være tilgjengelig for redgjørelse av detaljer og planer i løsningen. Det er en hel rekke spørsmål som ofte blir glemt under initiell planlegging og som det ofte krever en større oversikt og forståelse for å gi gode svar på.Først og fremst er det selvsagt erfaring fra systemutvikling man trenger for å bli en løsningsarkitekt. Man må ha en interesse for å bevege seg inn i området, hvor man før eller siden blir mer distansert fra teknologien og beveger seg nærmere forretningene man jobber med.
Det finnes en hel rekke tidsskrifter som er rettet mot løsningsarkitekter, The Architecture Journal er en veldig viktig kilde for Microsoft løsningsarkitekter. Jeg vil også anbefale MSDN Magazine, disse bladene har en god samling av tekniske artikler som gir innsikt i eksisterende og kommende teknologier. Artiklene hjelper både utviklere og arkitekter til å holde seg oppdatert på hva som skjer.
IASA står for International Association of Software Architects. Det kunne like gjerne vært International Association for Software Architects. IASA er en organisasjon av og for IT arkitekter. Den ble startet av en rekke IT arkitekter i Texas i 2003 og det viste seg at det var mange arkitekter over hele verden som ønske å finne sammen - og å trekke å hverandre. IASA er en ideell organisasjon, og drives hovedsaklig på frivillig basis IASA drives av arkitekter- arkitekten først- deretter profesjonen IASA er for alle typer IT arkitekter- Infrastrukturarkitekter- Virksomhetsarkitekter- Løsningsarkitekter- Applikasjonsarkitekter- Arkitektspirer IASA Ledes globalt og drives lokalt - Det er utrolig viktig for IASA å 'tenke globalt, handle lokalt' IASA er teknologi- og leverandøruavhengig
Dette er nettsiden til Simon Brown, en Java og .NET løsningsarkitekt som holder flere gode kurs for utviklere på løsningsarkitektur. Websiden har masse bra artikler, foredrag, m.m.. Den passer veldig bra for utviklere som ønsker å lære seg mer om løsningsarkitektur.
En bok som bare må anbefales for alle er boken Facts and Fallacies of Software Engineering av Robert L. Glass som kom ut i 2002. Denne boken inneholder 55 fakta og antagelser som vi vet er gjeldende for vår industri.
Jeg håper og tror de fleste av dere kjenner til nettsiden JoelOnSoftware.com? Dette er siden hvor Joel Spolsky skriver mye bra om livet til systemutviklere og hva som skal til for at vi skal yte best og ha best mulig omgivelser og miljø. Han har gitt ut to bøker basert på innholdet på nettsiden, Joel on Software 2004 og More Joel on Software som kom ut i 2008. Jeg har kjøpt begge, men hvis dere skal kjøpe en anbefaler jeg den siste.
Jeg har en utfordring til alle dere. Dette er kanskje en av de vanskligste utfordringene dere har fått før. Her kommer den:Dere skal fjerne én funksjon fra løsningen eller produktet dere jobber med. Fjerne én funksjon som kanskje ikke lengre er mye brukt eller som kanskje er unødvendig.Det vanskligste vi gjør når vi utvikler løsninger er å si nei, vi feiler ofte å se konsekvensene av alle tingene vi sier ja til. Vi tenker ofte at det høres ut som en nyttig funksjon, men glemmer å realisere det faktum om «Glass’ Law», at 25% mer funksjonalitet fordobler kompleksiteten.Hvis dere vil, kan dere gjerne sende meg epost hvorvidt dere har suksess med utfordringen!
Det er når man kaster seg ut på dypt vann at man lærer mest! Derfor skal vi aldri være redde for å bli litt våte og ikke akseptere Status Quo, men utfordre etablerte dogmer og praksis.Og med det før jeg åpner opp for spørsmål, vil jeg si takk for meg og tusen takk for tiden og oppmerksomheten deres!

1 Like

ibox2000, Consultant Tags architecture 3 years ago