May 2005 Archives
I dag fik jeg to nye interviews på plads.
I næste uge skal jeg snakke med Kåre Kjelstrøm om hans erfaringer i forbindelse med Sundhed.dk - med integration til CPR; medicin profil er sundhed.dk et glimrende eksempel på hvorledes man håndterer personfølsomme oplysninger i en arkitektur som er hen imod en SOA.
Men det er nu ikke så meget fortrolighedsspørgsmålet jeg vil tale med Kåre om. Min case omkring sundhed.dk kommer til at have brugerstyring som tema. Så vi kommer til at tale om motiver; Alternativer; Standarder; Identitetsstyring; Autentificering; Autorisation samt Brugerstyring.
Måske kan Kåre også lige fortælle hvorfor &/%%¤¤! at man ikke har kunne enes om række standardprincipper for sikkerhed. Den gamle CIA+A (confidentiality; Integrity; Availability+ Accountability) -Triade virker men er utilstrækkelig. Så hver gang den bliver nævnt er den blevet tillagt nye principper - men ikke på en standard måde så de skifter alt efter hvilken bog man læser.
Nå men tilbage til mit anden interview.
Om to uger skal jeg møde Henrik Pedersen - IT Chef i Gentofte Kommune og Steen Deth, Kommunens IT-arkitekt. Gentofte Kommune er en af de kommuner i Danmark som er længst fremme med it-arkitektur men det er nu ikke derfor jeg besøger dem. I et interview i computerworld i marts 2005 står Henrik Pedersen citeret for at tvivle KMDs motiver mht. ikke at ville indføre SOA i fbm. kommunalreformen - og det vil jeg da gerne høre mere om inden jeg tager ud og snakker med KMD.
Henrik Pedersen har efterfølgende sagt at han føler at kommentareren er grebet ud af kontekst, men ikke desto mindre vil hans indsigt kunne hjælpe mig i KMD interviewet - hvilket dog nok først bliver efter min EA eksamen d. 14. Juni.
Ud over KMD materiale er jeg også sikker på at Henrik og Steen kan give mig noget indsigt i en eventuel kommunal SOA-vision.
-----
Jeg ved at alle overnnævnte herrer er meget travle personer så jeg er virkelig glad for at de stiller op til et interview. I det hele taget synes jeg at det er utroligt at der endnu ikke er nogen som har sagt nej til et interview endnu.
Mht. til interviewene, så bliver de alle udsat for "meningskondensering" mindst 24 timer efter de er foretaget. Men jeg synes ikke helt jeg kan overkomme også at nedfælge det i en blog som jeg ellers gjorde i starten. Så skulle jeg nok have administreret min tid lidt bedre ;)
I næste uge skal jeg snakke med Kåre Kjelstrøm om hans erfaringer i forbindelse med Sundhed.dk - med integration til CPR; medicin profil er sundhed.dk et glimrende eksempel på hvorledes man håndterer personfølsomme oplysninger i en arkitektur som er hen imod en SOA.
Men det er nu ikke så meget fortrolighedsspørgsmålet jeg vil tale med Kåre om. Min case omkring sundhed.dk kommer til at have brugerstyring som tema. Så vi kommer til at tale om motiver; Alternativer; Standarder; Identitetsstyring; Autentificering; Autorisation samt Brugerstyring.
Måske kan Kåre også lige fortælle hvorfor &/%%¤¤! at man ikke har kunne enes om række standardprincipper for sikkerhed. Den gamle CIA+A (confidentiality; Integrity; Availability+ Accountability) -Triade virker men er utilstrækkelig. Så hver gang den bliver nævnt er den blevet tillagt nye principper - men ikke på en standard måde så de skifter alt efter hvilken bog man læser.
Nå men tilbage til mit anden interview.
Om to uger skal jeg møde Henrik Pedersen - IT Chef i Gentofte Kommune og Steen Deth, Kommunens IT-arkitekt. Gentofte Kommune er en af de kommuner i Danmark som er længst fremme med it-arkitektur men det er nu ikke derfor jeg besøger dem. I et interview i computerworld i marts 2005 står Henrik Pedersen citeret for at tvivle KMDs motiver mht. ikke at ville indføre SOA i fbm. kommunalreformen - og det vil jeg da gerne høre mere om inden jeg tager ud og snakker med KMD.
Henrik Pedersen har efterfølgende sagt at han føler at kommentareren er grebet ud af kontekst, men ikke desto mindre vil hans indsigt kunne hjælpe mig i KMD interviewet - hvilket dog nok først bliver efter min EA eksamen d. 14. Juni.
Ud over KMD materiale er jeg også sikker på at Henrik og Steen kan give mig noget indsigt i en eventuel kommunal SOA-vision.
-----
Jeg ved at alle overnnævnte herrer er meget travle personer så jeg er virkelig glad for at de stiller op til et interview. I det hele taget synes jeg at det er utroligt at der endnu ikke er nogen som har sagt nej til et interview endnu.
Mht. til interviewene, så bliver de alle udsat for "meningskondensering" mindst 24 timer efter de er foretaget. Men jeg synes ikke helt jeg kan overkomme også at nedfælge det i en blog som jeg ellers gjorde i starten. Så skulle jeg nok have administreret min tid lidt bedre ;)
Webservices.org has been a faithful supplier of material for my thesis. I've found many interesting and insightful articles there in their staggering repository of weblogs and papers.
One of very interesting readings on webservices.org is the survey From Web Services to SOA and Everything in Between: The Journey Begins . The survey illustrates through 38 pages of interesting data the current usage of WebServices and SOA among 1.000 companies in Europe and the US.
More than 1/3 of companies say that they turn to webservices to Integrate disparate systems .. and that is exactly what what the organisations are getting. 55% of respondents state that Better integration between systems and Better reuse of services are the two key benefits of Web services and SOA deployments.
Not all figures can be taken as such - it's argued that 35% of businesses have or plan to have a fully functioning Web services infrastructure in the near future. At this point, about 18% were to be considered "SOA-ready," meaning they were part of an infrastructure of standardized, loosely coupled services. For most companies, the hard work still lies ahead. About 24% have simple point-to-point implementations, and 29% are still in the development stages.
This may sound incredible and it is misleading (as the report points out) - because the companies are selected from the member lists of webservices.org - hence they're already interested in SOA and webservices.
In relation to my thesis on Security aspects in SOA I was supported in my perception that security is a major concern. The study divided the repondents into two groups - beginners and advanced. While the major concern - maturity of standards differed between the two groups, concerns over security were consistently high at 68% - a very interesting thing.
I personally found that I needed a survey like this to establish the usage of Web Services and SOA in the real life.
One of very interesting readings on webservices.org is the survey From Web Services to SOA and Everything in Between: The Journey Begins . The survey illustrates through 38 pages of interesting data the current usage of WebServices and SOA among 1.000 companies in Europe and the US.
More than 1/3 of companies say that they turn to webservices to Integrate disparate systems .. and that is exactly what what the organisations are getting. 55% of respondents state that Better integration between systems and Better reuse of services are the two key benefits of Web services and SOA deployments.
Not all figures can be taken as such - it's argued that 35% of businesses have or plan to have a fully functioning Web services infrastructure in the near future. At this point, about 18% were to be considered "SOA-ready," meaning they were part of an infrastructure of standardized, loosely coupled services. For most companies, the hard work still lies ahead. About 24% have simple point-to-point implementations, and 29% are still in the development stages.
This may sound incredible and it is misleading (as the report points out) - because the companies are selected from the member lists of webservices.org - hence they're already interested in SOA and webservices.
In relation to my thesis on Security aspects in SOA I was supported in my perception that security is a major concern. The study divided the repondents into two groups - beginners and advanced. While the major concern - maturity of standards differed between the two groups, concerns over security were consistently high at 68% - a very interesting thing.
I personally found that I needed a survey like this to establish the usage of Web Services and SOA in the real life.
Min problemstilling har levet et omtumlet liv, men er nu igennem de hårde "teenage år" og jeg ser dette som den modne og kraftfulde problemstilling som i store træk vil holde til slut.
Diskuter hvorledes den serviceorienterede arkitektur påvirker it-sikkerheden og opstil på baggrund af undersøgelsesresultatet en referenceprofil for sikker implementering af serviceorienterede arkitektur.
Som en præcisering af min problemformulering har jeg opstillet en række udfordrende hypoteser som skal udgøre en ledetråd i forhold til det som jeg mere præcist ønsker var på
Diskuter hvorledes den serviceorienterede arkitektur påvirker it-sikkerheden og opstil på baggrund af undersøgelsesresultatet en referenceprofil for sikker implementering af serviceorienterede arkitektur.
Som en præcisering af min problemformulering har jeg opstillet en række udfordrende hypoteser som skal udgøre en ledetråd i forhold til det som jeg mere præcist ønsker var på
- H1: SOA og it-sikkerhed er komplementære, frem for at være to modstridende begreber hvilket de ofte behandles som. En "korrekt" indført SOA er samtidig en arkitektur som er mere sikker i at modstå trusler imod virksomheden.
- H2: Åbne standarder er vejen frem for sikker SOA bl.a. fordi gennemsigtigheden i standarder samtidig sikrer et større anvendelsesområde.
- H3: Der findes ikke i dag nogen standard måde at lave sikker SOA, men der findes allerede en række "værktøjer" som i det rette mix kan sammensættes på en sikker måde.
Jeg har for alvor kastet mig ind i mine case-studies.
Jeg tager fat i 3-5 virksomheder eller organisationer og bruger dem hver især som cases som repræsenterer et specifikt fokusemne. På denne måde får jeg skabt den bredde som jeg ikke mener jeg vil kunne opnå ved at fokusere på een bestemt virksomhed - (der er i øvrigt ingen danske virksomheder som sidder inde med netop alle sikkerhedsproblematikkerne) - desværre giver jeg derved afkald på lave noget sammenlignende analyse på tværs af cases som min
indenfor min teorbehandling hvorved jeg kan understøtte metodebog ellers foreslår.
Kun een af case-virksomhederne er endnu helt på plads og det er lægemiddelstyrelsen som har brugt webservices med stor success og skala i mange år.
Jeg var i den forbindelse ude i går (19.5.2005) og snakke med Kontorchef Lasse Larsen som har været med fra starten og kunne fortælle berette omkring motiverne og baggrunden bag deres løsning samt de sikkerhedsovervejelser de havde haft.
Stor tak til Lægemiddelstyrelsen for deres hjælp og støtte til kildeindsamlingen.
Jeg tager fat i 3-5 virksomheder eller organisationer og bruger dem hver især som cases som repræsenterer et specifikt fokusemne. På denne måde får jeg skabt den bredde som jeg ikke mener jeg vil kunne opnå ved at fokusere på een bestemt virksomhed - (der er i øvrigt ingen danske virksomheder som sidder inde med netop alle sikkerhedsproblematikkerne) - desværre giver jeg derved afkald på lave noget sammenlignende analyse på tværs af cases som min
indenfor min teorbehandling hvorved jeg kan understøtte metodebog ellers foreslår.
Kun een af case-virksomhederne er endnu helt på plads og det er lægemiddelstyrelsen som har brugt webservices med stor success og skala i mange år.
Jeg var i den forbindelse ude i går (19.5.2005) og snakke med Kontorchef Lasse Larsen som har været med fra starten og kunne fortælle berette omkring motiverne og baggrunden bag deres løsning samt de sikkerhedsovervejelser de havde haft.
Stor tak til Lægemiddelstyrelsen for deres hjælp og støtte til kildeindsamlingen.
Jeg har på det sidste gået og reflekteret over om Webservices er "moden" nok til large scale produktion
I mine samtaler har jeg opnået noget som jeg synes kunne tyde på en afklaring af spørgsmålet.
Og det må være at - ja - webservices er klar til stordrift. True - der kan være problemer når man pakker xml'en med en masse binær data som kort eller musik, men ren xml bliver så effektivt pakket ved forsendelse og udbuddet af bandwidth er så stort at der i dag stadig er masser af plads.
Jeg har været ude og besøge lægemiddelstyrelsen som kører noget der hedder "Det Centrale Tilskudsregister" CTR som er indberetning af medicin omkostning således at tilskud kan uddeles som følge heraf. Da systemet blev lavet i starten af 2000 anskaffede man sig ISDN linier ud til hver apotek - det var 64kbit - og i dag bruger man stadig ikke mere end 20% af kapaciteten.
Den 12. september 2003 var i alt 4.114.542 personers køb af tilskudsberettigede lægemidler registreret i CTR.
Der er gennemsnitligt ca. 300.000 transaktioner om dagen, fordelt på godt 3.000 kasseterminaler på de i alt ca. 280 danske apoteker. Systemet skal levere svartider på under 2 sekunder i 95% af tilfældene og i gennemsnit er svartiden under 0,5 sekund. I spidsbelastningssituationer håndteres flere end 70 transaktioner per sekund.
Så jeg er efterhånden blevet overbevist om at kan lade gøre at bruge WS til sine mere krævende applikationer - spørgsmålet kommer dog om man så også kan køre SOA i large scale. Ovenstående eksempel er en god indikator.
I mine samtaler har jeg opnået noget som jeg synes kunne tyde på en afklaring af spørgsmålet.
Og det må være at - ja - webservices er klar til stordrift. True - der kan være problemer når man pakker xml'en med en masse binær data som kort eller musik, men ren xml bliver så effektivt pakket ved forsendelse og udbuddet af bandwidth er så stort at der i dag stadig er masser af plads.
Jeg har været ude og besøge lægemiddelstyrelsen som kører noget der hedder "Det Centrale Tilskudsregister" CTR som er indberetning af medicin omkostning således at tilskud kan uddeles som følge heraf. Da systemet blev lavet i starten af 2000 anskaffede man sig ISDN linier ud til hver apotek - det var 64kbit - og i dag bruger man stadig ikke mere end 20% af kapaciteten.
Den 12. september 2003 var i alt 4.114.542 personers køb af tilskudsberettigede lægemidler registreret i CTR.
Der er gennemsnitligt ca. 300.000 transaktioner om dagen, fordelt på godt 3.000 kasseterminaler på de i alt ca. 280 danske apoteker. Systemet skal levere svartider på under 2 sekunder i 95% af tilfældene og i gennemsnit er svartiden under 0,5 sekund. I spidsbelastningssituationer håndteres flere end 70 transaktioner per sekund.
Så jeg er efterhånden blevet overbevist om at kan lade gøre at bruge WS til sine mere krævende applikationer - spørgsmålet kommer dog om man så også kan køre SOA i large scale. Ovenstående eksempel er en god indikator.
Microsoft har virkeligt taget web services til sig i den forestående version af Visual Studio med codename "Indigo".
Indigo er en samling af nye programmerings frameworks som til høj grad understøtter SOA i form af web services. Med vanlig sikkerhed udtalte en microsoft executive at dette kunne blive slutningen på at skrive kode - i stedet vil det bare være et spørgsmål om at sammensætte services.
Indigo sammensætter efter sigende de bedste features fra .NET, ASMX til en ensartet programmerings og administrations-model, men frem for at køre deres eget show er Indigo i højere grad bygget på standarder som HTTP, XML og SOAP (Web services).
Sikkerhedsmodellen for Indigo er opgivet som følgende:
1. beskedudveksling sikres igennem entiteter (fortrolighed)
2. entiteters adgang til ressourcer sikres (autenticitet og adgangskontrol)
3. alle forespørgsler til ressourcer af entiteter registreres (integritet)
Dette lyder jo meget simpelt og mapper sig fint op imod de-fakto CIA-treenigheds sikkerhedsmodellen.
En anden interessant ting er at Indigo bruger "credentials" til at foretage sikkerheden - dette er således et skridt væk fra "token security"
Microsoft ser credentials som
1. Claims (data omkring en entitet)
2. Issuer (kontrollerer og certificerer credentials)
3. Proof of prossession (hvordan en entitet beviser at det er dens claims)
Det lader til at MS Indigo træder et skridt imod en mere standardiseret sikkerhedsmodel (bl.a. imod federated identity) så det bliver spændende at følge udviklingen nærmere når produktet kommer på gaden. Dog var der i præsentationen mange forbehold og det lød til at der stadig var mange løse ender som skulle fixes før produktet var klar.
Indigo er en samling af nye programmerings frameworks som til høj grad understøtter SOA i form af web services. Med vanlig sikkerhed udtalte en microsoft executive at dette kunne blive slutningen på at skrive kode - i stedet vil det bare være et spørgsmål om at sammensætte services.
Indigo sammensætter efter sigende de bedste features fra .NET, ASMX til en ensartet programmerings og administrations-model, men frem for at køre deres eget show er Indigo i højere grad bygget på standarder som HTTP, XML og SOAP (Web services).
Sikkerhedsmodellen for Indigo er opgivet som følgende:
1. beskedudveksling sikres igennem entiteter (fortrolighed)
2. entiteters adgang til ressourcer sikres (autenticitet og adgangskontrol)
3. alle forespørgsler til ressourcer af entiteter registreres (integritet)
Dette lyder jo meget simpelt og mapper sig fint op imod de-fakto CIA-treenigheds sikkerhedsmodellen.
En anden interessant ting er at Indigo bruger "credentials" til at foretage sikkerheden - dette er således et skridt væk fra "token security"
Microsoft ser credentials som
1. Claims (data omkring en entitet)
2. Issuer (kontrollerer og certificerer credentials)
3. Proof of prossession (hvordan en entitet beviser at det er dens claims)
Det lader til at MS Indigo træder et skridt imod en mere standardiseret sikkerhedsmodel (bl.a. imod federated identity) så det bliver spændende at følge udviklingen nærmere når produktet kommer på gaden. Dog var der i præsentationen mange forbehold og det lød til at der stadig var mange løse ender som skulle fixes før produktet var klar.
Bea har netop offentliggjort en undersøgelse bland 1000 "Professionals" i amerikanske virksomheder... (Ud af hvilke 29% kaldte sig selv arkitekt..)
Undersøgelsen viste at SOA var kendt af 44% og det var kun til en grad af 1.76 - hvor eet var "basic understanding" af SOA og fire var en "very advanced" forståelse af SOA.
Læs resumeet her
Undersøgelsen viste at SOA var kendt af 44% og det var kun til en grad af 1.76 - hvor eet var "basic understanding" af SOA og fire var en "very advanced" forståelse af SOA.
Læs resumeet her
På baggrund af den tidligere artikel er jeg begyndt at ræsonnere over hvorvidt web-services er det klare valg i forhold til "availability".
Som det blev forklaret er det et problem hvis systemer går ned "due to heavy load" blot fordi standarden går hen imod at køre web services.
Så jeg ringede til Henrik Hvid som jo har skrevet en bog om SOA og som måske kunne lede mig imod nogle virksomheder som havde erfaringer med SOA uden Web services. Den eneste han kunne komme i tanke om var Danske Bank som har kørt SOA i mange år.
Men har de nu også det? - Vi tog en diskussion om hvorvidt det egneligt var SOA som DanskeBank kører fordi skal man tro side 68 i Henriks bog så skal der åbne standarder til et SOA og det kører Danske Bank ikke.
Man kan sige at Danske Bank tænker SOA men laver komponent baseret udvikling hvilket jeg i øvrigt også har hørt nogen sige før.
Så jeg spurgte om hvorvidt definitionen af SOA så var forkert men det mente han nu ikke og definitionen passer også ok med andre forklaringer på SOA som jeg har læst.
Spørgsmålet er derfor om de som går og siger at man har kørt SOA i rigtig mange år også har ret eller om det reelt bare har været en modul- / komponentbaseret it-arkitektur. Måske skal vi først til at køre rigtigt SOA nu. Det tror jeg er mere rigtigt fordi jeg har endnu ikke mødt nogle eksempler som har kunne sige at deres SOA:
Er Distribueret
Har Løse Koblinger
Er Processorienteret
og
Bygger på Åbne Standarder.
Men det kan jo være at jeg i mine søgning efter case-virksomheder bliver klogere.
For at vende tilbage til forvirringen omkring web services' anvendelighed i high load miljøer gav Henrik mig medhold i det faktum at der kommer successhistorier fra "begge lejre" - både dem som kører web services og så dem som har valgt en leverandørafhængig løsning.
Han forklarede at performance ikke er et stor problem når vi har at gøre med menneskelige interaktioner - om vi venter 1 eller 3 sekunder på at få svar fra en service gør ikke det store - men hvis web services og SOA skal vokse sig stor og stærk så må det være et krav at den også understøtter maskin-processerne.
Måske er vejen frem konverteringen af XML til binær kode. Men det ville være at sluge en stor kamel for XML-grundlaget. Det kan også være at Moore's lov og Bandwidth løser problemet inden det overhovedet når at blive et problem. Lidt mere at kigge på.
Som det blev forklaret er det et problem hvis systemer går ned "due to heavy load" blot fordi standarden går hen imod at køre web services.
Så jeg ringede til Henrik Hvid som jo har skrevet en bog om SOA og som måske kunne lede mig imod nogle virksomheder som havde erfaringer med SOA uden Web services. Den eneste han kunne komme i tanke om var Danske Bank som har kørt SOA i mange år.
Men har de nu også det? - Vi tog en diskussion om hvorvidt det egneligt var SOA som DanskeBank kører fordi skal man tro side 68 i Henriks bog så skal der åbne standarder til et SOA og det kører Danske Bank ikke.
Man kan sige at Danske Bank tænker SOA men laver komponent baseret udvikling hvilket jeg i øvrigt også har hørt nogen sige før.
Så jeg spurgte om hvorvidt definitionen af SOA så var forkert men det mente han nu ikke og definitionen passer også ok med andre forklaringer på SOA som jeg har læst.
Spørgsmålet er derfor om de som går og siger at man har kørt SOA i rigtig mange år også har ret eller om det reelt bare har været en modul- / komponentbaseret it-arkitektur. Måske skal vi først til at køre rigtigt SOA nu. Det tror jeg er mere rigtigt fordi jeg har endnu ikke mødt nogle eksempler som har kunne sige at deres SOA:
Er Distribueret
Har Løse Koblinger
Er Processorienteret
og
Bygger på Åbne Standarder.
Men det kan jo være at jeg i mine søgning efter case-virksomheder bliver klogere.
For at vende tilbage til forvirringen omkring web services' anvendelighed i high load miljøer gav Henrik mig medhold i det faktum at der kommer successhistorier fra "begge lejre" - både dem som kører web services og så dem som har valgt en leverandørafhængig løsning.
Han forklarede at performance ikke er et stor problem når vi har at gøre med menneskelige interaktioner - om vi venter 1 eller 3 sekunder på at få svar fra en service gør ikke det store - men hvis web services og SOA skal vokse sig stor og stærk så må det være et krav at den også understøtter maskin-processerne.
Måske er vejen frem konverteringen af XML til binær kode. Men det ville være at sluge en stor kamel for XML-grundlaget. Det kan også være at Moore's lov og Bandwidth løser problemet inden det overhovedet når at blive et problem. Lidt mere at kigge på.
Det har længe stået klart at SOA ikke er synonym med Web Services. Men fordi web services tilbydes som en åben standard er det naturligt at mene at vi skal gå imod denne implementationsform. Men at web services stadig er langt fra at være den ultimateive SOA-metode beskriver Jared Rodriguez i hans (corporate) blog under artiklen Basics som i hvert fald åbnede mine øjne.
Artiklen giver indsigt i Web services's performance (processering og bandwidth) vanskeligheder i forhold til bl.a. binære løsninger og selvom det langt fra er nogen videnskabelig undersøgelse så giver det stof til tanke om tidsaspektet for web services og er der alternativer - også rent sikkerhedsmæssigt.
Jeg ser et problem i at introducere sikkerhedsperspektivet til udviklere & it-arkitekter som allerede sidder og kæmper med at højne performance for web-service. I sådan et scenario er må sikkerhedsperspektivet tvinges eller sælges bedst muligt således at det ikke bliver udeladt.
Jared er i øvrigt indehaver af Skyway Software som sælger grafiske værktøjer til at bygge SOA samt diverse konsulentydelser dertil - han har netop landet en stor ordre i i fbm. at bygge SOA for British American Tobacco PLC som med tiden vil uskifte dele af deres Oracle, Microsoft og IBM værktøjer med Skyways SOA Builder.
Artiklen giver indsigt i Web services's performance (processering og bandwidth) vanskeligheder i forhold til bl.a. binære løsninger og selvom det langt fra er nogen videnskabelig undersøgelse så giver det stof til tanke om tidsaspektet for web services og er der alternativer - også rent sikkerhedsmæssigt.
Jeg ser et problem i at introducere sikkerhedsperspektivet til udviklere & it-arkitekter som allerede sidder og kæmper med at højne performance for web-service. I sådan et scenario er må sikkerhedsperspektivet tvinges eller sælges bedst muligt således at det ikke bliver udeladt.
Jared er i øvrigt indehaver af Skyway Software som sælger grafiske værktøjer til at bygge SOA samt diverse konsulentydelser dertil - han har netop landet en stor ordre i i fbm. at bygge SOA for British American Tobacco PLC som med tiden vil uskifte dele af deres Oracle, Microsoft og IBM værktøjer med Skyways SOA Builder.
I forbindelse med det nu afsluttede T8 EA-miniprojekt valgte min skrivepartner - Martin Wittrock Andersen og Jeg, at følge en opfordring fra "branchen" om at skrive om gamle ctr. nye rammeværk.
Jeg så miniprojektet som en mulighed for at gå i dybden med et nyt område omkring EA som lå udenfor mit speciale, hvilket jo altid kunne være brugbart når man skal ud og søge jobs. Derfor var det klart at de-fakto standarden - Zachmans Rammeværk for EA - skulle med i analysen.
Det var således ikke fra starten bevidst valgt at vi ville tage SOA ind i opgaven og jeg havde personligt ikke noget bevidst motiv for at dreje miniprojektet over i retning af mit speciale.
- hvad der derfor overraskede os var, omfanget af nye "moderne" rammeværker som havde SOA "stemplet" i bunden. faktisk lykkedes det os ikke at finde et nyere udviklet rammeværk (eller tilgange som de også til tider kaldes) som havde elementerne med løse koblinger, behændighed, brug af standarder etc.
Derfor var det da glædeligt for mig at opdage at ikke alt mit arbejde med T8 var spildt men at jeg nok vil kunne bruge nogle af de tanker jeg havde haft i begrebsafklaringen af SOA.
Jeg så miniprojektet som en mulighed for at gå i dybden med et nyt område omkring EA som lå udenfor mit speciale, hvilket jo altid kunne være brugbart når man skal ud og søge jobs. Derfor var det klart at de-fakto standarden - Zachmans Rammeværk for EA - skulle med i analysen.
Det var således ikke fra starten bevidst valgt at vi ville tage SOA ind i opgaven og jeg havde personligt ikke noget bevidst motiv for at dreje miniprojektet over i retning af mit speciale.
- hvad der derfor overraskede os var, omfanget af nye "moderne" rammeværker som havde SOA "stemplet" i bunden. faktisk lykkedes det os ikke at finde et nyere udviklet rammeværk (eller tilgange som de også til tider kaldes) som havde elementerne med løse koblinger, behændighed, brug af standarder etc.
Derfor var det da glædeligt for mig at opdage at ikke alt mit arbejde med T8 var spildt men at jeg nok vil kunne bruge nogle af de tanker jeg havde haft i begrebsafklaringen af SOA.
