Fremtidsarkitekturen

Der findes en masse problemstillinger som relaterer sig til at organisationer ikke arbejder aktivt med at formgive sin it-arkitektur. Enterprisearkitekturen som indbefatter både it-arkitekturen, forretningsarkitekturen (typisk forretningsprocesser og forretningsmodeller) og informationsarkitekturen. Ofte viser det sig at organisationens it-afdeling vil have svært ved at specificerer præcist hvordan it-arkitekturen skal se ud over en tidsperiode. Fremtidsarkitekturen (også kaldet to-be architecture) har til hensigt at give beslutningstagerne en idé om, hvorhen i organisationen som de har mulighed for at påvirke så organisationen kan opnå konkurrencefordele. Forandringerne i it-arkitekturen kan påvirke forretningsprocesserne som hvis man vælger en applikation frem for en anden til at løse bestemte opgaver med. Fremtidsarkitekturen kan vise sig svær at kommunikere ud til personer som ikke arbejder med enterprisearkitektur og det kan betyde et omfattende kommunikationsarbejde skal sættes i gang, men samtidigt skal den tekniske side af organisationen kunne visualiseres.

Til visualiserings formål kan H-modellen vise sig at være god, men H-modellen er begrænset til at fokusere på it-arkitekturen og om at få den struktureret så den passer med et fremtidigt billede af organisationen.

H-modellen

Modellen kan anvendes til at skabe et overblik over de forskellige applikationer som anvendes i organisationens logiske forretningsområder. H-modellen er illustreret nedenfor.

H-modellen
H-modellen

H-modellen består af input, output, servicebus og front-end samt en back-end.

Input

Der findes forskellige interessenter og organisationer som med en hvis sandsynlighed vil leverer information til organisationen. Det kan vise sig at være lovbestemt og det kan vise sig at interessenter i input og samtidigt være interessenter i output. De forskellige interessenter kan have integrationer eller webservices som de forskellige applikationer kobler sig op til.

Output

Der kan som sagt vise sig at være et overlap mellem interessenterne som stiler input og interessenterne som modtager output. Der vil med stor sandsynlighed også vise sig at være nogle andre interessenter som vil modtage data. Interessenterne for output bør i de fleste tilfælde betragtes som værende eksterne. Output kan komme fra de forskellige logiske forretningsområder. De bør som sådan ikke kunne tilgå applikationerne i de logiske forretningsområder, men få udleveret data igennem webservices.

Servicebussen

Formålet med servicebussen er at kunne få applikationerne til at behandle data og anvende hinandens funktioner på en bedre og mere overskuelig måde end punkt-til-punkt integrationer. Servicebussen står for orkestrering af beskeder mellem de forskellige applikationer. Det som kaldes for servicebussen kan også indeholde forskellige typer applikationer. En applikation som kan nævnes er en applikation til orkestrering af de forskellige meddelelser.

Front-end

Delen kaldet front-end består af klienter og portaler. Klienterne har direkte adgang til de applikationer som findes i de logiske forretningsområder. Maksimum 20 % af brugerne bør have adgang til klienterne som har direkte adgang til applikationerne. Minimum 80% af brugerne bør anvende portalerne til at interagere med applikationerne i de logiske forretningsområder.

Back-end

Den nederste del af H-modellen består af de logiske forretningsområder. Under de logiske forretningsområder kan applikationer som business intelligence applikationer og data warehouses og store databaser.

IT-arkitektur

Applikationer, datamodeller, informationsmodeller, processer med henblik på problemløsning af it-relaterede problemstillinger, hardware platforme og netværk er alle dele af it-arkitekturen. H-modellen omhandler services, logiske forretningsområder og ikke mindst applikationer. Det er derfor af stor betydning for organisationen. Det er nødvendigt for de fleste organisationer at få styr på deres it-arkitektur og de forskellige dele af den, men det er samtidigt, måske mere nødvendigt at få styr på organisationens forretningsarkitektur. H-modellen er derfor et artefakt som kan bruges til at engagere de forskellige beslutningstagere, eksperter og medarbejdere som skal konsulteres for at de rette leverancer kommer på plads så organisationen kan forandres.

I arbejdet med at sætte fokus på arbejdet som skal føre til at opnå konkurrencefordel så kræver det at der findes en konstant skanning af organisationens interne og eksterne miljøer, hvor en prioritering af de forskellige informationsteknologier bliver vurderet og prioriteret i forhold til investering i organisationens interne situation.

125 Technology Evolution

Informationsteknologierne som er relevante for organisationen at investere findes i emnet tæt på adaptable.

Service-orienteret arkitektur

Typisk forbindes SOA med protokoller, standarder og services som forbinder forskellige applikationer sammen på en måde som gør det overskueligt at understøtte at de rette applikationer kan udveksle informationer og anvende hinandens funktioner. SOA som er korrekt implementeret kan påvirke organisationens evne til at kunne skabe et fornuftigt overblik over sin it-arkitektur og ligeledes kan SOA som et program være med til at understøtte at der opstår en dialog med de forskellige forretningsenheder om hvor meget de forskellige forretningsprocesser skal kunne skaleres.

Inden for SOA verdenen figurerer H-modellen og denne type model kan, hvis den anvendes rigtigt, bruges til at skabe overblik over applikationslandskabet i sin nuværende form og samtidigt kunne bruges som dialog med de forskellige interessenter med henblik på at skabe en strategisk retning for hvilke applikationer, som organisationen skal investerer i på sigt.

SOA er bindeledet mellem applikationerne, men SOA uden anvendelse af it-arkitekturen kan ikke leverer et reelt transformationsprogram.

Konklusion

H-modellen kan vise sig anvendelig i forhold til at få defineret fremtidsarkitekturen. Modellen er god fordi den bidrager med lige akkurat nok information om it-arkitekturen til at beslutningstagerne kan træffe beslutninger om, hvordan de enkelte ansvarsområder og it-orienterede logiske forretningsområder kan udvikle sig.

Skriv et svar

Please log in using one of these methods to post your comment:

WordPress.com Logo

Du kommenterer med din WordPress.com konto. Log Out /  Skift )

Twitter picture

Du kommenterer med din Twitter konto. Log Out /  Skift )

Facebook photo

Du kommenterer med din Facebook konto. Log Out /  Skift )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Blog på WordPress.com.

Up ↑

%d bloggers like this: