Arkiv for kategorien 'Integrasjon'

Seks dominerende trender
- fra Web 2.0 Expo 2010

Tarantell hadde fire deltakere på årets Web 2.0 Expo i San Francisco. Konferansen arrangeres to ganger i året (vår/høst i henholdsvis San Francisco og New York) i regi av O’Reilly media. Tema og bakgrunn for konferansen er Tim O’Reilly’s fellesbetegnelse web 2.0, der hovedformålet var å skape en felles terminologi for alt som endrer vår oppfatning av hva internett er, kan brukes til og hvorledes det påvirker både vår forretningdrift og våre liv.

Konferansen er et viktig møtepunkt for alle som er opptatt av hva som venter rundt neste hjørne på internett – samt en realitetssjekk på hva som fungerer (eller ikke fungerer) med dagens plattformer, løsninger og forretningskonsepter.

Vi har tatt med oss noen hovedtrender fra Web 2.0 Expo. Hver av dem en verdt en eller flere blogginnlegg, og vi vil komme nærmere tilbake til de enkelte trendene.

Here goes:

Trend #1 : Lokalisering er overalt

Utnyttelse av sosiale medier med lokaliseringstjenester er på alles lepper. De fremste tjenestene pr. nå er businessorienterte Foursquare og tamagotchi/pokemon-inspirerte Gowalla. Google og Facebook er på vei med sine konkurrerende tjenester, så dette skal bli et uoversiktlig landskap å orientere seg i. Det som dog er viktig å ta med seg er:

  • Dialog mellom mennesker inneholder stedsinformasjon. Overhør en telefonsamtale på bussen og sjekk selv. Sosiale medier er fremfor alt om dialog, og disse mediene kommer følgelig til å oversvømmes av lokaliseringsinformasjon.
  • Virksomheter ønsker å vite både hvem kundene er – og hvor de er. At man også kan bruke sosiale medier til å trekke kunder inn i de fysiske butikkene er ett av Foursquares verdiforslag.
  • SFs svar på Ruter (BART) har brukt Foursquare for å øke antall reisende med offentlig kommunikasjon. I en kundeundersøkelse sier 19% av de spurte at de hadde reist med BART basert på en anbefaling fra en digital venn, og 38% syntes offentlig transport var “more fun” med mobile lokaliseringstjenester.

Lokaliseringstjenester kommer til å bli stort – og forhåpentligvis mer oversiktlig enn det er idag.

Trend #2 : HTML5 er den nye vinen

Hva skal man si? ALT kan gjøres i HTML5. Audio, video, skalerbar vektorgrafikk, 3D, SQL, webfonter etc. etc. Dette kan erstatte Flash, Silverlight og andre pluginbaserte utvidelser. De dårlige nyhetene er at implementeringen varierer kraftig fra nettleser til nettleser, og Microsoft er ikke på banen ennå. Vi står med andre ord foran flere år med browserkrig. Google har prøvd å imøtegå dette ved å lage en Chrome plugin til IE, noe som virker som et solid hopp tilbake til start.

En engstelig sjel i salen som prøvde å varsku om sikkerhets- og ytelsesproblemer fikk klar beskjed fra podiet: Toget har gått; standarden er vedtatt, framtiden er her og nå.

Så fikk vi se og høre Quake 2, spilt i nettleseren. Wow.

Trend #3 : Weboptimalisering

Ytelsesoptimalisering av websider gir høyere kundetilfredshet, økt konverteringsrate, mer aktive brukere – OG det er lønnsomt ift reduserte krav til infrastruktur og drift.

For å ta det siste først: Siden det å servere ut html-sider er noe av det tyngste infrastrukturen din gjør, har tjenester som Netflix og Shopster redusert henholdsvis antall servere og båndbredde til det HALVE ved å drive strukturert og helhetlig optimalisering av websidene. Sjekk ditt eget driftsbudsjett for å se hva gevinsten kunne vært? Forutsetningen for en slik kostnadsreduksjon er selvfølgelig at man har et stort antall brukere – og at man betaler for faktisk bruk av infrastrukturen (slik man gjør i skyen…).

Google og Yahoo! har foretatt undersøkelser med brukere som blir utsatt for dårlig ytelse. Begge undersøkelsene utsatte brukere for høyere og høyere forsinkelse i levering av websider. Undersøkelsene ble ikke framlagt, men en viktig lærdom fra Google sin undersøkelse er verdt å merke seg:

Google kjørte undersøkelsen med testgruppe og referansegruppe, der referansegruppen ikke ble utsatt for forsinkelser. Testgruppens adferd endret seg, i form av at brukerne ble mer passive, mindre villige til å fullføre oppgaver (=lavere konverteringsrate). Etter at forsinkelsen ble fjernet hadde gruppene fortsatt ulik adferd – i lang tid. Så lang tid at testgruppen ikke hadde fått gjenopprettet sitt aktivitetsnivå idet undersøkelsen ble avsluttet. Brukere som blir utsatt for forsinkelse blir passive, og det gir ingen umiddelbar effekt å rette feilen.

Ved dårlig servicenivå gjør man skade som varer lenge.

Virksomheter som har hatt suksess med weboptimalisering sier at verktøyene ikke trenger å være veldig sofistikerte. De trekker fram Yahoo! YSlow og Google Page Speed som gratiseksempler. Men et viktig suksesskriterie er at ytelsesparametrene ikke kan eies av IT alene: Alle de viktigste ytelsesparametrene må eies (og forstås) av forretningsenheter, markedsavdeling og ledelse. Først da kan man ta ut den forretningsmessige effekten.

Trend #4 : API’er på godt og vondt

Fra å snakke om mashups er dialogen og diskusjonen nå vendt til realitetene ved å eie, forvalte og bruke åpne API’er. Mantraet fra LinkedIn er: Planlegg godt, gjør ingen feil. Lett å si, men vanskelig å gjøre.

Twitter har hatt store problemer med sin autentiseringstjeneste, og har måttet tvinge brukerstedene av API’et over på ny løsning – rett og slett ved å skru av den gamle på et gitt tidspunkt. Resultatet ble at mange tjenester som baserte seg på twitter sluttet å virke, og feilsøking og feilretting rundt overgangen er fortsatt ikke avsluttet. Litt mer kundevennlige LinkedIn måtte ringe opp alle brukerstedene før de gjorde endringer. God service, men en så stor jobb at det nesten er vanskelig å forestille seg.

Lærdom1: Skal man etablere et åpent API må man betrakte brukerne av API’et som kunder, og behandle dem deretter. Å eie et API er å eie et produkt – lansering må planlegges nøye, og produktets livssyklus må analyseres før det settes ut i markedet.

Lærdom2: Skal man benytte et åpent API må man agere som kunde. Dette innebærer å registrere seg, og forholde seg til løpende dokumentasjons- og programendringer. Man må også ytelsesplanlegge og robustifisere sin egen løsning og kundedialog for situasjoner der API’et kan være utilgjengelig.

Trend #5 : Sosiale medier og CRM

Alle vil vite mer om hvorledes man kan benytte sosiale medier i aktiv bearbeiding av markedet og kundene – med økt salg som formål. Mange vil snakke om temaet, og har kloke ideer til hva man ikke bør gjøre. Nesten ingen har gode mønster/patterns for hvorledes gjøre dette i praksis.

Lærdom: Det er bedre å gjøre noe selv om man ikke ser en konkret og målbar positiv effekt, enn å gjøre ingenting og oppleve en konkret og målbar negativ effekt.

Trend #6 : Vi er alle (agile) webutviklere

Sett i lys av ovenstående trender blir webutvikling og kunnskap om tjenester og teknologier en felles møteplass for forretningsutviklere, systemeiere, markedsførere, designere og utviklere. Ingen kan melde seg ut av denne kunnskapssirkelen og fortsatt ha et realistisk håp om fantastiske resultater ved bruk av digital teknologi. Web 2.0 tilhører ingen rolle, avdeling eller virksomhet alene.

For å skape god effekt med mange involverte parter, satte konferansen søkelyset på hurtigd/agile/lean prosesser der man skaper verdi tidlig – og prioriterer hardt i forhold til egne krav. Levere lite & fort er bedre enn mye & sent.

Alt satt i system

I et forsøk på å sette disse trendene i en form for et system, skisset jeg raskt opp denne figuren på det man bare måtte ha med seg hjem fra San Francisco i mai i år: en iPad. Rundt en tredel av alle konferansedeltakerne hadde et brett, og på forespørsel fra plenumspodiet kom så godt som alle hender i været på spørsmålet: “Hvem har en iPhone?”. Tross denne Apple-dominansen var det slående at sympatien vektet tungt i favør av Adobe i spørsmålet rundt framtiden til Flash. Dette er kanskje også trender, men her har vi satt fokuset på forretningsutvikling på nett:

Kundeopplevelse og Web 2.0 trender

Kundeopplevelse og Web 2.0 trender

Notasjon for integrasjonsdiagrammer

 I forbindelse med endringer i IT-systemer og IT-infrastruktur er integrasjon mellom systemer ofte en tidkrevende øvelse. At forskjellige leverandører har forskjellig bakgrunn og kompetanse gjør også ofte at integrasjonsløsningene blir anderledes enn man forventer. For å unngå misforståelser er det viktig med gode illustrasjoner.

Illustrasjonene bør inneholde følgende informasjon:

  • Hvilke data som flyter mellom systemene
  • Hvilken teknologi som benyttes i integrasjonene
  • Hvilket system som initierer koblingen

Tidligere har vi tegnet dette i forskjellige diagrammer, med og uten UML. Det har vært vanskelig å få nok informasjon inn i ett enkelt diagram uten å miste oversikten og lesbarheten. Flere diagrammer kan gi klarhet i hvert sitt perspektiv, men når det blir snakk om mange systemer og målbildet endrer seg ofte, kan det bli tidkrevende å holde de forskjellige diagrammene i samsvar med hverandre. Følgende notasjon gjør det mulig å tegne alle detaljene i ett enkelt diagram uten at det blir uoversiktlig.

Read more »

SOA på tre måneder? Slank på 6 uker?

Det er mange spennende tilbud å lese om på internett, for ikke å snakke om en del av de som dukker opp i mailboksen min. Ofte loves stor fremgang (eller reduksjon, eller økning) på kort tid. Nå har jeg imidlertid fått med beskjed hjemmefra om ikke å tro på alt jeg leser, så jeg står vel uten unntak over denne typen tilbud. OK, jeg er litt svakere hvis de lover meg blankere sykkel eller lettere tur-utstyr – men nok om det.

En interessant sak nå nylig er denne: Tilbyr SOA på tre måneder til fast pris Her er aktøren seriøs og godt kjent i markedet, men har jeg noen tro på SOA (tjenesteorientert arkitektur) på 3 måneder? Til fastpris?

Read more »

Er SOA en ESB?

Å rent faktisk implementere SOA er en ny øvelse, særlig hvis man snakker om en virkelig gjennomgripende tjenestearkitektur, og ikke bare det å være i gang med å etablere enkeltstående tjenester. Hvilke verktøy som vil være nyttige og nødvendige er derfor til dels ennå et diskusjonstema. Kanskje er dette også et område som tiltrekker verktøyleverandører med mer eller mindre akutt behov for å redefinere seg selv til noe annet enn det de holder på med i dag?

En del verktøy begynner imidlertid å få mange tilhengere og ganske entydige definisjoner, et av disse er den såkalte servicebussen, dvs en Enterprise Service Buss. En ESB altså. Som sagt er det ikke nødvendigvis enighet om nøyaktig hva en ESB skal omfatte, men her er ihvertfall en definisjon av hva en ESB skal bidra med:

  • Ruting og formidling av tjenestekall
  • Transformering og berikelse av meldinger
  • Overvåkning og monitorering

Read more »

Integrasjon med Mule

Mule ESB er et rammeverk for integrasjon som har fått ganske så mye oppmerksomhet i IT-miljøer og på konferanser som Java Zone 07. Årsaken til dette er nok at Mule sees som et open source alternativ til svært dyre integrasjonsteknologier, samt dens nære knytning til populære open source teknologier som Spring, Maven og JBoss.

Så hva kan Mule brukes til og hvordan funger det? Mule er en Enterprise Service Bus i forstand at den består av komponenter som kan motta data, transformere data, eksekvere kode, og sende data videre. Disse komponentene konfigureres via XML filer hvor prosessflyten og protokoller spesifiseres. Her er en figur som illustrerer et tenkt scenario hvor den første komponenten mottar data via en Web Service og legger dataene på en kø via JMS, og er ferdig. En annen komponent lytter på køen, transformerer dataene og splitter den til en komponent som lagrer dataene til en database og en annen komponent som sender dataene til et annet system via en Web Service.

Prosesflyt

Dette er et enkelt men veldig typisk scenario for integrasjon. Siden flyten og protokollene konfigureres via en XML fil er det en smal sak å endre det slik at dataen sendes til en tredje komponent, samt å legge på transaksjonsstøtte for garantert levering fra kø til destinasjon.

Mens flyten, protokoller, destinasjoner og transaksjons konfigureres via en XML fil, så består selve innholdet i hver komponent av en enkel java klasse. Å lage en web service kan være så enkelt som å lage en klasse med en metode String getName() og så spesifisere XML filen at det skal være en Web Service.

It’s free. There must be a catch? Vel, ja. Hovedproblemet med Mule er den teknologiske terskelen for å komme i gang. Mule består av så mange forskjellige teknologier, hvor mange av dem, blant annet Mule selv, er nokså dårlig dokumentert. Så foruten at man trenger en god forståelse av integrasjonsteori som synkron/asynkron kommunikasjon, normalisering, korrelasjoner, transaksjoner, xml og database, så er det underliggende teknologiene som er en utfordring. Teknologier som man bør kunne for å få gjort noe i Mule vil generelt være: Java, Spring, Maven, Web Services (Xfire,CXF, JAX-WS), JMS, XML, JDBC, JMX og J2EE applikasjons tjener.

Det er mange måter deployere Mule på, men måten jeg har funnet ut fungerer mest tilfredsstillende er pakke hver instans som en ear fil, og hot-deploy til JBoss. Når man deployer flere instanser så vil hver instans ha sin egen classloader og være fullstendig separat. Problemet med dette, i forhold til andre ESB produkter, er at Mule ikke kan dele såkalte konnektorer mellom ulike instanser. Konsekvensen av dette er at dersom man har to instanser som eksponerer Web Services så må hver instans ha sin egen port. Dette kan fort bli en utfordring dersom man har mange instanser.

Så for å summere opp. Fordeler med Mule er

  • Fleksibelt og veldig pragmatisk rammeverk for integrasjon og prosessflyt
  • Skalerer sannsynlig veldig bra teknologisk på komponentnivå
  • God støtte for protokoller
  • Open source, noe som gjør det lettere å debugge
  • God støtte for unit- og funksjonell testing (noe som de aller fleste andre ESB mangler)
  • Ingen lisenskostnader
  • God online hjelp via deres mailingliste
  • Relativ god støtte for innsyn/monitorering under kjøring via JMX

Svakheter

  • Skalerer dårlig når det gjelder deployering
  • Høy terskel for å komme i gang
  • Fortsatt en del ting som ikke fungerer som det skal
  • Mangler grafisk grensesnitt for konfigurering
  • Mangler grafisk grensesnitt for XML mapping

Så alt i alt så er Mule et veldig interessant rammeverk som i mange tilfeller vil være tilfredsstillende for å gjøre integrasjon.