Hovedoppgave LKSK II/2 Modul VI

Transkript

1 Hovedoppgave LKSK II/2 Modul VI En systemarkitekts bidrag i komplekse utviklingsprosjekter av kadett Ketil Skogheim Kull 54 Luftkrigsskolen

2 1 1 Innledning BAKGRUNN PROBLEMSTILLING OG AVGRENSNING OPERASJONALISERING Metode Validitet Reliabilitet Teori SYSTEMARKITEKTUR/ SYSTEMARKITEKTEN IMAS Prosjektets mål NYTT SJØMÅLSMISSIL Prosjektets mål Gjennomgang av IMAS prosjektets faser INNLEDNING FASE 1 IDENTIFISERING AV KUNDE OG SYSTEMKRAV FASE 2 VALG AV SYSTEM FASE 3 UTVIKLINGSPROSESSEN FASE 4 ANSKAFFELSE OG INTEGRERING FASE 5 TESTING OG EVALUERING Gjennomgang av NSM prosjektets faser INNLEDNING FASE 1 IDENTIFISERING AV KUNDE OG SYSTEMKRAV FASE 2 VALG AV SYSTEM FASE 3 UTVIKLINGSPROSESSEN FASE 4 ANSKAFFELSE OG INTEGRERING FASE 5 TESTING OG EVALUERING Sammenlikning av Systemarkitektrollen i IMAS og NSM prosjektene GRUNNLAG SAMMENLIKNING FASE 1 - IDENTIFISERING AV KUNDE OG SYSTEMKRAV SAMMENLIKNING FASE 2 VALG AV SYSTEM SAMMENLIKNING FASE 3 UTVIKLINGSPROSESSEN SAMMENLIKNING FASE 4 ANSKAFFELSE OG INTEGRERING SAMMENLIKNING FASE 5 TESTING OG EVALUERING GENERELLE BETRAKTNINGER RUNDT SYSTEMARKITEKTROLLEN Sammendrag/ konklusjon Bibliografi...53 Vedleggsoversikt Vedlegg A: Spørreskjema brukt under intervjuer Vedlegg B: Modellen "The SIMILAR process" unba/\\kuhfs0001\data$\lksk\lksk bibliotek\bibliotek\fordypningsoppgaver\hoved05\skogheim\hovedoppgaven.doc

3 2 1 Innledning 1.1 Bakgrunn I dagens samfunn blir vi stadig mer avhengig av teknologiske hjelpemidler. Utviklingen av ny teknologi vil ingen ende ta, og nye produkter blir hele tiden sendt ut på markedet. En del mennesker, særlig de eldre, klarer ikke henge med i denne raske utviklingen. De siste ti-årene har denne teknologien ført til større og mindre endringer i samfunnet vårt, selv om få tenker på dette til vanlig. Tenk deg verden i dag uten pc er, trådløse nettverk, Internett eller mobiltelefon. Ingenting av dette var utbredt for år siden. I dag er vi, i store deler av verden, mer eller mindre avhengig av denne teknologien, og et fravær av disse tingene ville ført til fullt kaos. Dette har medført utfordringer på mange ulike plan i samfunnet. En av de er i forbindelse med utvikling av nye komplekse tekniske systemer. Fordi den teknologiske utviklingen går så raskt frem, har krav til at tids- og kostnadsrammer blir overholdt, samtidig som produktene inneholder stadig ny og bedre teknologi, blitt stadig strengere. Mye teknologi har samtidig blitt så kompleks at det har blitt vanskelig å beholde oversikten underveis i utviklingsfasen. Nye utfordringer krever ofte ny teknologi, og da helst så raskt som mulig. Disse nye utfordringene har forplantet seg også til Forsvaret, spesielt når det gjelder innkjøp og/eller utvikling av nye plattformer, våpen, eller IT-systemer. Et annet område hvor slike utfordringer kan bli aktuelle er på veien mot et nettverksbasert forsvar (NBF), et konsept som Forsvaret skal satse på fremover. 1 En del av verdens mange utviklingsprosjekter, ender med katastrofe. Enten når de ikke sine fastsatte mål, de overskrider tid og/eller kostnadsrammene eller ender med systemer som ikke er i stand til å løse det de er blitt utviklet for. 2 Prosjektene i Forsvaret er således intet unntak. En viktig årsak til slike tilstander er ofte at totaliteten og helhetsbildet ikke har vært ivaretatt. Kompleksiteten til systemene blir for mye og holde styr på og alvorlige feil blir gjort under utviklingsprosessen. Dette kombinert med harde tidsfrister for å få produktene ferdig gjør ofte situasjonen enda verre. Både det sivile næringsliv og Forsvaret har begynt å ta disse nye utfordringene inn over seg og en ny og spennende retning, systemarkitektur, er i frammarsj. Den skal blant annet bidra til å få bedre oversikt over denne type prosjekter og sikre at man får det produktet en har behov for til riktig pris og til riktig tid. Systemarkitektur fokuserer mye på prosessen som leder frem til hva som faktisk skal utvikles. Den skal også se helhetlig på utviklingsprosessen samt integreringen 1 Foredrag av Bjørn Ian Bednar, FFI, systemarkitektur, ved Luftkrigsskolen, 29 sept Ibid

4 3 av systemet og hele tiden kontrollere at det som utvikles er i samsvar med det kunden har behov for, innenfor de rammene som er fastsatt. Det er gjerne en person; systemarkitekten, som har en nøkkelrolle for å sikre at dette blir oppnådd. Et moderne, fleksibelt og ikke minst, effektivt forsvar vil være avhengig av stadig nye anskaffelser av komplekse, tekniske systemer. Flere anskaffelsesprosjekter blir gjennomført hvert år, men så langt uten en definert systemarkitektrolle (sa-rolle). 1.2 Problemstilling og avgrensning Denne oppgaven skal fokusere på systemarkitektrollen og søke å gi svar på følgende problemstilling: Hva kan en systemarkitekt bidra med i komplekse utviklingsprosjekter i Forsvaret? Bidrag eller nytteverdi i denne sammenheng kan være flere ting; det kan dreie seg om rene økonomiske gevinster. Det kan være innsparinger i form av raskere og mer effektiv utvikling/ innkjøp av et system, eller at man rett og slett får utbytte i form av et bedre og mer effektivt system. Nytteverdier kan også oppnås ved å se sammenhenger mellom ulike prosjekter og skape synergieffekter. Enkelte kilder definerer systemarkitektur som prosessen som leder fram til hva som skal utvikles, mens hvordan denne systemarkitekturen skal realiseres kalles systems engineering. 3 Systemarkitekten lager oppskriften mens systemingeniøren realiserer i henhold til denne. Det kan finnes mange ulike tekniske løsninger. Systemarkitekten må derfor overvåke og følge opp at oppskriften følges og at kunde/systemkrav blir oppfylt. Denne oppgaven skal ta for seg begge disse aspektene, og se på både utvikling og realisering. Når begrepet systemarkitektur blir brukt i oppgaven, kan det i enkelte tilfeller derfor også være snakk om system engineering Oppgaven kommer ikke til å skille disse begrepene, men se på hele prosessen under ett. Det samme vil være gjeldende for systemarkitekten/systemingeniøren. Det forutsettes derfor at systemarkitekten er involvert i hele systemutviklingsprosessen. Grunnen til dette er ganske enkelt at systemarkitektur og system engineering henger veldig tett sammen og er vanskelig å skille fra hverandre. Begge aspektene må ivaretas i større prosjekter og de sklir ofte over i hverandre. Mark Maier og Eberhardt Rechtin skiller de ved at system engineering jobber med det som er målbart og bruker analytiske verktøy basert på matematikk og forskning. System engineering er basert på deduktive prosesser (fra teori til erfaring). 3 Foredrag Bednar, FFI, Systemarkitektur, 29 sept 2004

5 4 Systemarkitektur dreier seg mer om ting som ikke kan måles, bruker ikke - kvantitative verktøy og retningslinjer basert på praktiske erfaringer. 4 Mye av dokumentasjonen i Nytt Sjømåls Missil (NSM) prosjektet er i dag gradert. Denne dokumentasjonen har vært vanskelig å få tak i, samtidig som det medfører en del vanskeligheter å ta i bruk gradert materiale. Oppgaven er derfor begrenset til ikke å inneholde noe som er gradert. Til tross for graderingen har det lyktes å fremskaffe de ønskelige data som trengs for å kunne svare på problemstillingen. Oppgaven har derfor ikke blitt skadelidende som en følge av at mye av materiale i NSM-prosjektet er graderte dokumenter. 1.3 Operasjonalisering Følgende fremgangsmåte er valgt for å kunne gi svar på oppgavens problemstilling: Teorien skal innledningsvis beskrive systemarkitektur som fagområde. Den vil videre fokusere på systemarkitektens roller og ansvarsområder. Hensikten er å gi leseren en grunnleggende forståelse for systemarkitektur som fagområde, samt gi et bilde av hvilke arbeidsoppgaver en systemarkitekt har ansvar for. Teorien skal også definere og beskrive en del viktige begreper som blir brukt innen fagområdet. Systemarkitektur er til dels komplisert og avansert. Fagområdet er derfor beskrevet ganske utfyllende med hovedfokus på generell teori som vil være relevant i de fleste større komplekse utviklingsprosjekter. Denne teorien brukes som et grunnlag senere i drøftingen, for å vurdere i hvilken grad SA-rollen har blitt ivaretatt. Hovedfokus vil være på SArollen innad i Forsvaret i de to prosjektene. De to andre underkapitlene beskriver henholdsvis Integrert Materiell Administrasjons System (IMAS)- og Nytt Sjømåls Missil (NSM) prosjektene, og skal gi leseren bakgrunnsinformasjon om disse. Drøftingen (analysen) skal se på de to prosjektene, fra start til slutt. Kapittel 4 og 5 vil i hovedsak presentere funn og rådata fra intervjuer, samtaler og gjennomgått dokumentasjon. Disse kapitlene danner således grunnlaget for å kunne vurdere relevansen og dekningen av SArollen innad i prosjektene. Dette gjøres gjennom å dele opp prosjektløpet i flere faser. I hver fase vil det bli fokusert på en del kritiske faktorer/milepæler som en systemarkitekt har ansvaret for å følge opp. For å få frem resultater fra disse fasene er det utarbeidet et spørreskjema med relevante spørsmål knyttet til de fem fasene. A Dette spørreskjemaet har vært grunnlaget for alle intervjuene som har blitt gjennomført. Intervjuobjektene har fått prate fritt i størst mulig grad, for å sikre et bredt og utdypende rådatamateriale. De fem fasene er utledet fra en modell; the 4 Mark Maier & Eberhardt Rechtin, the art of systems architecting, 2002, preface 5 Ketil Skogheim, Semesteroppgave 2004, LKSK, Roller og krav til en systemarkitekt, side 11

6 5 similar process B, som beskriver de viktigste områdene/fasene en systemarkitekt må fokusere på i et utviklingsprosjekt. 5 Første bokstav i hver boks utgjør ordet SIMILAR. The SIMILAR Process Customer Needs State the Problem Investigate Alternatives Model the System Integrate Launch the System Assess Performance Output Re-evaluate Re-evaluate Re-evaluate Re-evaluate Re-evaluate Re-evaluate Figur 1, "The SIMILAR process" Drøftingen skal videre sammenligne de to prosjektene, og se på forskjeller og likheter i systemarkitektens rolle. Disse vil utredes og knyttes til teorien, og vil gi svar på hva som har vært bra og hva som har manglet eller feilet med tanke på SA-rollen. Her vil det også drøftes hva systemarkitekten kunne ha bidratt med. Fasene fra kapittel 4 og 5 vil bli brukt også i disse sammenlikningene. Til slutt i drøftingen vil det komme en del generelle betraktninger rundt systemarkitektrollen med henblikk på problemstillingen. Prosjektets natur vil kunne være en faktor som påvirker rollen underveis. To prosjekter kan være svært forskjellige på ulike måter, dette vil i stor grad kunne påvirke systemarkitektrollen.

7 6 2 Metode Denne oppgaven vil være et videre arbeid av semesteroppgaven; Roller og krav til en systemarkitekt som ble skrevet som et grunnlagsdokument for denne hovedoppgaven, høsten Oppgaven baserer seg på relevant teori/litteratur om systemarkitektur, fra både bøker og Internett. Litteratur og linker på Internett er i stor grad anbefalt av professor Bent Erik Bakken og forskningssjef Ian Bjørn Bednar ved Forsvarets Forsknings Institutt (FFI), som begge har utdanning og erfaring innen systemarkitektur, og som jobber med dette til daglig. Utdanningen er gjennomført ved Massachusetts Institute of Technology (MIT) i USA. For å kartlegge systemarkitektens rolle i de to prosjektene har det blitt gjennomført dybdeintervjuer med prosjektlederne, systemarkitekten eller personell med innsikt i denne rollen. Alle intervjuer har vært individuelle, åpne intervjuer, bortsett fra ett som har vært ett gruppeintervju med to personer. Selv om et spørreskjema har vært utgangspunktet for intervjuene har intervjuobjektene fått prate fritt i størst mulig grad. Bruken av spørreskjemaet har egentlig vært en slags forsikring om at tilfredsstillende data rundt SA-rollen har blitt samlet inn. Ett intervju har hatt form som et personlig intervju, de resterende har vært telefonintervju hvor samtalene har blitt tatt opp. Dette har vært godkjent på forhånd. Det har blitt gjennomført samtaler med alle intervjuobjektene på forhånd hvor de har blitt opplyst om oppgavens mål og hensikt, min bakgrunn for å skrive om dette emnet og hvorfor jeg ønsker å intervjue nettopp dem. Hovedårsaken til at telefonintervjuer har blitt valgt er at intervjuobjektene har hatt stor geografisk spredning. Det har kun vært ressurser til å foreta en til to reiser i forbindelse med skriving av hovedoppgaven, noe som har ført til at det ikke har vært mulig å kun foreta personlige intervjuer. Denne type intervju blir ofte brukt i forbindelse med en kvalitativ tilnærming, som denne oppgaven har. 6 Tilnærmingen baserer seg på funn gjort gjennom observasjon, deltakelse, analyse av skriftlig materiale og intervju. Metoden kjennetegnes ofte ved at den går i dybden på et utvalgt område. 7 Den er hensiktsmessig å bruke når relativt få enheter undersøkes, når en er interessert i hva det enkelte individ sier og når en er interessert i hvordan den enkelte fortolker og legger mening i et spesielt fenomen. 8 Dette gjelder for denne oppgaven da det er begrenset med personell som kjenner til systemarkitektrollen i disse prosjektene. 6 Dag Ingvar Jacobsen, Hvordan gjennomføre undersøkelser?, 2000, side 46 7 Georg Mattingsdal, Prosjektoppgave ved BI, Prosjekt IMAS ved Luftforsvarets Forsyningskommando, side 8 8 Ibid, side 13

8 7 I tillegg vil litteraturstudie av systemarkitektur som fagområde inngå i oppgaven i teoridelen. Dokumentundersøkelse fra de to prosjektene har også bli brukt i den grad den har vært tilgjengelig. IMAS-prosjektets dokumentasjon har blitt gjennomgått ved Kjeller i tidsrommet 7 10 mars 05. All denne dokumentasjon er ugradert. Dokumentasjon brukt i forbindelse med NSM- prosjektet er i hovedsak mottatt per og er også ugradert. Datainnsamlingen er basert på deduktiv strategi, eller fra teori til empiri. Den baserer seg på å først skape noen forventninger om hvordan virkeligheten ser ut, for deretter å samle empiri eller erfaringer og se om disse stemmer med virkeligheten Validitet Validitet refererer til datamaterialets gyldighet i forhold til problemstillingen som skal belyses. 9 Det fins flere typer validitet og selve begrepet er mindre presist og mer komplekst enn for eksempel reliabilitetsvurderinger. Det eksisterer ingen presise mål på validitet, og den lar seg heller ikke måle eksakt. 10 I forbindelse med kvalitative studier er det særlig tre typer validitet som nevnes; kompetansevaliditet, kommunikativ validitet og pragmatisk validitet. Kompetansevaliditet går på forskerens kompetanse for innsamling av kvalitative data på det aktuelle forskningsfeltet. I denne oppgaven har teoretisk kunnskap som har blitt tilegnet ved Luftkrigsskolen blitt brukt, samt erfaring fra å skrive og samle inn data fra tidligere oppgaver og studier, både militære og sivile. Kommunikativ validitet bygger på dialog mellom forsker og andre om hvorvidt materialet er godt og treffende i forhold til problemstillingen. Dette har blitt ivaretatt gjennom dialog og tilbakemeldinger fra professor Bent Erik Bakken ved FFI som har høy kompetanse og erfaring innen systemarkitektur. Han er i dag prosjektleder for et prosjekt som ser på systemarkitektrollen, og dens relevans for Forsvaret. Materialet og spørreskjema har også blitt evaluert av intervjuobjektene, samt Karl Selanger ved Luftkrigsskolen som har lang erfaring på dette området fra forskning og utvikling. Pragmatisk validitet viser i hvilken grad datamaterialet og resultatene i oppgaven danner grunnlag for bestemte handlinger. Validiteten er høy dersom oppgaven utgjør et godt handlingsgrunnlag. For eksempel kan en studie av arbeidsmiljøet i en bedrift sies å ha høy pragmatisk validitet dersom studien danner grunnlag for forbedringer av miljømessige forhold i 9 Sigmund Grønmo, Samfunnsvitenskapelige metoder, 2004, side Ibid, side 237

9 8 bedriften. Resultatene i kapittel 6 og 7 vil gi en pekepinn på om denne validiteten er god eller ikke i oppgaven. 11 To prestisjetunge og omfattende prosjekter har blitt valgt. Selv om prosjektene på mange måter er ulike har de også mange fellestrekk. De har gått over flere år, har store budsjetter og er begge utviklingsprosjekter hvor utviklerne er eksterne selskaper. NSM-prosjektet pågår den dag i dag, mens IMAS-prosjektet ble terminert i år 2000, noe som sikrer at prosjektene ikke er gamle og urelevante. I begge prosjektene bør systemarkitektrollen være svært synlig, enten gjennom tilstedeværelse eller i form av fravær. En studie av prosjektene vil også peke på hvor godt systemarkitektrollen har blitt ivaretatt. De bør også kunne si noe om den generelle bruken av systemarkitektrollen i Forsvaret i dag, fordi de på mange måter er typiske utviklingsprosjekter som vil gå igjen i fremtiden. IMAS-prosjektet var et prosjekt hvor en stor og omfattende IT-applikasjon, som berørte veldig mange i Forsvaret, ble utviklet og innført i organisasjonen. Formålet var blant annet å redusere driftskostnader, samt å styre materiell mer effektivt og sikkert. Med dagens raske teknologiske utvikling vil en innføring av nye it- applikasjoner være aktuelt med få års mellomrom. De oppgavene som en systemarkitekt har ansvaret for i slike prosjekter representerer muligheter for store gevinster/besparelser. Når det gjelder NSM-prosjektet så gjelder mye av det samme der. Prosjektet går ut på å utvikle og kjøpe inn et nytt våpensystem, som vil kunne brukes på flere våpenplattformer, både maritime og etter hvert i luften. Innkjøp av nye våpensystemer, store og små, er noe som skjer kontinuerlig i Forsvaret, og i forbindelse med nyutvikling av teknologi er systemarkitektrollen svært relevant. Et viktig aspekt her vil også være å vurdere nyutvikling kontra eksisterende systemer som allerede er i operativ bruk Reliabilitet Reliabilitet viser hvor pålitelig et datamateriale er og kan defineres som: graden av samsvar mellom ulike innsamlinger av data om samme fenomen basert på samme undersøkelsesopplegg. 12 I og med at oppgaven baserer seg på kvalitativ metode og dybdeintervjuer vil resultatene i kapittel 4, 5 og 6 være veldig avhengig av få intervjuer med relevant personell. Disse personene bør ha inngående kjennskap til prosjektet og systemarkitektrollen. Oppgaven vil derfor være 11 Grønmo, Samfunnsvitenskapelige metoder, 2004, side Ibid, side 222

10 9 avhengig av ærlige og gode svar, noe som kan være en svakhet. NSM-prosjektet er fortsatt ikke terminert og det vil derfor være nærliggende å tro at involverte i prosjektet ikke ønsker å sette seg selv eller prosjektet i et dårlig lys. Dette medfører en viss risiko med tanke på reliabiliteten. For å minske denne risikoen ble det gjennomført intervjuer med personell fra både Forsvaret og de som utvikler systemene IFS (Industrial and Financial Systems) og KDA (Kongsberg Defence & Aerospace). Riktige intervjuobjekter ble sikret gjennom å lete etter personer i SA-rollen eller med tilknytning til denne, samt prosjektledere, både i Forsvaret og blant de som utviklet systemene. Samtaler med personer i begge prosjektene har hjulpet til med å navngi og finne de mest relevante intervjuobjektene. Intervjuobjektene selv har også navngitt hverandre og alle kjenner til hverandre innad i prosjektene. Dette bør gi et godt grunnlag for å finne avvik i datamaterialet. En sammenligning ville avsløre om det er store avvik mellom partene i oppfattelsen av systemarkitektrollen i prosjektene. I tillegg ble tilgjengelig dokumentasjon fra prosjektene studert og veid opp i mot intervjuene for å kvalitetssikre det som ble sagt. Det har også blitt gjennomført uformelle telefonsamtaler med personell som jobber opp mot eller innad i prosjektene. Ved å gå gjennom alt dette materialet og sammenligne det, ser man tendenser og om ulike kilder samsvarer med hverandre. Intervjuobjektene blir nærmere beskrevet og presentert innledningsvis i kapittel 4 og 5, som tar for seg funnene i prosjektene og i hovedsak baserer seg på intervjuer. Ut i fra resultatene som kommer frem i oppgaven virker det som om både reliabiliteten og validiteten til oppgaven er god.

11 10 3 Teori 3.1 Systemarkitektur/ systemarkitekten Systemarkitektur har opprinnelig sitt utspring fra marinarkitektur og sivilarkitektur (bygningsarkitektur), med røtter helt tilbake til oldtidens Egypt, Hellas og romerne. 13 Det representerer den mest abstrakte høynivåfunksjonen i dagens utviklingsprosjekter. 14 Hovedforskjellen på den gangs arkitektur og dagens er den voldsomme kompleksiteten og teknologiske kapasiteten som eksisterer i dagens systemer. Dagens systemarkitekter må i tillegg sette seg inn i- og forstå nyutviklede systemer med ulike egenskaper. 15 FFI beskriver systemarkitektur som: Kunsten og vitenskapen knyttet til utviklingen av komplekse systemer, 16 noe som gir et godt bilde på hva systemarkitektur dreier seg om. Den skal sørge for en overordnet utforming av systemet, og gi svar på hva som skal utvikles og ikke hvordan. Systemarkitektur som fagområde har blitt tvunget frem av stadig økende krav til utvikling av bedre systemer med lave kostnader og korte tidsfrister. Her må det også nevnes at vedlikeholdskostnader samt kostnader knyttet til utfasing er svært viktige. Disse kan i mange tilfeller bli høyere enn selve anskaffelseskostnadene, når man ser på hele livsløpet til et system. Samtidig blir ny teknologi utviklet stadig raskere, noe som kan medføre at et system blir avleggs innen det har blitt ferdigutviklet. Nye utfordringer, både innen organisasjoner, stater og bedrifter krever ny teknologi for å kunne løse disse effektivt. 17 Systemarkitektur skal bidra til at utvikling skjer innefor gitt tidsramme og budsjett, og med et sluttresultat som har den etterspurte ytelse. 18 Det er viktig å få bekreftet at den nye løsningen faktisk bidrar til å løse disse nye utfordringene. Et nytt system bør gi en økt gevinst. I verste fall skaper det frustrasjon og motstand mot å ta det i bruk, eller det gir svar på andre ting en det er ment å gjøre. Prosjektledelse og systemarkitektur er to ulike retninger. Disse begrepene bør derfor ikke brukes om hverandre. Prosjektledelse handler hovedsakelig om å gjennomføre utviklingen av systemet i henhold til systemarkitektens komposisjon. Her bør systemarkitekten overvåke utviklingen og komme med innspill ved behov. I mindre prosjekter vil ofte systemarkitekten og prosjektlederen være en og samme person. 19 Systemarkitektur skal gi grunnlag for å utarbeide konseptuelle 13 Maier & Rechtin, the art of systems architecting, 2002, preface 14 John-Mikal Størdal, Systemarkitektur, kunsten å utvikle komplekse tekniske systemer, side 1 15 Maier & Rechtin, the art of systems architecting, 2002, preface 16 Foredrag, Bednar, FFI, Systemarkitektur, 29 sept Ibid 18 Ibid 19 Størdal, Systemarkitektur, kunsten å utvikle komplekse tekniske systemer, side 1

12 11 løsninger og spesifikasjoner og bidrar blant annet til at materiellanskaffelser foregår på en systematisk og helhetlig måte. 20 En annen definisjon på systemarkitektur er hentet fra the International Council on Systems Engineering: The arrangement of elements and subsystems and the allocation of functions to them to meet system requirements. 21 Å dele opp elementer og undersystemer og fordele funksjoner på disse for å møte systemkrav, medfører ofte store utfordringer for en systemarkitekt. Han må ha teknisk innsikt til å forstå hva en endring på et element gjør med hele systemet. Jo større og mer komplekst et system blir jo mer uoversiktlig blir det som regel. Et stort, komplekst system vil som regel ha flere elementer og undersystemer enn et lite system, selv om det her kan finnes unntak. Utfordringene da blir å få kompleksiteten ned på et nivå hvor systemarkitekten igjen har oversikt og kontroll. Dette kan gjøres på flere måter. FFI definerer kompleksitet på denne måten: Systemer med essensiell kompleksitet som er høyere enn menneskelig fatteevne er ansett som komplekst i denne sammenheng. Systemer innefor menneskelig fatteevne er ansett som enkle. (Mennesket kan typisk forstå inntil 50 ting på en gang). 22 Når vi prater om systemer som en systemarkitekt er med på å utvikle er det som regel komplekse systemer det er snakk om. Hvordan skal så en person klare å holde oversikt over 100, 200 eller enda flere elementer? Dette er det flere løsninger på. Det fins blant annet ulike dataverktøy/programmer designet for akkurat dette. En systemarkitekt kan bruke de til å hjelpe seg med å få kompleksiteten ned på et nivå som er mulig å fatte for et menneske. Han kan også slå sammen flere av disse uten at det går på bekostning av systemet, gjennom systemering og riktig design. Særlig innen IT-arkitektur er det i dag mange slike verktøy/programmer som gjør dette for deg. Ulike modeller kan også være med på å bryte ned kompleksiteten og gjøre ting mer forståelig: 1. Dekomposisjon; Baserer seg på å dekomponere systemets oppbygning lagvis, for å få en bedre oversikt over de ulike deler og funksjoner. 23 Eksempler på lag kan være; system, delsystem, undersystem, modul, komponent eller del. 2. Abstraksjon: en modell som består av en fysisk del og en hendelsesbasert del, hvor den fysiske delen inkluderer abstraksjoner som utvikles for software oppgaver, objekter, rutiner og grensesnitt Ibid 21 INCOSE SE Handbook, Version 2a 22 Foredrag Bednar, FFI, systemarkitektur, 29 sept 2004

13 12 3. Hierarkier; En modell som bryter ned systemet i flere nivåer, ofte to eller tre, disse nivåene består igjen av flere interne deler, som igjen kan ha flere nivåer. Hvert hovednivå representerer ett spesielt område eller oppgave, for eksempel dataflyten i systemet. 25 En annen mulighet kan være å fordele oppgaver i en mindre gruppe hvor alle jobber med systemarkitektur. På den måten kan en fordele ansvarsområder slik at den enkeltes kompetanse blir bedre utnyttet. Dette vil igjen medføre fare for at helhetsbildet forsvinner og at ingen sitter med den totale oversikten lengre. Det kan også medføre støy og uenighet, både innad i gruppen og ut mot eksterne samarbeidspartnere. Vanligvis utøves systemarkitektur av så få som mulig. 26 I dag skiller man ofte mellom systemarkitektur og system engineering. Førstnevnte tar for seg fasen fra idé til konsept (komposisjon). Den skal gi overordnede føringer på hvordan konseptet skal realiseres (ved blant annet detaljering av grensesnitt og hovedelementer), samt overvåke realiseringen av konseptet. Systemingeniøren (system engineering) skal videreutvikle konseptet til et design og detaljere konseptet. Han er teknisk ansvarlig for realisering av konseptet. En slik fordeling bidrar til at rollefordeling og arbeidsoppgavene blir enklere enn om en person må ta for seg hele området. I dag blir ulike løsninger brukt, ofte avhengig av størrelsen og kompleksitet på prosjekt. Samarbeidet mellom disse vil være tett og systemarkitekten bør være involvert hele veien, for å sikre kontinuitet og beholde helhetsbildet. Dette vil også redusere sannsynligheten for å gå i fallgruver, som det er mange av i komplekse utviklingsprosjekter. Et annet viktig begrep i tilknytning til systemarkitektur er systemer. Flere ulike systemalternativer må vurderes. Målet er å finne det systemet som best tilfredsstiller krav/behov til riktige kostnader. En definisjon på et teknisk system er: An integrated set of elements that accomplish a defined objective. These elements include products (hardware, software, firmware), processes, people, information, techniques, facilities, services, and other support elements. 27 For en systemarkitekt vil det være viktig å kjenne godt til alle aspektene ved et system og ha en god systemforståelse. Han må også ha teknisk forståelse, slik at han skjønner hvordan ulike tekniske løsninger påvirker helheten for et system. Dette er et krevende område, særlig fordi et 23 Maier & Rechtin, the art of systems architecting, 2002, s 157 og Maier & Rechtin, the art of systems architecting, 2002, s Maier & Rechtin, the art of systems architecting, 2002, s , figure 10.1 og Fra internettsiden, side 4 27 INCOSE SE Handbook, Version 2a, juni 2004

14 13 system kan inneholde så mange ulike elementer. Alle disse elementene må vurderes og veies opp i mot hverandre, for å kunne kvalitetssikre systemets funksjon og ytelse. Bednar ved FFI sier dette om et system: Består av deler, er mer enn summen av de enkelte bidrag, er en del av et større system, har klare grenser mot omgivelsene, eksempelvis en blyant, hus, båt, fotballag, vann, foretak osv. 28 Et system er ofte en del av et større system som igjen er en del av et enda større system osv. Dette kan vi se eksempler på også i naturen i fra mikroorganismer til verdensrommets oppbygning, det fins alltid noe som er større eller mindre og forskning avdekker stadig nye oppdagelser rundt dette. Ser vi for eksempel på IT-nettverkene i Forsvaret består disse av mange ulike nett, hvor noen er koblet sammen og andre ikke. Deler av et nett kan være knyttet sammen til et hovednett, mens andre deler ikke er det. De ulike bransjene i Luftforsvaret har ofte egne nett og systemer som de andre bransjene ikke har adgang til, noe som hindrer informasjonsflyt og gjør det vanskelig for alle å få en helhetlig og overordnet oversikt og dermed jobbe mot samme mål. Dette gjelder også de ulike forsvarsgrener. En innføring av NBF, hvor meningen er at alle skal være på samme nett og utveksle informasjon seg i mellom, vil kunne bedre denne situasjonen, selv om veien dit fortsatt er lang å gå. Noe som er viktig å merke seg er at også mennesker er en del av et system. 29 Dette blir ofte lite vektlagt og kan få uheldige konsekvenser. Det er tross alt mennesker som skal bruke systemene, de må derfor være tilrettelagt for dette gjennom god funksjonalitet og enkle brukergrensesnitt. Grensesnittene skal gi synergieffekter og være med på å skape nye verdier. De bør i størst mulig grad være enkle, rene og skjule kompleksitet. 30 Andre utfordringer er kompatibilitet og å få systemene til å snakke sammen, eller med andre ord; definere hvilke arbeidsoppgaver systemet skal løse, hvem det skal jobbe opp i mot og hvordan det skal gjøres. Roller og krav som en systemarkitekt må fylle er ofte mange og krevende. De kan variere fra prosjekt til prosjekt og etter hvem som definerer dem. Innen faglitteraturen og på internettsider som omhandler systemarkitektur er det mange ulike meninger og definisjoner, likevel er det en del fellestrekk som går igjen: I følge International Council on System Engineering (INCOSE) medlem Brian Mar er de fleste systemarkitekter enige om følgende kjernekonsepter: Forstå hele problemet før du prøver å løse det 28 Foredrag Bednar, FFI systemarkitektur, 29 sept Ibid 30 Ibid 31 Fra internettsiden 7 apr 2004

15 14 2. Oversett problemet til målbare krav 3. Utforsk alle mulige alternativer før du velger en løsning 4. Pass på å se på systemets totale livssyklus. Et fødsel til død konsept inkluderer vedlikehold, utbyttinger og avvikling. Dersom disse ikke blir tatt hensyn til i de andre oppgavene, vil livssyklus - kostnadene fort bli mye høyere enn beregnet. 5. Test det totale systemet før levering 6. Dokumenter alt Dette er kjerneområder som er allmenngyldige for systemutvikling generelt og som vil stille mange ulike krav til en systemarkitekt. Han må sette seg inn i og forstå hele problemet med en ofte svært begrenset informasjon som eksisterer tidlig i et prosjekt. Å definere målbare krav er viktig for å kunne måle progresjon og sjekke at utviklingen går rett vei hele tiden. De vil kunne fungere som referansepunkt underveis, og er verdifulle i en stadig re-evalueringsprosess. Punkt tre vil blant annet stille krav til god teknisk innsikt, helhetlig tenking, evne til å håndtere en stor mengde informasjon og kunne fokusere på det essensielle. De tre første punktene krever en stor innsats på et tidlig stadium. En av de største feilene som blir gjort innen systemutvikling er nettopp for liten innsats tidlig. De fleste alvorlige feil blir gjort da, fordi informasjonsmengden er liten. Ofte blir ikke slike feil oppdaget før mye senere i prosessen, noe som krever mye ressurser å få rettet opp igjen. Her kan systemarkitekten legge inn såkalte tilbakekoblinger, som gir muligheter til å gå tilbake og rette opp feil raskt, uten at andre ting blir påvirket. Tilbakekoblinger er svært viktig for å unngå at feil som oppdages sent i utviklingsfasen får fatale konsekvenser. En systemarkitekt er ikke en generalist, men en spesialist i å forenkle kompleksitet, løse opp tvetydighet og fokusere kreativitet. 32 Hans kanskje viktigste roller (arbeidsområder) kan oppsummeres slik: 1. Han skal definere grensene til det lukkede systemet, som utgjør systemets design og implementeringsprosessen. Dette medfører blant annet å tolke inkorporert strategi, markedsstrategier og konkurrerende analyser. Han må lytte til kundene og deres behov, og tolke innflytelse fra ulike regulativer. Dette er et viktig område som må tas hensyn til. Miljøkrav kan for eksempel sette en stopper for 32 Fra internettsiden, side 4, 4 nov 04

16 15 en systemutvikling dersom disse ikke har blitt tatt hensyn til tidlig i prosessen. Forandringer for å etterkomme kravene kan fort bli både dyre og ta mye tid. 2. Systemarkitekten skal utvikle konseptet for systemet; han skal foreslå og utvikle ulike løsninger, utføre avveiinger og optimalisering på høyeste nivå. Han må også forutse mulige feiltilstander/mangler og legge planer for å dempe eller helbrede disse. Dette vil foregå tidlig i utviklingsprosessen, før prototyper på systemet er bygd slik at tester kan utføres. Planer for feilretting må dermed produseres på et begrenset og teoretisk grunnlag. Dette stiller krav til god teknisk innsikt, en god oversikt over hvordan systemet fungerer og hvordan alle delene kommuniserer med hverandre. Identifisering av mulige flaskehalser vil også kunne være med på å hindre feil og gi systemet bedre utholdenhet. For ulike del- og totalløsninger kan kost kontra ytelse avveiinger også være noe han må forholde seg til. 3. En tredje rolle (ansvarsområde) er å fordele funksjonalitet og definere grensesnitt og abstraksjoner. Form og funksjoner må dekomponeres og funksjonalitet fordeles til ulike elementer i systemet. Grensesnitt mellom undersystemene må konfigureres og konfigureres med tanke på; fleksibilitet eller optimalisering (ytelse), modulisering eller plattform og selvutviklet eller innkjøpt design og produksjon. 33 Systemarkitektur er en teknisk rettet disiplin hvor det er viktig å skille mellom det å bidra til å definere systemet og hvordan systemet skal bygges opp og fungere i praksis. Systemarkitekten skal i en første fase særlig fokusere på hva systemet skal gjøre og hvor godt det skal gjøre det. Hvordan løsningen konkret skal fungere er egentlig mindre vesentlig og er problemområdet til system-utviklere som utvikler systemet fysisk. 34 Nye teknologiske løsninger er også noe en systemarkitekt må sette seg inn i for å kunne vurdere de opp i mot hverandre og kunne anbefale et bestemt system for en kunde. 35 Viktige faktorer her er å finne en riktig balanse mellom å være lydhør for hva kunden tror han/hun vil ha, og være opplysende med henhold til hva kunden burde ha definert som sitt behov. En systemarkitekt vil typisk analysere behovet og se det i lys av mulige løsninger. På den måten kan han påpeke at kunden egentlig ikke behøver et fly for å kunne forflytte seg raskt, men vil se på behovet; rask forflytning, og komme med ulike alternativer som vil dekke dette behovet. Det er kanskje ikke et fly som er beste løsning, kanskje et helikopter, en båt eller en snøscooter 33 Hentet fra internettsiden 4 nov Hentet fra internettsiden 7 nov Foredrag Bednar, FFI, systemarkitektur, 29 sept 2004

17 16 kan være en bedre løsning. Det ideelle i så måte ville være å få kunden til å skjønne at det fins flere alternativer som kan dekke hans behov og ikke kun ett system. 36 Det fins egentlig ingen fasitsvar på hva som kreves av en dyktig systemarkitekt, men det er ofte ønskelig med erfaring fra utvikling av komplekse tekniske systemer, en solid matematisk bakgrunn kombinert med dybdeforståelse av en eller flere av de involverte teknologier. Han bør ha interesse og kunnskap om helhetstenkning og evne til å kunne kombinere teknisk forståelse med kjennskap til alle de ikke tekniske sider ved systemutviklingen. Det er også svært viktig å være objektiv. 37 Dette kan være veldig vanskelig med så mange ulike interessenter, som vil prøve å påvirke løsningen. Disse utfordringene stiller også høye krav til tverrfaglighet. Mye av det som kreves av en systemarkitekt vil nok være knyttet til personlige egenskaper, og er ikke nødvendigvis noe som kan læres. Områder som å kunne håndtere kompleksitet og store mengder informasjon, se sammenhenger og beholde oversikten, vil nok like mye være et medfødt talent og et resultat av solid erfaring. Disse kravene til tverrfaglighet og personlige egenskaper gjør det vanskelig å finne dyktige systemarkitekter. Mange mennesker er svært dyktige innen et spesielt fagfelt, men kan ha store mangler på andre områder. En dyktig systemarkitekt må inneha ulike roller etter hvem han har med å gjøre. Han må kunne kommunisere med både kunder, leverandører, produsenter og reguleringsmyndigheter eksternt. Internt må han blant annet forholde seg til systemingeniøren, teknikere, utviklere og prosjektleder. For at dette skal være mulig må også samarbeidspartnerne forstå og anerkjenne systemarkitektens rolle. Uten denne anerkjennelsen vil det bli svært vanskelig å kunne utføre en god jobb og ivareta egen integritet. Systems Engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. Systems Engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs IMAS IMAS-prosjektet ble initiert i 1993 som en del av et større prosjekt; PULSAR ( Prosjekt for Utforming av Luftforsvarets Strategi vedrørende ADB Ressurser), som hadde oppstart i Systemet skulle etter planen innføres innen utgangen av Semesteroppgave, Ketil Skogheim, Roller og krav til en systemarkitekt, LKSK, side 9 37 Størdal, Systemarkitektur, kunsten å utvikle komplekse tekniske systemer, side 4 38 Ibid 39 Prosjektoppgave ved BI, Georg Mattingsdal, Master of Management program prosjektledelse, 2000, Prosjekt Imas ved Luftforsvarets Forsyningskommando, side 6

18 17 Systemet består av flere moduler som snakker sammen. Lager og innkjøpsmodulen ble igangsatt januar 1999, vedlikeholdsmodulen i oktober og regnskapsmodulen i desember. 40 IMAS erstattet syv mindre systemer innen vedlikeholdsstyring, materiellstyring og produksjonsstyring, som ikke pratet sammen. Noen av de større systemene som ble utfaset var TORIL, SMIL, LISE og MICS. 41 Tidlig i prosjektet var forventningene store til dette nye systemet. En av målsetningene var en reduksjon i utgifter på 25 prosent, innen materielldrift og vedlikehold, samt 50 prosent på driftsbeholdningene gjennom redusert liggetid før Systemet ville berøre mellom to til tre tusen ansatte daglig. For mange av disse ville arbeidsdagen bli sterkt påvirket av den nye applikasjonen. Prosjektet ble nedlagt i mars 2000 og overført til linjen. En av grunnene til anskaffelsen av IMAS var å få bort alle småsystemene som florerte. Flere steder hadde enkeltavdelinger egne systemer som ingen andre hadde tilgang til. Dette ble etter hvert veldig tungvint, lite effektivt og lite oversiktlig. IMAS skulle bidra til at folk jobbet smartere og mer effektivt, uten å måtte jobbe mer. En integrering av alle småsystemene ville også sørge for en sikrere måte å drive Luftforsvarets materiell på. 43 I dag jobbes det med et nytt felles IT-prosjekt i Forsvaret; prosjekt GOLF, hvor det er meningen at nye IT-applikasjoner etter hvert skal overta for IMAS Prosjektets mål Prosjektet hadde et overordnet mål og tre hovedmål, hver med flere undermål: Overordnet mål: Delprosjekt IMAS skal bidra til utviklings- og effektiviseringsprosessen i Luftforsvaret ved å etablere en felles og gjennomgående informasjonsstruktur i materiellforvaltningen. 45 Hovedmål 1: systemskifte Delprosjekt IMAS skal erstatte dagens systemer innenfor materialforvaltningen i Luftforsvaret med nye integrerte informasjonssystemer for materiellforsyning, vedlikehold og verksteder. Hovedmål 2: Organisasjonsutvikling 40 Prosjektoppgave ved BI, Georg Mattingsdal, Master of Management program prosjektledelse, 2000, Prosjekt Imas ved Luftforsvarets Forsyningskommando, side Ibid 42 Pulsar info nr 5, desember 1994, side 7 43 Pulsar info nr 5, desember 1994, side 7 44 fra internettsiden: 45 Målsettingsdokument for Prosjekt 7108, PULSAR delprosjekt IMAS

19 18 Delprosjekt IMAS skal tilføre Luftforsvaret nye rutiner og systemer som gir organisasjonen gjennomgående og felles referanser. Dette skal gi grunnlag for endringer og tiltak som kan rasjonalisere virksomheten. Hovedmål 3: Styringsprinsipper Delprosjekt IMAS skal understøtte de nye prinsippene om ressursstyring, oppdragstyring, resultatmåling og samhandel mellom kunder og leverandører i Forsvaret Nytt Sjømålsmissil Naval Strike Missile Figur 2 Naval Strike Missile NSM-prosjektet ble offisielt startet 23/ Kontrakt ble da skrevet med KDA. Prosjektet er per i dag fortsatt ikke terminert. I dag er det i siste del av utviklingsfasen, samtidig som testing og evaluering foretas. Prosjektet hadde sin spede begynnelse allerede i 1986, hvor en oppgradering av Penguinmissilet, som Sjøforsvaret allerede hadde og brukte, ble utredet. FFI utviklet den gang grunnlaget, plattformene for de nye sensorene som skulle brukes på NSM. KDA har senere tilpasset disse det nye missilet. På grunn av stadig økende krav fra Sjøforsvaret ble det etter hvert klart at et nytt missil måtte bygges, blant annet på grunn av kravene til rekkevidde (missilet måtte kunne skytes over Vestfjorden). Dette medførte at det nye missilet måtte ha rakettmotor, 46 Målsettingsdokument for Prosjekt 7108, PULSAR delprosjekt IMAS

20 19 noe Penguin ikke hadde. Prosjektet har tatt svært lang tid, og har periodevis stått nesten stille, mye på grunn av økonomiske problemer, særlig etter den kalde krigens slutt. NSM er et avansert Fire and Forget missil som opprinnelig ble tenkt brukt på de nye MTB ene av Skjold-klassen. Dette har blitt utvidet til også å gjelde de nye fregattene i Fritjof Nansen klassen som blir levert til Sjøforsvaret mellom 2005 til , med ytterligere muligheter for å utvide bruken på flere plattformer senere, blant annet P-3C Orion og helikoptre. Selve utviklingsprosjektet for NSM har så langt kostet Forsvaret omlag 1,8 milliarder kroner. NSM kommer til å gå langt utenpå alle andre sjømålsmissiler som fins i verden i dag. Alle som har fått en demonstrasjon av systemet er imponert over egenskapene til dette missilet, og i følge både KDA og Sjøforsvaret blir det verdens beste sjømålsmissil. I forhold til Penguin-missilet så er NSM en helt ny generasjon missil med forbedringer på alle områder. 48 Prisen på selve missilet kommer til å avhenge av hvor mye som blir solgt, og da spesielt med tanke på salg til utlandet. KDA satser på å selge NSM til flere land og har derfor tatt en del risiko selv med å utvikle missilet. Dersom de ikke får solgt til utlandet vil prisen for Sjøforsvaret fort kunne bli høy. 49 Basert på de tekniske spesifikasjonene og de analysene og simuleringene som ble utarbeidet i Kontraktsdefinisjonsfasen- og tre brofaser, samt bearbeiding av disse, blir missilsystemet nå utviklet. Prosjektet i utviklingsfasen omfatter utvikling av missilsystem, skyteutstyr, kundestøtteutstyr, tekniske håndbøker, introduksjonskurs og systemutviklingsverktøy. Missilsystemet omfatter Missilsystemadministrator (MSA), Power Distribution Unit (PDU), Cable Connecting Unit (CCU) og Launcher med missil (LMM). Utviklingsfasen vil omfatte jobbledelse, systemarbeid med utarbeidelse av spesifikasjoner og gjennomføring av analyser, design og konstruksjon, produksjon av testobjekter, gjennomføring av utviklingstester, gjennomføring av simuleringer, produksjon av materiell til miljøkvalifisering og teknisk evaluering samt gjennomføring av selve miljøkvalifiseringen og evalueringen hentet fra intranett.mil.no, fire fregatter under produksjon 48 Intervju, Jan Erik Aasen, Sjøforsvaret, 11 mar Intervju, Jan Erik Aasen, Sjøforsvaret, 11 mar Intervju, Jan Erik Aasen, Sjøforsvaret, 11 mar 2005