På grund af den internationale økonomiske krise, de krav som regeringer påtvinger banksystemet og forbrugernes forbrugslyst påvirker organisationernes evne til at kunne skaffe kapital og investerer den i forhold til at kunne sikre sig udvikling på en særdeles negativ måde. Siden det er blevet væsentligt svære at skaffe kapital er det ofte en nødvendighed at få så meget ud af den investerede kapital som muligt. Dette kan lade sig gøre ved at organisationerne fokuserer mere på at få de forskellige dele af organisationen til at arbejde bedre sammen og dermed være med til at begrænse omkostninger.

Udviklingen af organisationens enterprise arkitektur har stor betydning på organisationens evne til at kunne sikre sin konkurrencemæssige evne. Derfor bør fokus være på at udvikle projekter der kan være med til at øge effektivitet af de aktiviteter, som organisationen er god til at få udført og ligeledes søsætte projekter der mindsker de problemstillinger, som organisationen står overfor.

Fordele ved enterprise arkitektur

Enterprise arkitektur kan medføre en række fordele, hvis enterprise arkitektur programmet implementeres korrekt. Foorthuis (2012, s. 54) skriver, at Capgemini (2006), Bucher et al. (2006), Wagter et al. (2005) nævner følgende fordele ved enterprise arkitektur programmet:

1)   Reducerede risici og kompleksitet.

2)   En højere grad af projekt-succeser.

3)   Reducerede projekt omkostninger og forbedrede ROI og evnen til finde genanvendelige services og komponenter der kan anvende dem.

4)   Projekt igangsættelse, hvor EA modeller kan assistere specificere Projekt Starts Arkitekturen kan være med til at begrænse behovet for koordinering med de forskellige andre projektledere og projektteams.

5)   Kortere projekter ved at de beslutninger der defineres i PSA’en gør at projektteamet skan fokusere på arbejde på løsningen.

Ifølge Foorthuis (2012, s. 55) så består projekt arkitekturen af to elementer. Projekt Starts Arkitekturen (PSA) og Project Exclusive Design (PED).

Inden projekternes betydning og projekt starts arkitektur og PED behandles, så mener jeg, at der findes et behov en kort gennemgang for modning af enterprise arkitekturerne, og hvad det vil sige at have en enterprise arkitektur på samtlige niveauer.

Modning af enterprise arkitekturen

Doucet et al (2009) beskriver tre former for praktisering af enterprise arkitektur i organisationerne, og de tre former afhænger af organisationernes modenhed.  Doucet et al mener at alle organisationer som sådan har en arkitektur, men fordelene høstes kun, hvis organisationen aktivt går ind og arbejder med den igennem et enterprise arkitektur program.

Fundament arkitektur

Det første niveau som organisationen vil opnå med sit enterprise arkitektur program vil være fundament arkitekturen (foundation architecture), hvor enterprise arkitektur programmet er placeret i it-afdelingen med det fokus at give de forskellige beslutningstagere i it-afdelingen kan udvælge de enkelte projekter der vil kunne understøtte en bedre it-arkitektur i organisationen.

Udvidet arkitektur

Doucet et al arbejder videre med ideen om at enterprise arkitektur programmet kan adopteres af forretningen (altså de enheder af organisationen der er uden for it-afdelingen). Dette niveau kaldes for udvidet arkitektur. Forretningsarkitekter, informationsarkitekter og enterprise arkitekter arbejder med at udarbejde information, planer og scenarier for, hvordan organisationen kan udvikle sig.

Indlejret arkitektur

Doucet et al mener, at enterprise arkitektur programmet kan udvikle sig yderligere til det, de kalder for indlejret arkitektur. Denne form for arkitektur eller rettere dette niveau for arkitektur omhandler at det ikke længere er tale om at enterprise arkitekterne, forretningsarkitekterne eller informationsarkitekterne sidder og udarbejder artefakter, scenarier osv. Det er de forskellige ”implicitte” arkitekter der typisk besidder andre jobtitler.

Der findes forskellige niveauer inden for enterprise arkitektur teamet såvel som for de implicitte arkitekter på alle niveauer i organisationen.

Det formelle enterprise arkitektur team bruger deres energi på at understøtte udviklingen af artefakterne så de passer med de modeller og rammeværker de har været med til at definerer, og derudover går deres arbejde ud på at understøttelse af de implicitte arkitekter i deres aktiviteter med at dokumentere og organisere de forskellige dele af organisationen.

Projekter i en arkitektur-kontekst

For at få organisationens enterprise arkitektur til at udvikle sig kan det vise sig at være nødvendigt arbejde med projekter.

Et projekt

Der findes mange definitioner af hvad et projekt egentlig omhandler. Jeg har valgt at anvende en antagelse om at projekter består af et sæt aktiviteter der har til formål at løse en bestemt opgave fx at levere en it-løsning til en bestemt enhed i organisationen. Et projekt er kendetegnet ved at det er relativt unikt og det samtidigt er afgrænset. Dele af denne betragtning understøttes af Foorthuises anskuelse af begrebet projekt.

 

”A project us a temporary endavor undertaken to deliver a local solution, i.e. a unique product, service or result (project Management Insitute, 2004)” – Foorthuis (2012, s. 9)

De forskellige projekter er med til at understøtte løsninger på de problemstillinger, som organisationen står overfor, og et projekt bør kunne implementeres, når det går fra projekt-organisationen til linje-organisationen.

For at projekterne der burde være med til at understøtte udviklingen af enterprisens arkitekturen kræver det til dels at projekterne er succesfulde og at de i anledning af at være succesfulde overholder de krav og afgrænsninger som organisationens enterprise arkitektur program fastsætter.

Afstemning

For at projekterne stemmer overens med de krav, som enterprise arkitektur programmet har opstillet set i forhold til at nye systemer, processer og information passer sammen med de tekniske og sociale systemer som organisationen er underlagt på grund af de beslutninger der er truffet i forhold til investering i informationsteknologi. Ofte når der er tale om ældre organisationer, hvor der har været forskellige situationer hvor it-investering blev foretaget. Dette er en af faktorerne og årsagerne til at enterprise arkitektur programmet bør være med til at fastlægge principper, standarder og road maps for at kunne  give retningslinjer til den enkelte projekter.

De enkelte projekter bør derfor både evalueres og kontrolleres for at de reelt er afstemt med enterprise arkitekturens rammer og betingelser. Nedenfor har jeg citeret Foorthuis for sin definition af begrebet overensstemmelse.

”We define compliance as the extent to which there exists a state of accordance between an actor’s behavior or products on the one side and predefined explicit rules, procedures, conventions, standards, guidelines, principles, legislation or other norms on the other side (cf. Zaelke et al, 2005; Kim, 2007; Faure and Lefevere, 2005; Foorthuis et al, 2012; Mitchell, 2006; Abdullah et al, 2009)” – Foorthuis (2012, s. 10)

Jeg nævnte tidligere, at måden enterprise arkitektur programmet udvikles på sker igennem implementering af projekter (forretningsprojekter såvel som it-projekter). Enterprise arkitektur funktionen bør fokusere på at guide de enkelte projekter for at sikre den mest fordelagtige løsninger for organisationens arkitektur og dermed for organisationen.

Foorthuis mener, at enterprise arkitekturen og eventuelle domæne arkitekturer har indflydelse på de enkelte projekter. Foorthuis kalder dette for ”prescription”, hvilket oversættes til hævd eller recept for projektet, men som jeg ser det giver det mere mening at kalde det et blueprint for projektet (eftersom jeg ikke mener, at et blueprint giver alle detaljer, men giver dem der bygger de ydre rammer for hvad der skal bygges). Hvis projekterne får stillet et blueprint som projektlederne så bør følge kan, som jeg ser det, medføre at projekterne kan udføres hurtigere, da projektlederne så ikke skal ud for selv at undersøge om der er elementer der påvirker projektets pålidelighed. Nedenfor er Foorthuis citeret for henholdsvis det jeg ville kalde blueprints (eller fundamentalt set projekt start arkitekturer) og domæne arkitekturer.

Enterprise arkitektur funktionen har derfor mulighed for at understøtte en positiv forandring i organisationen, hvis de forskellige projektledere og de forskellige projekter bliver evalueret.

”Prescriptions are used in EA to provide constrains and direction. As such, they are the means by which the EA (and possibly a Domain Architecture) influence projects. Prescriptions can take various forms. They can be text-based principles that state a generic requirement, or they can be graphical models that depict a generic process or structure which can be refined by the project which takes them as a starting point. Prescriptions will evovle but should be relativiely stable over time” – Foorthuis (2012, s. 52)

”Second, if needed, one or more Domain Architectures (DAs) can be created. These are architectures defined on the basis of one specific group of products, services, processes or functions. A Domain can be acknowledged on the level of the enterprise, for example security or a specific process step that is used through-out the organization. However, a DA can also reside below enterprise-level, for instance when creating guidelines for one specific product group” – Foorthuis (2012, s. 53)

Projekt Start Arkitektur

Jeg nævnte tidligere, at Foorthuis definerer to typer sub-arkitekturer til projekt-arkitekturer. Den første form for arkitektur kaldes for projekt start arkitekturer og den anden form kaldes for project exclusive documents (hvilket vil egentlig kan oversættes de artefakter som projektet producere) og bør overvejes at indarbejde i enterprise arkitektur rammeværket, hvis organisationen vel at mærke arbejder med modeller der har behov for den type information. Ellers bør dokumenterne arkiveres i et projektledelsesrelateret bibliotek der kan tilgås af projektledere, løsningsarkitekter, informationsarkitekter, forretningsarkitekter og enterprise arkitekterne.

”As a third kind, Project Start Architectures (PSAs) can be distinguished. An Architecture on the level of the enterprise or a domain does not detail the complete functional and technical design for a specific solution. This will be done in a lower level project that should conform to the general EA and/or relevant DA. Therefore, at the start of such a local project, a PSA can be created (Wagter et al., 2005). This is an architecture on the project level that inherits and, if needed, translates the prescriptions from the EA, and possibly a DA, to prescriptions that are tailored to the specific project at hand.” – Foorthuis (2012, ss. 53-54).

Projektkontoret

Gartner-analytikeren Brian Burke (2006) mener, at enterprise arkitektur programmet bør arbejde med at skabe vished om, at de projekter der udarbejdes overholder de blueprints eller guidelines, som er udstedt af enterprise arkitektur funktionen.  I den forbindelse kommer Brian Burke ind på der bør fastlægges en proces der står for at være sikker på, at de forskellige projekter overholder dem.

I et møde jeg havde med Brian Burke i marts 2012, gav han udtryk for at fokus på projekter kunne være en fornuftig fremgangsmåde for et enterprise arkitektur program kan bevæge sig i den rette retning fordi projekterne modtager 1) opmærksomhed og 2) det giver mulighed for at kunne evaluere projekterne og sikre sig indflydelse.

Derfor kom jeg til den konklusion, at chefarkitekten bør fokusere på at tage del i programledelsen (den gruppe beslutningstagere der træffer beslutninger om de enkelte projekter) og hvis muligt få skabt fokus på at enterprise arkitektur funktionen bør have den ledende rolle i forhold til evaluering af de enkelte projekter. Dermed sagt så bør chefarkitekten være i stand til at sælge ideerne til de andre beslutningstagere og samtidigt være i stand til at kunne skabe nye relationer til dem der kommer i berøring med de instruktioner og beslutninger der træffes i led af enterprise arkitektur programmet.

Konklusion

Fokus på projekterne er vigtig i forhold til at få udvikle organisationens enterprise arkitektur, da beslutningstagernes opmærksomhed er rettet mod projekterne og at enterprise arkitektur funktionen har mulighed for at påvirke projekterne ved at udstede de rette blueprints til de rette mennesker på den rette tid.

Enterprise arkitektur omhandler på mange måder om at skabe de rette forbindelser mellem beslutningstagerne og medarbejderne i organisationen således de aktiviteter udføres på den rigtige måde.

For at projekt starts arkitekturen kan blive et aktiv i udvikling af nye projekter og påvirke organisationens enterprise arkitektur så kræver det at der findes en chefarkitekt der griber chancen, der har kompetencerne og er i stand til at sælge enterprise arkitektur programmet til andre beslutningstagere der vel at mærke lader sig påvirke. Dertil så kræver det enterprise arkitekterne og de andre arkitekter er i stand til at levere resultater.

Kilder

Burke, B., 2006, Implement an Effective Assurance Process for Your Enterprise Architecture.

Doucet et al., 2009, Coherency Management: Architecting the Enterprise for Alignment, Agility and Assurance.

Foorthius, R., 2012, Project Compliance Enterprise Architecture.

Wagter et al., 2005, Dynamic Enterprise Architecture: How to Make it Work.