Applikationer har på visse områder en lignende livscyklus den organismer har. Livscyklussen har betydning for risici som organisationen oplever og på de strategier samt handlingsplaner der udarbejdes. Derfor bør chefarkitekten arbejde med begrebet livscyklus i de strategier og planer der ligges for organisationens anvendelse af informationsteknologi (it).

Jeg har lagt mærke til at emnet håndtering af livscyklus (Lifecycle Management) ikke fylder ret meget i enterprisearkitektur litteraturen. Dette er til trods for at der findes en form for konsensus om enterprisearkitektur bør understøtte at skabe overblik over applikationslandskabet og at der bør udarbejdes planer og roadmaps for prioritering og valg af teknologier (Anupinidi & Coady 2011) er et vigtigt område for chefarkitekten at have en mening om i forhold til organisationens udvikling.

Livscyklus

Applikationer kan på sin vis fortolkes som havende en livscyklus som på visse områder kan minde om en organismes. Applikationen starter som en idé, sidenhen begynder en reel udvikling, hvortil applikationen på et tidspunkt når et niveau så den kan lanceres. Lancering skal tolkes som det tidspunkt, hvor applikationen tages i brug til kommercielle formål. Dernæst kommer fasen der, hvor applikationen begynder at skabe værdi for organisationen altså det der kan kaldes for ”i produktion” fasen.

På et tidspunkt vil leverandøren til applikationen have skiftet strategi eller fundet frem til at en anden type teknologi vil være bedre at satse på fremadrettet, hvis jeg vel at mærke kan antage at leverandøren stadig eksisterer.

Software (applikationer) kan virke i meget lang tid, især hvis der ingen afhængighed er til hardware uden for det, som organisationen råder over, men hardware bliver nedslidt og det er ikke sikkert at de grundlæggende systemer der understøtter det specifikke system understøttes fx i form af operativsystemer, API’er eller tilsvarende. Hvis systemet bryder sammen kan det have stor betydning i forhold til muligheden for at organisationen vil være i stand til at kunne fungere set i forhold til at kunne leverer produkter og service til kunderne.

McKeen & Smith (2003) mener at hardware og software rent strategisk kan sidestilles med hinanden, når det kommer til fremgangsmåden der skal anvendes set i forhold til estimering af risici, hvor systemet enten sander til og med tiden bliver svært at håndtere og udvikle på eller at systemet bryder sammen. McKeen & Smith bruger en definition som antyder at når det viser sig at det specifikke it-system (hardware og software) ikke understøtter forretningen på en omkostningseffektiv måde, så bør it-systemet betragtes som værende udaterede.

”Stated differently, information technology should be renewed when it fails to provide adequate functionality to support the business in a cost-effective manner. This is when it should be considered obsolete” – McKeen & Smith (2003, s. 186).

For at få styr på it-relaterede risici anbefaler Westerman & Hunter (2007) at organisationen påbegynder at arbejder med at få styr på sit fundament, hvilket vil betyder at arbejdet med den teknologi der findes og udvikles på i organisationen bør drives ud fra et perspektiv om at skabe et sundt fundament. Et fundament hvor organisationens it-afdeling og den generelle organisation arbejder på at få sat styr på kompleksitet i forhold til udviklingsarbejdet som for eksempel giver det mening at arbejde med oldnordiske applikationer eller oldnordiske programmeringssprog i en organisation der kræver konstant tilpasning og forandring. McKeen & Smith (2004) bekæftigede sig med en strategi, hvor der udarbejdes et ”Technology Blueprint” for hvordan det forventes at de forskellige fremtidige teknologier forventes at blive anvendt, og ligeledes taler McKeen & Smith for at der udnævnes ansvarlige individer for håndtering af de enkelte applikationer og it-systemer.

Organisationer der har anvendt informationsteknologi i en periode vil dog ofte opleve at de forskellige systemer er vævet sammen og ved udfasning af et system ikke vil være helt så lige til at erstatte funktionerne der mistes som først antaget. Derfor kræver det en hvis grad af analyse og planlægning før en organisation ideelt set begynder på at udarbejde et roadmap.

Roadmap

Et roadmap er ifølge Anupindi & Coady en kerne leverance set i forhold til et enterprisearkitektur program. I sin natur er et roadmap fremadrettet. De har defineret to typer roadmaps. Det ene roadmap med fokusering på applikationer og på den fremtidige anvendelse af teknologi.

I forbindelse med definition af artefakterne der udgør de to roadmaps har Anupindi & Coady en karakterisering der tyder på at  fremgangsmåden med at udarbejde et roadmap for applikationer primært er en illustration der viser, hvad der forventes at ske med den givende applikation på over en årrække. I arbejdet med den specifikke applikation bliver det en nødvendighed at understøtte forskellige handlemåder så som opgradering, vedligeholdelse og i sidste ende udfasning. I forhold til den form for roadmap der omhandler de teknologier, som organisationen bør satse på, hvordan teknologierne påvirker applikationerne (og dertil at de enkelte application roadmaps bliver opdateret) samt hvilke leverandører som organisationen ønsker at satse på. Fujiyoshi et al deler dette synspunkt, hvor de anvender en noget mere generel tilgangsvinkel der på sin vinkel understøtter udvælgelsen af teknologier og formålet med et teknologi roadmap er at understøtte formuleringen af en it-strategi.

Fujiyoshi et al (2005)mener, at et roadmap omhandler at kunne understøtte en it-strategier ved at give beslutningstagerne mulighed for at kunne træffe beslutninger omhandlende teknologierne der anvendes på sigt.  Dette kommer til udtryk i citatet nedenfor:

”The IT road map is designed to support client companies and the NRI Group companies in making decisions on IT Strategies by establishing a highly precise view of each technology field up to five years in the future.” – Fujiyoshi et al (2005).

Ydermere kommer Fujiyoshi et al ind på at planlægningen af it-strategier blandt andet kræver at der findes et større fokus på det teknologiske økosystem der er til rådighed for organisationen, og på den måde virker det til at den information som organisationens analytikere som for eksempel enterprisearkitekter råder bør sættes i spil i processen for at tegne et teknologi roadmap.

”The information technology map is designed to provide guidelines for activities in making the best use of each type of information technonology.” – Fujiyoshi et al (2005).

Konklusion

Kilderne henviser til at et enterprisearkitektur program kan bruges til at understøtte et sundt fundament for it og forretningsudvikling for organisationen, men det er vigtigt at tænke holisme ind i tankegangen som enterprisearkitektur programmet anvender, og det er ligeledes vigtigt at påvirke it-strategien igennem roadmaps for de applikationer og den fremtidige teknologi der er til rådighed.

Hvis en livscyklus ikke tages i betragtning i forhold til teknologistrategien (en hjørnesten i it-strategien) så kan det betyde at organisationer på sigt oplever højere risici og med tiden kan organisationen komme til at opleve forøgede omkostninger, eller opleve at omstilling ikke kan lade sig gøre fordi organisationen har låst sig fast på en teknologi der ikke længere understøttes i form af leverandører, ressourcer i form af systemudviklere eller hardware ikke længere kan afvikle systemerne.

Kilder

Anupindi, Nagesh V., and Gerard A. Coady. Enterprise Architecture Turnaround. Trafford Publishing, 2011.

Fujiyoshi et al, Information Technology Map and IT Road Map, NRI Information Technology Report, 2005.

McKeen, James D., and Heather A. Smith. Making IT Happen: Critical Issues in Managing Information Technology. John Wiley & Sons, 2003.

Westerman, George, and Richard Hunter. IT Risk: Turning Business Threats into Competitive Advantage. illustrated ed. Harvard Business School Press, 2007.