Ændringer i IT landskabet?
Står jeres virksomhed overfor at skulle indføre et nyt IT produkt/system eller udvide et eksisterende? Så har I nok brug for en IT-Arkitekt. Har I overblik over kompleksiteten og omkostningerne i forbindelse med dette projekt? Er alle krav til systemet beskrevet? Både de funktionelle og de ikke-funktionelle krav?
De funktionelle krav er alle de ting som det nye system skal kunne, fx oprette brugere, gemme data, udskrive dokumenter, vise data osv. Ikke-funktionelle krav kaldes også kvalitetskrav og kan fx være tilgængelighed, sikkerhed, hastighed, brugervenlighed, ydeevne osv. Det er vigtigt at få disse krav på plads og beskrevet således at udviklere og virksomheden forstår dem, da de sætter rammerne for projektet.
Ligeledes skal begrænsningerne også beskrives, så alle er klar over hvad systemet ikke kan og ikke skal kunne funktionelt og ikke-funktionelt. Dette er IT-Arkitekten i stand til at hjælpe med.
Vision
IT-arkitekten arbejder sammen med ledelsen i starten af projektet med at få defineret projektet. Hvad er det der skal løses og skaber det rent faktisk værdi for virksomheden? Ud fra en businesscase får arkitekten stillet de rigtige spørgsmål til ledelsen og får skrevet det vigtige dokument der beskriver Visionen. Dette dokument er projektets beskrivelse således at alle i virksomheden, lige fra ledelsen til brugeren af systemet, kan se hvad projektet går ud på. Og mindst ligeså vigtig; hvorfor.
Brugere kan hurtigt blive fortvivlede hvis de skal til at lære et nyt system at kende. Måske erstatter dette system noget de har kendt igennem mange år og det kan være svært at lære nye systemer at kende når man har nået en vis alder. Men hvis disse brugere kan forholde sig til Visionen og se hvorfor de skal erstatte det gamle system, vil overgangen være væsentlig nemmere. Når de ser at det nye system kan klare det gamle systems opgaver på en tredjedel af tiden, vil brugerne have en andet mind set og måske ligefrem gå og glæde sig til det nye system bliver implementeret. Ligeledes er det vigtigt for udviklerne at forholde sig til Visionen. De sidder måske og udvikler på en delkomponent af systemet og har derfor brug for at se helheden af hvad det er de er med til at skabe.
Design
Når Visionen er på plads påbegyndes design fasen, hvor arkitekten samarbejder med et hold af erfarne udviklere om at få designet og dokumenteret projektet ud fra Visionen. Hvilken metode der benyttes kommer an på projektets størrelse, størrelse på udvikler team(s) og hvor erfarne udviklerne er.
Er der tale om et hold af super erfarne udviklere er det måske blot nødvendigt at have designet systemet og dets moduler samt evt. Grænseflader til andre system. Derefter er de selv i stand til at kunne designe komponenterne til de forskellige moduler. Denne tilgang er en hybrid metode hvor man starter med “top down” og skifter til “bottom up” når den agile udviklingsproces starter på komponenterne.
Men hvis udviklerne består af nye udviklere med knap så meget erfaring inden for det område de skal udvikle, kan det være nødvendigt at design teamet kører en ren “top down” og får designet hele vejen ned på komponent niveau. Design fasen er ikke en one-shot proces. Den er iterativ og kan sagtens blive skudt i gang løbende når der sker udvikling af komponenter og moduler. Ting ændrer sig og man bliver måske opmærksom på nogle ting som skal ændres under vejs. Designet skal løbende kunne ændres. Men selvfølgelig skal man gøre sig omhyggelig og forsøge at få designet systemet mest muligt i den første fase, da det er tidskrævende at genbesøge fasen og implementeret ændringer.
Designfasen skal også indtænke tests i systemet. Hvorledes kan man teste de forskellige komponenter og moduler uafhængigt af hinanden og endeligt en test at hele systemet. Test skal sikre at det er det rigtige der bliver udviklet, men også ved løbende udvikling eller vedligehold at funktionaliteten ikke går i stykker eller ændrer sig af det pågældende modul eller komponent.
Udvikling & Test
Når designet er på plads og beskrevet i de nødvendige views som er blevet udarbejdet i designfasen kan det reelle udviklingsarbejde begynde. Udviklerne laver de forskellige komponenter til de forskellige moduler der sammen giver systemet. Det gør de ud fra de “regler” der er blevet defineret i de forskellige views. Det kan fx være at der er specificeret at der skal bruges et bestemt pattern til komponenterne, eller at modulerne skal have et helt særligt interface.
Udviklerne tester løbende deres komponenter som de bliver færdige med dem. Opfylder de også de krav som designet kræver? Gør de rent faktisk det som er meningen? Når alle komponenterne er færdige i et modul, testes modulet igennem. Opfylder dette kravene fra designet? Når alle moduler er færdige, testes systemet af i en decideret test fase. Dette inkluderer test af alle dele af systemet samt test på det hardware og infrastruktur som systemet skal køre på.
Såfremt alle test er succesfulde kan implementationsfasen begynde. Systemet sættes i drift på det hardware og infrastruktur som er defineret i designet. Når systemet kører som det skal begynder monitoreringsfasen. Denne kører indtil systemet ikke skal være i drift mere eller indtil at det skal udvides. I dette tilfælde begynder faserne forfra med at få beskrevet hvad de nye funktionaliteter er og derefter får dem udviklet, testet og sat i drift.