2007-06-10

Beat Schwegler, "Architecting Applications for a Service-Oriented World" (Developer Summit 2007)

Developer Summit inleddes med en keynote av Beat Schwegler, Microsoft Architect Evangelist för EMEA (Europe Middle East and Africa). Ämnet var "Architecting Applications for a Service-Oriented World" och Schwegler inledde med att ställa sig frågan vad han möjligtvis kunde ha att säga om detta, med IT-världens mått mätt, relativt gamla buzzword. "En modell är ej tillräckligt" var hans svar. Han exemplifierade med en karta över Londons tunnelbanesystem - "one of the best abstractions I know" - och jämförde det med kartor över busslinjer och flodtrafik, andra system som har beröringspunkter med tunnelbanesystemet för den som är intresserad av att transportera sig genom London. På samma sätt som det finns "interconnection points" mellan dessa behövs det knytpunkter mellan verksamheten och IT.

Grundförutsättningen var, som alltid med SOA (eller IT överhuvudtaget för den delen), att verkligheten är stadd i förändring. Eller som Beat Schwegler uttrycker det med ett citat av Charles Darwin i undertiteln till sin blogg:

"It is not the strongest of the species that survive, nor the most intelligent, but the ones most responsive to change."

Ett scenario med låneansökan i ett banksystem fick tjäna som exempel, inte heller det särskilt ovanligt för att exemplifiera serviceorienterade lösningar. Det tradtitionella fallet, att en sökande laddar ned en ansökan i form av ett PDF-dokument och skickar in det till en handläggare, var utgångspunkten. Ett in-house call center som tar emot en ansökan och på motsvarande sätt fyller i och skickar PDF-dokumentet till handläggaren var det andra användningsfallet. Vad vi än vill tro ser det tyvärr ut så här på många ställen än i dag.

Förändringsbehovet innehåller inte heller några överraskningar: ledningen vill att kunder ska kunna sköta sina ärenden online, vill outsourcea sitt call center och vill ha samma system för alla inblandade så att t.ex. en kund ska kunna börja fylla i sin ansökan online och sedan genast kunna fortsätta processen via telefon med kundtjänsten. Lösningen är inte helt oväntat en serviceorienterad arkitektur. Men vad innebär det?

Schwegler menar att det i den traditionella systemmodellen finns en klyfta mellan verksamhetsmodellen och den tekniska modellen. IT ses som en kostnad och kanske till och med som en kostnad man borde skära ned. Istället borde IT ses som en möjlighet att tillföra värde till verksamheten, men det är bara möjligt om IT närmar sig verksamheten. Schwegler hade ett småroligt sätt att uttrycka "exakt" hur stor klyftan mellan verksamheten och IT är; lika stor som den mellan en bok och filmatiseringen av den. När en bok ska filmatiseras finns det ett oändligt sätt att göra det på och det kan göras hundra filmer som alla är olika och som alla är sämre än boken (eftersom du läste den först). Analogin är att verksamheten inte riktigt vet vad de får från IT. Ett sätt att komma till rätta med det är att sluta fokusera på Hur systemen ska byggas och börja fokusera på Vad som behövs: "You have to separate the 'how' from the 'what'."

Ett enkelt men effektivt exempel Schwegler använde var en processbeskrivning som "A skickar ett fax till B som bekräftar med SMS till A". Om några år kanske vi inte ens använder fax och SMS utan någon helt annan teknologi som vi inte ens kan föreställa oss i dag (telepati?) och då är processbeskrivningen, liksom naturligtvis även själva systemet, värdelös. Verksamheten bör istället beskriva sina förväntningar på vad som behöver ske och sedan inte bry sig om hur det åstadkoms. För att överbrygga klyftan mellan verksamhetsmodellen och teknikmodellen inför Schwegler den servicebaserade modellen ("the service based model"). I denna systemmodell fokuserar verksamheten på Vad, vilka generella "capabilities" som behövs och på Service Level Expectations (SLE) istället för på detaljerade Service Level Agreements (SLA). Servicemodellen blir bryggan som tillhandahåller ett kontrakt för att uppfylla behoven och som orkestrerar verksamhetsprocesserna, IT implementerar dem.

Så långt var det inte mycket som kändes nytt, men som en introduktion till SOA var det bra och lättfattligt. Ofta slutar SOA-introduktioner ungefär här och det som var mest intressant med Schweglers presentation var att han gick vidare och försökte ge en bild av hur man kan implementera en servicemodell med existerande teknik utan att bygga allt på nytt. Han kallar sitt tillvägagångssätt för "Lift and Shift" och det innehåller ungefär dessa steg:

  • Analyze "as-is" architecture
  • Define the service model
  • Define the logical "to-be" architecture
  • Refactor ("Lift"): Refactor the existing system to be aligned with the "to-be" model
  • Migrate ("Shift"): Move the refactored assets to the target system and technology

"Lift and Shift" tillämpades sedan, på en mycket översiktlig nivå, på lånesystemet från det tidigare exemplet. Tyvärr har jag svårt att återge den här delen av presentationen, jag saknar t.ex. Schweglers fina skisser och diagram, så den som är intresserad får helt enkelt hålla utkik efter PowerPoint-presentationen på Developer Summits webbplats eller ta nästa tillfälle i akt att lyssna på Schwegler.

Avslutningsvis framhöll Schwegler att serviceorientering inte bara handlar om "back-end services" utan också om användargränssnitt. Microsofts två strategier för detta är "Software and Services" (även kallat "Software as a Service", SaaS) och Office Business Applications.

0 kommentar(er):