Artikler om Uddannelse

Sammenhæng, arkitektur og øl

Wednesday, 3. March 2010

Den 24. – 26. marts holder vi næste-generations EA-kurset Coherency Management – Architecting the enterprise (hent kursusbeskrivelsen) sammen med Dansk IT. Vi har holdt dette kursus før, og har noget godt materiale, men som noget nyt vil vi denne gang trække en konkret case direkte ind i forløbet. Casen er Carlsberg.

Dels kommer Jan Staack, EA Senior Manager hos Carlsberg IT, og fortæller om hvordan Carlsberg arbejder med EA og om de styringsmæssige udfordringer. Og dels kommer tre unge forskere, som har arbejdet med Carlsberg det seneste halve år, og giver deres perspektiv på sammenhængsledelse i Carlsberg, og generelt.

EA-certificering 2010

Friday, 5. February 2010

Der er nu åbnet for tilmelding til det første certificeringsforløb i 2010.

Hent brochure (PDF) eller kontakt John på 5124 5878 for yderligere info.

Certificering som enterprisearkitekt – i Danmark

Friday, 3. October 2008

Carnegie Mellon University’s EA-trænings- og certificeringsprogram starter nu op i Danmark, leveret af EA Fellows.

Efter at have kørt programmet i over et år i Belgien og Holland sammen med Telelogic, har vi i EA Fellows ladet os akkreditere hos CMU til selv at kunne udbyde programmet. Ikke at vi har noget imod Telelogic – som nu er en del af IBM – men vi mener godt, at vi “kan selv”, og desuden vil vi – og CMU – gerne understrege, at programmet er leverandøruafhængigt.

Vi kører det første kursusforløb i november-januar, og der er stadig enkelte ledige pladser. Blandt allerede tilmeldte deltagere er en finansiel koncern, en statslig myndighed og et teleselskab.

Der er tale om tre intensive kurser à 4 dage. To eksamener undervejs. En lærebog, som forventes læst under forløbet. Kursusdokumentationen er omfattende. Fast underviser er John Gøtze, som trækker relevante gæsteforelæsere ind i forløbet.

Læs mere om CMU-kurserne her, samt ovre på enterprisearchitecture.dk. Eller hent vores nye brochure!

Man certificerer da arkitekter

Sunday, 20. May 2007

Der er en voksende efterspørgsel efter EA-kompetencer, og det er derfor os en fornøjelse, at annoncere et nyt program for træning og certificering som enterprise arkitekt.

EA Fellows er gået sammen med det amerikanske Carnegie Mellon University, et af superliga-universiteterne på it-området, og Telelogic, en af verdens førende EA-værktøjsleverandører, om at udbyde et EA-trænings- og certificeringsprogram i Europa.

I juli, september og november udbyder vi de første certificeringskurser i Amsterdam og Bruxelles. Vi planlægger endvidere kurser i de nordiske lande, og vil gerne høre fra folk, der eventuelt er interesserede i sådanne.

Der er tale om et tredelt forløb med et Fundamentals-kursus, et Applied-kursus og et Advanced-kursus. Det grundlæggende Fundamentals kursus henvender sig til arkitekter og ledere, der vil introduceres til EA. De to efterfølgende kurser går mere i dybden/stiller større krav, og henvender sig til praktiserende forretnings- eller it-arkitekter. Der er tale om nogle meget intensive kurser (3-5 dage), der hvert især afsluttes med en eksamen. Gennemføres alle tre kursus på tilfredsstillende vis tildeles titlen Certified Enterprise Architect med et dobbeltcertifikat fra Carnegie Mellon University og Telelogic.

Kurserne og certificeringen er baseret på et antal EA Knowledge and Skills Areas (KSAer), der angiver hvad en enterprisearkitekt skal vide og kunne (se CMU’s EA-KSA List), og programmet specificerer på den baggrund konkrete læringsmål. Disse er baserede på de 350 ‘learning points’, der er opstillet af det amerikanske CIO Council i en EA competency matrix, der afspejler de 42 EA læringsmål i dokumentet 2006 Clinger-Cohen Core Competencies and Learning Objectives. Selvom disse er udviklede med henblik for den amerikanske centraladministration er der tale om tilpas generiske krav til, at de også passer fint ind i en europæisk kontekst, og er relevante for både offentlige og private virksomheder.

At der er et samarbejde med Telelogic i dette certificeringsforløb betyder ikke, at kurserne orienterer sig mod specifikke leverandørers EA-værktøjer. Kursernes curriculum er udviklet af Dr Scott Bernard og efteruddannelses- og certificeringseksperter fra Carnegie Mellon universitetet. Bernard er en erfaren enterprise arkitekt (og forhenværende jagerpilot), der bl.a. har skrevet EA-lærebogen. Sammen med Telelogic har han startet programmet op for godt et år siden i USA, og samarbejder nu med EA Fellows om opstarten i Europa, hvor det er EA Fellows’ John Gøtze, der er ansvarlig for kurserne, og som har tilpasset dem til europæiske forhold.

For EA Fellows er dette partnerskab med akademisk og EA-professionel tyngde helt ideelt. Ikke blot er det en bro ud i Europa, det er også en god måde for os at fokusere vores indsats. Vi vil gerne bruge flere ressourcer på direkte dialog med vores kunder, og ser derfor certificeringsprogrammet som en integreret ydelse i et kompetenceskabende samarbejde med vore kunder. Vi sammensætter gerne et specialtilpasset forløb, der kombinerer kurserne, med individuel coaching og review for den enkelte organisation.

Tag gerne kontakt med John Gøtze på 5124 5878 eller john (Email address: john #snabel-a# eafellows.com), hvis du vil høre mere om mulighederne.

At være eller ikke være enterprise arkitekt

Tuesday, 30. January 2007

Både i den videnskabelige litteratur, hos analyse institutter, og på blogs “i den virkelige verden” er der en rimelig enighed om hvad betegnelsen enterprise arkitektur (EA) står for. Men samtidig er der en klar tendens til, at stadig flere IT professionelle får betegnelsen “arkitekt” føjet til deres visitkort.

Det kan være en udfordring at få øje på enterprise arkitekten blandt alle de andre typer af arkitekter som vi møder: infrastruktur-, sikkerheds-, applikations-, løsnings-, informations-, database arkitekter – og der kommer stadig flere til!

Alle disse gode mennesker er utvivlsomt kompetente og effektive til at planlægge, designe og implementere IT-løsninger, men det kan nok diskuteres, om de alle beskæftiger sig med arkitektur. For arkitektur handler om at organisere på et overordnet niveau, i modsætning til at udforme løsningens detaljer.

I forbindelse med de konkrete opgaver, som EA Fellows løser for større kunder, er vi stødt på flere af de ovennævnte arkitekter, og mange tankevækkende beskrivelser af arkitektur. Derfor vil vi her give vores bud på, hvad arkitektur er, og – måske lige så vigtigt – hvad det ikke er.

Arkitektur er ikke tomme ord

“Arkitektur” er ikke en ny og opgraderet version af “bullshit-bingo” hvor det gælder om at kunne benytte flest akronymer og frameworks, på en måde så al tale bliver sort for dem som lytter. Hvis det er oplevelsen, så er det en sælger der taler – og ikke en arkitekt.

Arkitektur er ikke en konsulentydelse

“Arkitekter” er ikke en titel der er forbeholdt konsulenter, der er også en stor andel arkitekter i forskningsmiljøet og blandt de ansatte i offentlige og private virksomheder.

Arkitektur er ikke programmering

“Arkitektur” er mere end udvikling af ny software. Programmører og projektledere er ikke arkitekter, det er personer der har til opgave at skrive kildetekst, lave applikationer og styre implementeringen. Arkitektur handler om at organisere løsningens elementer på et overordnet niveau, og tage de principielle beslutninger for løsningens udformning.

Arkitektur indeholder mange discipliner

Der er mange discipliner indenfor arkitektur, og de har hver til sin tid en berettigelse. Hvis discipliner udelades, det være sig tekniske, organisatoriske eller procesmæssige, så bliver resultatet ensidigt og ukomplet. Alle discipliner må balanceres efter opgave, organisation og modenhed, for et skævt fokus vil føre til bristede illusioner og gode spildte kræfter for alle involverede.

Arkitektur kræver samarbejde og governance

En “stærk ledelsesforankring” eller anden form for “stærkt lederskab” bliver ofte nævnt som et element i arkitekturen, men det vil i sig selv aldrig løse opgaven for forretningen. Arkitekturen er en “opskrift”, som forretningsorganisationen sammen med ledelsen kan bruge til at løse de konkrete problemer og udfordringer, men det kræver at organisationen er i stand til at tage beslutninger og handle, for at realisere opskriften.

Arkitektur starter i forretningen

“Arkitektur” der ikke tager udgangspunkt i service til forretningen, krav eller ønsker fra forretningen, er ikke arkitektur, men elementer i en løsning. En “rigtig” arkitektur er en udmøntning af forretningsstrategien, og indeholder elementer som forretningsmodel (business case), nøgleprocesser og forbedringspotentiale (benefit realization), som definerer løsningens succesparametre.

Arkitektur er ikke en akademisk øvelse

Arkitekturarbejde som ikke er operationaliseret eller kan operationaliseres af andre, kan ikke betegnes som arkitektur. Det er akademiske øvelser, henstillinger, visioner eller dokumenter, som med stor sandsynlighed har størst værdi for forretningen i anden sammenhæng. “Rigtig” arkitektur giver grundlag for en praktisk implementering.

Arkitektur skal ikke være smuk – den skal være rigtig

Når vi taler om god arkitektur, er det altså ikke et spørgsmål om smag, men om løsningerne er hensigtsmæssigt struktureret i forhold til de opgaver de skal understøtte, og opfylder de overordnede målsætninger for den forretning, der skal bruge løsningerne.

Arkitektur giver ingen gevinster i sig selv

“Arkitektur” er ingen “silver bullet” eller frelsende Yourdon projektmodel, som giver løfte om umiddelbart målbare gevinster. Til gengæld er arkitekturarbejdet en god metode til at binde forretning og IT sammen på en måde, der sætter det positive samspil i fokus og giver mulighed for at høste nye fordele.

Din mening

Har du en anden mening om definitionen af enterprise arkitektur – eller en god forklaring at tilføje? Så skriv en kommentar nedenfor eller send os en mail.

Disciplinen “arkitektur” er inde i en udvikling, hvor der er utrolig stor efterspørgsel, men få klare og entydige definitioner, endnu færre målepunkter for kvalitet og succes. I samarbejdet med vores kunder sætter vi fokus på at få defineret arkitektur i kundens kontekst og i forhold til organisationens modenhed. Vi bidrager også med konkretisering af arkitektur funktionens mandat og rolle, så arkitekturprocessen placeres rigtigt i forhold til de eksisterende forretnings og IT-funktioner i kundens organisation.