mandag, september 18, 2006

Forretningen opnår bedre indsigt gennem serviceorienterede hændelser

Den sidste artikel diskutere hvordan en hændelsesbaseret SOA kan forøge virksomhedens udsyn til hvordan virkeligheden er i øjeblikket, frem for hvordan den så ud historisk.

Artiklen beskriver karakteristika ved stream computing og produkter til at behandle hændelsesstrømme (Event Stream Processing – ESP).

En hændelsesbaseret integrationsstrategi kan levere konsistent information hurtigt på tværs af virksomheden. Ofte er hændelsesdrevet integration den eneste måde at sikre konsistens, da mange hændelser kun giver mening, hvis de er opfanget præcis på det tidspunkt, hvor de skete. I mange virksomheder sker der større forsinkelser mellem, at en hændelse sker, og den er blevet identificeret af afdelingen, der skal håndtere den. Afhængig af hændelsestypen og dens vigtighed kan værdien af en hændelse formindskes proportionalt med den tid, der er gået, siden den skete. For visse hændelser er alt andet end øjeblikkelig behandling uacceptabel. For andre kan timer eller dage passere uden væsentlig forringelse af forretningsværdien. Hændelsesbaseret integration er essentiel for den første og kan repræsentere interessante, nye forretningsmuligheder for den sidste. Hændelsesbaseret integration skal derfor fokusere på hurtigt at få informationen, der beskriver hændelsen, hen til modtageren. Det skal ske så hurtigt, at værdien af hændelsen ikke degraderes.

Behovet for en beholder til metadata

Den næste artikel er et whitepaper, jeg har skrevet. Det behandler behovet for en metadata-beholder i en serviceorienteret arkitektur

Udfordringen til at styre virksomhedens SOA ligger i at levere en tilstrækkelig governance-infrastruktur uden at sætte behændigheden og fleksibiliteten af arkitekturen på spil. Hvis virksomheden vælger at fasttømrer deres governance-værktøjer og processer, vil den miste løftet om behændighed. Det er derfor nødvendigt at bygge fleksibilitet ind i selve governance-infrastrukturen. Hemmeligheden til at vedligeholde behændigheden ligger i metadata.

Mange virksomheder forsøger at håndtere denne metadata ved at bruge værktøjer såsom regneark, word-dokumenter eller Visio-diagrammer. For effektivt at kunne styre og håndtere mere komplekse systemer er det nødvendigt med en disciplineret proces til styring af metadata, der er understøttet af et Metadata Repository (MR) (Metadata-beholder).

BPM og SOA

I nogle artikler er der en diskussion omkring business process management BPMs i forhold til en SOA. Sandheden er, at BPM og SOA passer perfekt sammen og er afhængig af hinanden.

Hele budskabet omkring SOA er, at det i højere grad vil understøtte forretningen, at webservices er mere behændige end enkeltstående applikationer og det giver mulighed for at virksomheden hurtigere og bedre kan reagere på ændringer i efterspørgsel og markedsmuligheder. Det kan kun ske med en BPM, det er nødvendigt først at forstå virksomhedens forretningsprocesser, før man kan bygge services, der kan understøtte dem!
Uden BPM ved en SOA ikke hvad der skal bygges.

På den anden side er der heller ikke noget formål med at dokumenter og strømline virksomhedens forretningsprocesser uden en gennemgående metode for at levere nye services omkring dem!
Uden en SOA mangler BPM muligheden for at kunne ændre ting.

Tom Dwyers artikel om SOA og BPM giver et godt indblik i behovet for SOA og BPM sammen

fredag, september 08, 2006

Killerapplikationen for Web Services

Jonathan Sapir diskutere i denne artikel hvad der kendetegner en killerapplikation, det vil sige den applikation der får brugen af en teknologi til at eksplodere. Han nævner som eksempel spreadsheet for den personlige computer og browseren for internettet.

Han vurderer at Web Service- killerapplikationen vil være en Personal Service Builder (PSB). En PSB vi opfylde videnarbejderens behov for fleksibelt at kunne sammensætte services efter personlige behov og markedets krav om øjeblikkelig reaktion på ændrede situationer.

Jonathan Sapirs artikel kan findes her

Er UDDI den grimme ælling?

Jason Bloomberg diskutere hvordan UDDI i dets tidlige barndom blev betragtet som den grimme ælling som ingen kunne se behovet for. "Det vil være alt for bedrøveligt at fortælle al den nød og elendighed, den måtte prøve i den hårde vinter." Men nu ser det endelig ud til, at nogle har fået øjnene op for dets skønhed.

It-arkitekter har indset, at styrken i UDDI ligger i dets rolle i en SOA, som en nøglestandard der hjælper virksomheder med at realisere den løse kobling ved at understøtte placeringsuafhængigheden. Derved implementeres abstraktionslaget, som services repræsenterer i en SOA.

Informationen til UDDI’en er ikke indsamlet. Det er virksomhederne selv, der skal indtaste relevant information om dem og deres Web Service. Det kan godt være et stykke software eller en tredje part, der gør dette på virksomhedens vegne, men det vigtige er, at det er virksomheden, der er ansvarlig for indholdet. En UDDI kan derfor bruges til at se, hvilke services en specifik virksomhed tilbyder, og til at identificere de parametre, der bruges, for at en partner hurtigt kan bygge eller konfigurere et interface til at tilgå Web Servicen.

Kvaliteten af indholdet i UDDI’en er derfor afhængigt af, at virksomhederne har en interesse i, at UDDI’en indeholder korrekt information, og at de har velfungerende procedurer, der sikrer, at deres information altid er opdateret og korrekt. En af udfordringerne for UDDI er at præsentere en business case for virksomhederne, så de er villige til at investere ressourcer i at holde deres information opdateret. Det er et klassisk hønen eller ægget-princip, hvor ingen vil bruge UDDI’en, fordi der ikke er kvalitetsindhold i den, og ingen vil ofre ressourcer på at lægge indhold ind, fordi ingen bruger UDDI. For at UDDI’en bliver en succes skal det være en lige så vigtig parameter for virksomheden, at den har korrekt information i UDDI’en, som at den har korrekt og veldesignet layout på sin hjemmeside.

Det vil kræve nogle medarbejdere med ansvar for kvaliteten af virksomhedens UDDI-poster. Først når sådanne etiske regler er til stede, vil virksomheder turde bruge Web Services fra velrenommerede virksomheder, som de finder i UDDI’en.

Jason Bloombergs artikel findes her

Fordelen ved at bygge applikations- sikkerhed ind i infrastrukturen

Paul O'Connor diskuterer i denne artikel muligheden for, at Web Services og WS-Security standarderne vil være et paradigmeskifte i hvordan applikationer kan sikres.

Han argumenterer for hvorledes det vil være muligt at inkludere finkornede politikker og datasikkerhed i sikkerhedsinfrastrukturen frem for i applikationskoden.

Hvor hurtigt en Formel 1-racerkører kører ind i et sving afhænger ikke af motorens størrelse, men af hvor gode bremserne er. Jo bedre de er, jo senere skal der bremses, og jo bedre klarer racerkøreren sig i konkurrencen. Virksomheden kan kun operere fleksibelt, hvis den ved, at sikkerheden er i stand til at følge med. Det er nødvendigt at opbygge sin sikkerhedsinfrastruktur lige så fleksibelt, som man ønsker sin forretning skal være.

Selvom Web Services tilføjer en ekstra dimension til sikkerhedsspørgsmålet, opbygger de også et nyt paradigme for at levere en gennemgående sikkerhedsservice på en konsistent og omkostningseffektiv måde på tværs af hele organisationen. De vil derfor på sigt selv være med til at løse problemet. Ved at opbygge en samlet sikkerhedsinfrastruktur, som leverer sikkerheds-Web Services , der kan forbruges af andre Web Services på tværs af organisationen og mellem handelspartnere, bliver det lettere at benytte sikkerhedsfunktionaliteter såsom autentificering, autorisation og kryptering. Det må forventes, at disse sikkerheds-Web Services vil blive brugt på et større antal ressourcer, end det er praktisk og økonomisk muligt i dag, fordi det vil være lettere for ikke-uddannede at benytte disse.

Paul O'Connors artikel findes her

torsdag, september 07, 2006

XMLs kompleksitet introducerer sikkerhedsrisici

Michael S. Mimoso hævder i denne artikel at XML sikkerhed i dag ikke drejer sig om crackers, ondsindet kode og lignende men om at fjerne kompleksiteten og den medfølgende performance-degradering, som introduceres af tunge autentifikationsmetoder.

Kravene til sikkerhed må ikke sætte noget krav til kunden/partneren om brug af specielle sikkerhedsløsninger. Det er et helt fundamentalt princip inden for Web Services, at alle partnerne skal kunne beholde deres eksisterende systemer, og standarderne vil så sikre, at de individuelle systemer kan arbejde sammen. Ved at integrere gennem abstraktionen af en enkelt sikkerhedsmodel gør man det muligt for virksomheder at udnytte deres eksisterende investering i sikkerhedsteknologi, samtidig med at man kan kommunikere med virksomheder, som bruger en anden teknologi. Langt det meste af tiden bruges sikkerhedssystemet internt, og det vil derfor være uøkonomisk at skulle lave specielle løsninger, når man skal kommunikere med eksterne partnere.

Selvom en virksomhed har lagt en stærk ring rundt omkring virksomheden, som forhindrer angreb udefra, er problemet med angreb indefra ikke håndteret. Disse angreb er ofte de mest skadelige og foretages af personer, der allerede har adgang til interne systemer. Derudover er få applikationsprogrammører blevet trænet inden for sikkerhed. Efterhånden som Web Services bliver lettere at udvikle og implementere, vil flere og flere ikke-sikkerhedsuddannede udviklere bruge dem, hvilket igen kan kontrolleres bedst ved at tage sikkerhedsspørgsmålene ud af programmørens hænder og i stedet håndtere dem separat.

Selvom Web Services tilføjer en ekstra dimension til sikkerhedsspørgsmålet, opbygger de også et nyt paradigme for at levere en gennemgående sikkerhedsservice på en konsistent og omkostningseffektiv måde på tværs af hele organisationen. De vil derfor på sigt selv være med til at løse problemet. Ved at opbygge en samlet sikkerhedsinfrastruktur, som leverer sikkerheds-Web Services , der kan forbruges af andre Web Services på tværs af organisationen og mellem handelspartnere, bliver det lettere at benytte sikkerhedsfunktionaliteter såsom autentificering, autorisation og kryptering. Det må forventes, at disse sikkerheds-Web Services vil blive brugt på et større antal ressourcer, end det er praktisk og økonomisk muligt i dag, fordi det vil være lettere for ikke-uddannede at benytte disse.

Michael S. Mimosos artikel kan findes her

Hurtig udvikling af forretningsapplikationer med SOA

John McDowall diskutere i denne artikel tre koncepter som virksomheden skal kunne håndtere for at udnytte SOAs løfter om behændighed, mindre risici og hurtigere implementering. De tre koncepter udgør:

- Løs kobling,
- Delt infrastruktur og services og
- Mere simpel udviklingsmodel

Den løse kobling giver virksomheden mulighed for at forbinde sig til partnerne, samtidig med at integriteten af ens systemer er bibeholdt, og indkapsle dem fra uundgåelige uforudsigelige ændringer. En virksomheds behændighedsgrad afhænger af, hvor løst koblet den er i stand til at samarbejde med partnere.

Den løse kobling ofrer helt bevidst optimeringen mellem de enkelte komponenter for at opnå fleksibel interoperabilitet mellem systemer, som er forskellige i teknologi, placering, ydeevne og tilgængelighed. En løst koblet applikation isoleres fra interne ændringer af andre applikationer ved at bruge abstraktioner og sen binding i interfacet mellem applikationer. I forhold til traditionelle tæt koblede applikationer er målet med en løst koblet applikation at forøge genbrugeligheden og tilpasningen til det uforudsete.

Løs kobling er en måde at designe og udvikle på – det er ikke en teknologi. Hele dette paradigmeskifte kræver en omskoling af virksomhedens udviklere samt revidering af udviklingsstrategier og metoder. For mange vil det føles unaturligt ikke mere at skulle fokusere på let målbare fordele såsom performance, men i stedet udvikle til at optimere det mere abstrakte begreb fleksibilitet. Man skal til at lære at udvikle løst koblet, eventbaseret og til generelle standarder, ikke direkte til en anden virksomheds system. En ikke ubetydelig udgift og et område, hvor ændringsmodstanden i organisationen kan være høj. Arkitekters og udvikleres forståelse og udnyttelse af løs kobling vil imidlertid mere end noget andet være afgørende for succesfuld ekstern forretningsprocesintegration.

Artiklen findes her

Standing up for UDDI

I dette interview med Luc Clement, co-chair på OASIS UDDI diskuteres fremtidsperspektiverne for UDDI. Hans væsentligste budskab er, at uden et centralt register såsom UDDI kan en virksomhed ikke lave en SOA, derfor ser han også en stigende interesse for UDDI.

En vigtig pointe omkring UDDI er, at informationen til UDDI’en ikke er indsamlet. Det er virksomhederne selv, der skal indtaste relevant information om dem og deres Web Service. Det kan godt være et stykke software eller en tredje part, der gør dette på virksomhedens vegne, men det vigtige er, at det er virksomheden, der er ansvarlig for indholdet. En UDDI kan derfor bruges til at se, hvilke services en specifik virksomhed tilbyder, og til at identificere de parametre, der bruges, for at en partner hurtigt kan bygge eller konfigurere et interface til at tilgå Web Servicen.

Kvaliteten af indholdet i UDDI’en er derfor afhængigt af, at virksomhederne har en interesse i, at UDDI’en indeholder korrekt information, og at de har velfungerende procedurer, der sikrer, at deres information altid er opdateret og korrekt. En af udfordringerne for UDDI er at præsentere en business case for virksomhederne, så de er villige til at investere ressourcer i at holde deres information opdateret. Det er et klassisk hønen eller ægget-princip, hvor ingen vil bruge UDDI’en, fordi der ikke er kvalitetsindhold i den, og ingen vil ofre ressourcer på at lægge indhold ind, fordi ingen bruger UDDI. For at UDDI’en bliver en succes, skal det være en lige så vigtig parameter for virksomheden, at den har korrekt information i UDDI’en, som at den har korrekt og veldesignet layout på sin hjemmeside. Det vil kræve nogle medarbejdere med ansvar for kvaliteten af virksomhedens UDDI-poster. Først når sådanne etiske regler er til stede, vil virksomheder turde bruge Web Services fra velrenommerede virksomheder, som de finder i UDDI’en.

Interviewet med Luc Clement findes her

onsdag, september 06, 2006

Web Service og "the Grid"

Rickland Hollar diskuterer i denne artikel implikationerne af at "the Grid" og Web Services smelter sammen. Det betyder helt konkret, at visionerne for "the Grid" bliver opfyldt af de kommende Web Service standarder.


Grid Services er Web Services, der tilbyder et veldefineret antal basale funktionaliteter. Den generelle værditilvækst, som Grid Services tilbyder i forhold til Web Services, er:

- En sofistikeret sikkerhedsinfrastruktur
- En standard serviceopstartsmekanisme til at kunne styre og overvåge servicen i hele dets levetid
- Håndtering af servicens tilstand
- En standard serviceforespørgselsmekanisme.


Grid Services er startet ved brug af en "service fabrik" mekanisme. Når en applikation skal bruge en Grid Service, kontakter den en "fabrik" og anmoder om en instans af servicen. "Fabrikken" danne en serviceinstans og giver applikationen en reference til denne instans. Denne standard mekanisme muliggør sofistikerede serviceovervågningsmekanismer.
Styring af servicen over hele dens levetid sikrer, at servicen er "ryddet op", når der ikke længere er brug for den. Hver service opstart indikerer hvor lang tid, der vil være brug for servicen. Hvis en klientapplikation går ned eller holder op med at kommunikere med en service, vil servicen og alle de ressourcer den bruger automatisk blive ryddet op, når livstiden udløber. Applikationer kan udvide livstiden af en service.

Håndtering af servicens tilstand tillader Grid Services at holde styr på tilstanden mellem forskellige anmodninger. I stedet for at tilbyde et anmod/svar interface som de fleste Web Services gør i dag, er Grid Services vedholdende i hele deres levetid og muliggør forbindelsesløse interaktioner, multiple klientforbindelser og håndtering af fejl på klientsiden.

Grid Service tilbyder et standardinterface for applikationer og andre services til at forespørge om deres interne tilstand. For eksempel: en service, der udfører computerbehandling, kan tilbyde et interface for forespørgsel om tilstand af de behandlinger, der er i gang, den type af system hvor behandlinger udføres og hvilke typer af forespørgsler, der vil blive honoreret. Alle disse ville bruge en standard forespørgselsmekanisme leveret af alle Grid services. Denne information kan blive samlet ved brug af standard "push and pull" mekanismer til mange formål. For eksempel en dynamisk oversigt over tilgængelige services, samlet information over tilgængelige computerkraft, grafisk overblik der viser placering og karakteristik af lokationer og services i en Grid osv.

Rickland Hollars artikel kan findes her

At tilføje Web Services til en eksisterende arkitektur, giver ikke en SOA

Thomas Erl tager i sin blog fat på en helt central udfordring, når virksomheden skal opbygge en SOA. Det er rimeligt simpelt at lægge et Web Service lag ovenpå ens eksisterende applikationer, men en veldesignet SOA kræver, at man sætter sig udover ens eksisterende applikationsportefølje og designer serviceorienterede, forretningscentrerede services.

Web Services åbner døren til nye integrationsmuligheder, og hver Web Service kan potentielt blive en vigtig del af virksomhedens it-infrastruktur. Det sætter krav til kvaliteten af det interface, der tilbydes. Selvom Web Services er klassificeret som en løst koblet teknologi, kan den omfattende integration i virksomheden stadig medføre mange afhængigheder af serviceinterfacet. At ændre et interface, efter det er blevet etableret, kan være en omkostningsfuld og uoverskuelig opgave, især i miljøer, der udnytter samlinger af services. Et solidt kendskab til forretningsmodellen, som servicen skal fungere i, de teknologier, den skal understøtte, SOA-designstrategier og tilhørende standarder er vigtige komponenter i en Web Service-implementeringsplan.

Blogen findes her

UBL har revolutionære implikationer

Tirsdagens (uge 46 - 2004) ratifikation af Universal Business Language (UBL) som en OASIS standard vil have væsentlig indflydelse på forretningsverdenen.

UBL er et bibliotek for XML-forretningsdokumenter (indkøbsordrer, fakturaer osv.). Intentionen er, at UBL skal være en international standard for elektronisk handel let og gratis tilgængelig for alle. Standarden vil hjælpe mindre og mellemstore virksomheder lave overgangen fra papirhandel til elektronisk handel uden store investeringer i EDI.

UBL er en standard implementering af ebXML. EbXML bruger XML til sikker udveksling af forretningsdata. Det understøtter eksisterende internetstandarder og kan køre på alle platforme og tilbyder en infrastruktur, der garanterer datainteroperabilitet, semantik der sikre kommerciel interoperabilitet og mekanismer der hjælper handelspartnere med at finde hinanden. Kort sagt tilbyder ebXML en XML-baseret infrastruktur, der muliggør EDI funktionalitet over internettet. UBL leverer et standard dataformat for beskeder, der skal udveksles i en sådan infrastruktur.

For at reducere opgaven med e-handelsstandardisering til håndterbare størrelser, differentiere UBL datastandardiserings-problematikken fra processtandardiserings-problematikken. UBL fokuserer på standardisering af forretningsdata som det første trin mod global e-handel integration og overlader standardisering af forretningsprocesser til industriorganisationer og brugergrupper. Derved vil procesdefinitionerne blive håndteret i et separat lag i stakken. En sidegevinst er, at det gør UBL brugbar for den bredest mulige vifte af procesdefinitionsteknologier.

UBL er opbygget udvidelsesbart og det forventes at industrieksperter vil opbygge egne industrispecifikke versioner af UBL dokumenter. Den værdi UBL tilføjer her, vil være en reduktion i omkostningerne for at lave sådanne dokumenter og maksimere genbrug.
Det offentlige Danmark har valgt at bruge Universal Business Language (UBL) som standard for e-handel i den offentlige sektor. Ved valg af en global standardmetode er udgifter til etablering af interface mellem offentlige institutioner og leverandører reduceret. Det gør det mere attraktivt og lettere for mindre virksomheder og internationale foretagender at deltage.

UBL hjemmesiden findes her

Sir Tim Berners-Lees forventninger omkring Semantic Web

Mark Frauenfeld har interviewet Tim Berners-Lee om status på Semantic Web.
Semantic Web er det næste trin på interoperabilitetsstigen. Internetstandarderne har forbundet maskinerne, Web Service-standarderne forbinder applikationerne og Semantic Web-standarderne vil forbinde informationen.

Semantic Web drejer sig om at opbygge en infrastruktur, hvor information fra forskellige kilder, kan blive integreret dynamisk for at udføre nogle opgaver. Semantic Web leverer mekanismer, der muliggør integration af informationer. Data er ikke det samme som information. Data bliver information, når det kan forstås. Data med tilhørende metadata til beskrivelse af dets betydning, bliver information der kan behandles af en computer.

En af de mest spændende ting ved Internettet er, at det er så mange forskellige ting for så mange forskellige personer. Den kommende Semantic Web vil multiplicere denne mangesidighed tusinder af gange. For nogle vil den afgørende feature af Semantic Web være letheden hvormed ens PDA, bærbare, kontor PC, server og ens bil vil kommunikere med hinanden. For andre vil det være automatiseringen af virksomhedsbeslutninger, der tidligere skulle udarbejdes i hånden. For andre igen vil det være muligheden for at tilgå troværdigheden af dokumenter på nettet og den lethed hvormed man vil kunne finde svar på spørgsmål. Lige meget hvad grunden er, vil alle kunne finde en grund til at understøtte visionen om Semantic Web.

Mark Frauenfelds interview findes her

SOBA vil revolutionere applikationsintegrationen

Michael S. Mimosos artikel "Gartner: SOBAs will revolutionize Application integation" diskuterer hvordan leverandører, der ikke er klar til at levere deres applikationer som services, vil forsvinde.

Budskabet er ikke, at store, integrerede standardsystemer forsvinder, men leverandørens løsninger skal være mere fleksible og åbne over for andre leverandører end de nuværende monolitiske løsninger, og de skal kunne implementeres mere pragmatisk.

Glenn Petersen sendte mig for nylig en mail, som er værd at overveje i hele diskussionen omkring SOAs muligheder for mindre afhængighed af leverandørerne. Han skriver bl.a. "Man kan sagtens forestille sig en service, som er løst koblet ud fra en teknisk synsvinkel, men tæt koblet forretningsmæssigt. Som eksempel kan nævnes SAP, som udstiller sin forretningslogik som løst koblede (Web) services (eller i det mindste har planer om at gøre det). Da de annoncerede deres plan om at gøre det, faldt deres aktiekurser straks, fordi analytikere så det som en risiko, at man nu gjorde SAP kunderne mere frie i deres valg af leverandør. Hvad det imidlertid tegner til er, at de udstillede services faktisk låser kunderne endnu mere end tidligere. For nu kan kunderne integrere SAP i deres egne IT-løsninger, hvilket gør, at det faktisk bliver sværere at udskifte SAP."

Michael S. Mimosos artikel findes her

Betaling for Web Services

Phil Wainewright tager i sin blog "Amazon to charge for services" udgangspunkt i Amazons annoncering af Alexa Web Information Service (AWIS). Amazon vil kræve betaling og han diskuterer hvordan betaling af indhold via mikrobetalinger vil være anderledes end betaling for brug af services

At forstå hvordan man skal tjene penge på sine services, bliver en proces, hvor der skal opnås mange erfaringer og det er positivt at se, at førende e-business virksomheder som Amazon, begynder at opnå erfaringer med betalingsmodeller. Erfaringer som andre kan have glæde af.
Han skal dog være opmærksom på at har man noget af værdi, så vil folk og virksomheder gerne betale for det, og bare fordi vi snakker Web Services, behøver afregningen ikke være specielt avanceret

Den største brug af Web Services vil ske mellem virksomheder. Her vil Web Services primært bruges inden for allerede indgåede aftaler. Ideen om, at ukendte og perfekt beskrevne Web Services eksisterer et eller andet sted derude, som skal kunne opdages, skræddersyes og være pålidelige nok til at bygge sin forretning på, beskriver kun en lille og ubetydelig del af mulige services. I realiteten vil de fleste værdifulde Web Service-interaktioner blive udført mellem kendte og troværdige forretningspartnere. Først når to parter har opbygget relationer, eventuelt indirekte via en troværdig tredjepart, vil teknologierne for automatiseret opdagelse bruges til at offentliggøre, finde og muliggøre nye services mellem dem samt forbinde nye versioner af eksisterende services, og her er afregningsdelen lettere håndteret.

"Det kan forventes, at det vil være et kundekrav, at it-leverandørernes løsninger skal være interoperable. It-leverandørernes kunder vil opleve, at deres egne kunder ønsker at få adgang til information på mange forskellige måder. For at være konkurrencedygtig må de tilbyde kunderne en simpel måde at tilgå deres information. Derved vil de sætte krav til deres it- leverandører om, at deres løsninger overholder standarder, så de bliver interoperable."
Phil Wainewrights blog findes her

Introduktion til forbunden troværdighed

Preston Gralla præsentere i disse to artikler begrebet "forbunden troværdighed" og de tilhørende standarder.
Mange partnere vil være involveret i en Web Service-model. Det er derfor nødvendigt, at brugeridentitet og tilhørende information kan deles mellem mange virksomheder, samtidig med at brugerens information og hver enkelt virksomheds unikke relationer med brugeren beskyttes. Hvis adgang til en Web Service skal besluttes, baseret på informationer om slutbrugeren, må denne Web Service have adgang til information, der gør den i stand til at træffe denne autorisationsbeslutning . Oplysninger om identiteten på brugeren er ikke nødvendig, relevant autorisationsinformation er tilstrækkeligt. Da hvert led i en Web Services proces kan være ejet af forskellige enheder, må det forventes, at de har hver deres modeller, systemer og standarder for autentificering. For at disse Web Services kan arbejde sammen, må der være troværdige mekanismer, hvormed disse adskilte modeller kan udveksle identiteter. Da autentifikationsmodeller kan variere, må et sådan system også være løst koblet. Godt designede Web Services skal være fleksible i forhold til deres forventninger omkring andre systemers autentifikationsmodeller.
I en proces, der involverer adgang til flere systemer, bør det ikke være situationen, at brugeren skal autentificere sig, hver gang en SOAP-anmodning skal sendes på dets vegne. Udfordringen med at levere denne funktionalitet betegnes som single sign-on eller federated trust (forbunden troværdighed).
Forbundne systemer kan samarbejde på tværs af organisatoriske grænser. Disse systemer kan bygge på forskellige teknologier, forskellige sikkerhedstilgange og programmeringsmodeller. De er autonome forstået på den måde, at de har kontrol over deres egen ”ø”, men er bygget til at samarbejde med andre systemer.
Forbunden identitet er muligheden for sikkert at kunne genkende og forstå en brugers identitet ejet af andre organisationer uden at kræve, at brugeren indtaster navn og password, når han skal have adgang til ens hjemmeside eller Web Service.
Det tillader også organisationen på en sikker måde at dele konfidentielle brugeridentiteter med andre troværdige organisationer samt applikationer på internettet. Når man sikkert kan stole på identiteter fra andre organisationer, og disse organisationer kan stole på de identiteter, som man selv danner, forøges behændigheden i hele værdikæden.
Preston Grallas artikel findes her

SOA, BPM og Event-driven arkitektur

denne pressemeddelelse tager Gartner fat på tre områder: Kombinationen af Business Process Management og SOA, behovet for at opnå erfaring nu for at kunne håndtere SOA når det bliver maninstream i 2007 samt Event-driven arkitektur.

Virksomheder vil gennemløbe tre Web Services-stadier, før de er blevet til en behændig virksomhed: et organisk , et systematisk og et altgennemtrængende stadie.

Det er essentielt, at man begynder med at opnå noget erfaring med Web Services og konstant har et par Web Services-projekter kørende, som langsomt bliver mere og mere komplekse, indtil man behersker udviklingen af Web Services fuldstændigt. Lad være med at serviceorientere alting, før organisationen har opbygget tilstrækkelig viden. Begræns de første projekter til lav-risiko projekter , indtil udviklerne opnår en tilstrækkelig viden om, hvordan Web Services bedst udnyttes i virksomhedens miljø.

De første pilotprojekter bør være processer, der er rimelig godt forstået, rimeligt simple og har veldokumenteret semantik. Det er også vigtigt at huske, at omkostninger og kompleksiteten varierer, afhængig af hvilket miljø der vælges. F.eks. vil eksterne Web Services ofte være vanskeligere at designe end interne, fordi det udvidede omfang introducerer nogle yderligere udfordringer:
Den organiske fase er karakteriseret ved to ting, henholdsvis
uddannelse, hvor virksomheden ikke får nogen fordele af Web Services, men bruger det meste af tiden på at undersøge, hvad andre gør med Web Services, og afprøve offentlige Web Services, samt
eksperimenter, hvor man typisk har et begrænset antal Web Services i produktion, og kun en mindre gruppe af udviklere er dedikeret til disse projekter. Her handler det ikke om effektivitet, men om at lære. Så ting vil tage tid, og tålmodighed er en dyd i denne fase.

I slutningen af dette stadie skal man have opnået erfaring i at bygge simple forbindelser mellem interne applikationer og tætte forretningspartnere.

Pressemeddelelsen findes her

SOA og it som infrastrukturel teknologi

Ronald Schmelzer diskuterer i denne artikel hvordan SOA og outsourcing er et vigtigt aspekt af it's bevægelse mod en infrastrukturel teknologi. Hvor it mere og mere bliver betragtet som en infrastrukturkomponent på linje med jernbaner, elektricitet, telefon og vand.
Virksomheden er derfor nødt til at forholde sig til, at muligheden for længerevarende differentiering ved hjælp af nye innovative it-løsninger bliver vanskeligere, efterhånden som ”it-kraft ” bliver billigere og let tilgængeligt, fordi konkurrenterne lettere kan kopiere løsningen uden krav om store, faste investeringer i starten.

At have adgang til ”it-kraft” vil kun forøge hastigheden, hvormed ændringerne sker på markedet. For at organisationen skal kunne følge med, er det nødvendigt med strategier, der lægger mere vægt på bølger af kortsigtede (typisk seks til tolv måneders) operative initiativer – initiativer, der følger den langsigtede retning udstukket af den overordnede strategi. Ved at fokusere organisationen på rullende bølger af kortsigtede operative initiativer vil denne tilgang opmuntre til innovation, som over tid reflekteres i voksende kompetencer i virksomheden og hurtigere læring. Disse gradvise forbedringer er afhængige af den øjeblikkelige situation og bliver meget vanskelige for konkurrenter at replicere. Konkurrenter kan forsøge at kopiere processen, men fordelen vil holdes ved lige i de rullende bølger af forbedringer.

Indtrængningsbarrieren til en industri er reduceret på grund af den konstant forøgede effektivitet, som nye it-løsninger giver, og den lettere adgang til kunderne, som internettet har medført. Nytilkomne til en industri har ofte 30 procents omkostnings- og effektivitetsfordel i forhold til eksisterende virksomheder, fordi nybyggede systemer er optimeret til den moderne leverancekanal. Ineffektivitet og ufleksibilitet vil derfor straffe virksomheder hårdere.

Ronald Schmelzers artikler findes her

tirsdag, september 05, 2006

XML - For meget af det gode?

David Beckers artikel diskuterer, hvor vigtig XML er blevet efter at have været på banen i 6 år.
Artiklen understreger, at det er vigtigt at have en bevidst standardstrategi i virksomheden. Lav ikke egne formater, men benyt industristandarder. Selv i tilfælde hvor det drejer sig om udveksling mellem to interne systemer, skal der benyttes standarder. Er man konsekvent omkring brug af standarder, forøger det fremtidssikring og fleksibiliteten i ens systemer.
Virksomheden skal være opmærksom på, at der i øjeblikket tages beslutninger i mange industriorganer om, hvordan data og forretningsprocesser skal se ud. Vær derfor bevidst omkring deltagelse i standardorganisationer.

Mange udviklere, der er vant til at optimere alt, vil kigge på XML og sige ”Jeg kan bygge noget, det er ikke helt XML, men det er en slags XML, og jeg er sikker på, at det vil være hurtigere og fylde mindre.” Men det fungerer ikke i det lange løb. Til syvende og sidst er standarderne standarder, og de har en stor værdi på grund af det.

David Beckers artikel findes her

Psykologien i SOA

Jim Ericsson diskuterer her udfordringen med at få forretningen til at forstå og udnytte de muligheder som SOA giver.
It bliver en mere og mere vigtig del af virksomheders konkurrenceevne. Derfor skal der hos it-afdelingerne opnås en bedre forståelse for it’s indvirkning på forretningssiden. På samme måde skal de forretningsorienterede med-arbejdere opnå en større forståelse for, hvad teknologien indeholder, og hvordan den kan udnyttes i praksis
Jim Ericssons artikel findes her

Hvor løs er din kobling?

Den første artikel jeg vil henlede opmærksomheden på, er Jason Bloombergs ”How Loose is your Coupling?”.
Løs kobling er en måde at designe og udvikle på — det er ikke en teknologi. Paradigmeskiftet vil kræve omskoling af mange udviklere samt revidering af udviklingsstrategier. For mange vil det være unaturligt ikke mere at skulle fokusere på let målbare fordele såsom performance og økonomi, men i stedet optimere det mere abstrakte begreb, fleksibilitet

Jason Bloombergs artikel findes her