Der findes ofte situationer hvor organisationer lukker eller genstarter deres enterprise arkitektur programmer. Årsagerne hertil kan være mange, men jeg mistænker, at en vigtig faktor er at de fleste enterprise arkitektur programmer ikke formår at levere produkter (så som artefakter, planer, systemer osv.) som interessenterne kan bruge til noget konstruktivt.

Der findes en række interessenter der har berøring med nogle af de initiativer, som enterprise arkitektur programmet producere. Det er vigtigt for chefarkitekten samt enterprise arkitekterne at kunne forholde sig til de behov som de typiske interessenter har, og producere artefakter der er skaber værdi for interessenterne. Jeg har den antagelse, at det er en nødvendighed at understøtte mellemledelsen, ledelsen og ledende medarbejdere vil det være relevant at få set på, hvordan de forskellige artefakter støtter op om behovet for at kunne tildele ansvar og muliggøre handling.

Der findes taktiske årsager til at enterprise arkitektur funktionen bliver nød til at understøtte de behov som mellemledelsen har set i forhold til forandring. Set i lyset af at organisationer anvender primært anvender enterprise arkitektur til at understøtte it-afdelingens behov, så findes der behov for at understøtte tre perspektiver set i forhold til de leverancer som enterprise arkitektur funktionen er i stand til at levere.

En parole der kan være alt afgørende for et enterprise arkitektur program er at ”At se er at tro”. Set ud fra en antagelse om at enterprise arkitektur programmet primært igangsættes af it-afdelingerne følgende tre leveranceformer være af interesse.

• Applikationer.
• Udvikling.
• Prioritering og sekvensering.

Applikationer

De fleste organisationer råder over en række forskellige applikationer der strækker sig fra at være brugerorienteret og til at læse få men velkendte opgaver (fx skriveprogrammer) til større og komplicerede systemer der anvendes til at holde styr på information (fx ERP-systemer) til web-services der er rettet mod kontakt til omverden.

Omverden skifter hurtigt set i forhold til leverandørerne også oplever forandring fx i form af opkøb, konkurs eller frasalg. Disse har stor betydning for organisationens mulighed for at anvende den specifikke applikation.

Der findes en række interessante leverancer som enterprise arkitektur funktionen kan vælge at gøre brug af:

• De mest omkostningsfulde applikationer vurderes.
• De forskellige applikationer bliver udstillet på en oversigt designet til at udstille applikationer.
• Systemerne skal vurderes ud for ”forretningens synspunkter”.
• Systemer der antages at have en overlappende funktionalitet bør overvejes at skrottes.
• En sikkerhedsvurdering. Er det muligt at blive ved med at holde applikationerne opdateret og sikre?

Udvikling

I mellemstore og store organisationer finder der typisk også en form for egen udvikling sted set i forhold til back-end systemer og web-services der skal bruges set i forhold til få transporteret information fra et system til et andet. Udviklingen finder sted i projekter, og de leverancer som de enkelte projekter fører til skal kunne implementeres i den eksisterende enterprise it-arkitektur. For at sikrer at der fastholdes en form for viden om udvikling af applikationerne så bør der være et fokus på organisationens udviklingsmodel.

• Der findes en række forskellige systemer der skal tages i betragtning.
• Det gælder om at få overblik over processerne i it-afdelingen.

Sekvensering & prioritering

Disse leverancetyper findes der ofte et behov for at få styr på, men situationen afhænger af den enkelte virksomhed, som typisk arbejder med meget individuelle problemstillinger. Dermed er det op til chefarkitekten i samråd med enterprise arkitekterne at vurdere deres opfattelse af, hvilke it-leverancer der viser sig at være interessante at levere som nummer et.

Prioritering af de forskellige leveranceformer kan opnås ved at anvende to simple værktøjer, som chefarkitekten i samråd med sine enterprise arkitekter kan anvende for få en dialog i gang om hvilke leverancer der bør prioriteres.

 

De to ovenstående illustrationer giver i udgangspunktet et fundament for dialog, men dialog er ikke nok set i forhold til at levere funktionelle løsninger. Ligeledes er en økonomisk prioritering heller ikke nok, det kræver at der støttes op om eksekvering, altså at de rigtige systemer og applikationer skrottes og der er vilje til at implementere noget nyt og anderledes.

Konklusion

Det er en nødvendighed for de enkelte enterprise arkitektur programmer at prioritere at levere resultater der er synlige for de interessenter der viser sig at værende vigtige i forhold til fortsættelsen af enterprise arkitektur programmet. Leverancer som fokusere på udviklingsprocessen, applikationer og sekvensering og prioritering er leverancer der er nødvendige at forholde sig til, hvis enterprise arkitektur programmet er lokaliseret i it-afdelingen.