fredag, oktober 05, 2007
Steve Vinoski - ett RESTafarian
Steve Vinoski, en av figurerna bakom CORBA ransakar sig öppet på sin blog. Han menar att ESB var en religion som han lämnat bakom sig, för att istället blivit ett RESTafarian. Kommer han någonsin känna sig trygg o säkert i sina vägval?
måndag, oktober 01, 2007
SOA: Ett digitalt universum
Universum är gammalt. Ingen vet hur eller när det skapades, var vi är idag, vart det är på väg eller vad som fanns innan det skapades och vad som händer efter det försvinner. För att förklara det (påverkad av vad jag ftf läser; The God Delusion och tidigare S. Hawkings Kosmos : en kort historik) stora och ofattbara i det hela finns olika skapelseberättelser som grund i diverse religioner.
Vetenskapen slänger sig också med svepande begrepp som att "till en början rådde kaos, som övergick i kosmos". Att harmoni, styrda av naturlagar, skapades mellan universums beståndsdelar och tog oss dit vi är idag med högre sammansatta former (som oss själva).
Säg att vi backar tillbaka i tiden till strax efter universums skapelse. Där står vi nu och tittar hur det i ultrarapid skapas nya ämnen av några få beståndsdelar, som i sin tur tar nya former, allt under kontroll av naturlagarna. Känns inte detta igen? Står vi inte idag och tittar på ett annat fenomen som liknar det som vi själva uppkom ifrån?
Big Bang, det som vetenskapen betraktar som universums födelse. Kan man inte jämföra det med Internets födelse, dvs år 1995. Nu tänker du säkert, men mallå! det var ju tidigare än så, vi pratar 70-tal. Jo, men det var inte födelsen, det var att likna vid förvärkar. Vattnet rann när Web 1.0 föddes. Efter det tills nyligen har Internet betett sig som dagarna efter The Big Bang, dvs en enda lång explosion. Internet är idag en enda stor void-stjärna utan rättelse efter lagar om ordning ... det är kaos.
Vilka är lagarna som ska skapa harmoni och kosmos på Internet? WS-* kanske? Med osäkerhet om vilka lagarna är så är det ur den mängd information och funktion som tjänster ska utgöra de minsta beståndsdelarna och sluttillståndet är SOA. SOA det tillstånd då Internet (eller i mindre isolerade delar) är i harmoni. Då alla ingående delar förhåller sig tillvarandra som biologin, kemin och fysiken gör i universum.
Kan man se religiöst på SOA? Nej, jämförelsen med religionen går inte att göra eftersom religion är en ovetenskaplig förklaring till det ofattbara. Om SOA är som universum och att vi ser det hända just nu, vet vi ju vad som fanns innan SOA och hur gammalt det är. Alltså kan det idag inte betraktas som religiöst. Vi upplever det, därför är det fattbart. Kommer man om 100-tals år (vi får anta att det går snabbare än universums födelse), se tillbaka på Internet X.0 och förklara det som något ofattbart, dvs religöst, eller kan vi anta att generationerna behåller fattningen. Det vet vi inte, men troligen ligger svaret någonstans där emellan.
Kan man se fundamentalistiskt på SOA? Att måla upp en jämförelse mellan SOA och universum är ganska extremt, men kanske inte fundamentalistiskt. Kommer det att skapa fundamentalister som drar åt andra håll och vill blunda för utvecklingen av SOA? Ja, det är nog mer sannolikt. När vetenskapen blir för jobbig att leva med så vill man hindra den. Som en omvänd ordning mellan religion och vetenskap kommer SOA att få utstå häxjakter, korståg och rondellhundar.
Den som lever får se!
Vetenskapen slänger sig också med svepande begrepp som att "till en början rådde kaos, som övergick i kosmos". Att harmoni, styrda av naturlagar, skapades mellan universums beståndsdelar och tog oss dit vi är idag med högre sammansatta former (som oss själva).
Säg att vi backar tillbaka i tiden till strax efter universums skapelse. Där står vi nu och tittar hur det i ultrarapid skapas nya ämnen av några få beståndsdelar, som i sin tur tar nya former, allt under kontroll av naturlagarna. Känns inte detta igen? Står vi inte idag och tittar på ett annat fenomen som liknar det som vi själva uppkom ifrån?
Big Bang, det som vetenskapen betraktar som universums födelse. Kan man inte jämföra det med Internets födelse, dvs år 1995. Nu tänker du säkert, men mallå! det var ju tidigare än så, vi pratar 70-tal. Jo, men det var inte födelsen, det var att likna vid förvärkar. Vattnet rann när Web 1.0 föddes. Efter det tills nyligen har Internet betett sig som dagarna efter The Big Bang, dvs en enda lång explosion. Internet är idag en enda stor void-stjärna utan rättelse efter lagar om ordning ... det är kaos.
Vilka är lagarna som ska skapa harmoni och kosmos på Internet? WS-* kanske? Med osäkerhet om vilka lagarna är så är det ur den mängd information och funktion som tjänster ska utgöra de minsta beståndsdelarna och sluttillståndet är SOA. SOA det tillstånd då Internet (eller i mindre isolerade delar) är i harmoni. Då alla ingående delar förhåller sig tillvarandra som biologin, kemin och fysiken gör i universum.
Kan man se religiöst på SOA? Nej, jämförelsen med religionen går inte att göra eftersom religion är en ovetenskaplig förklaring till det ofattbara. Om SOA är som universum och att vi ser det hända just nu, vet vi ju vad som fanns innan SOA och hur gammalt det är. Alltså kan det idag inte betraktas som religiöst. Vi upplever det, därför är det fattbart. Kommer man om 100-tals år (vi får anta att det går snabbare än universums födelse), se tillbaka på Internet X.0 och förklara det som något ofattbart, dvs religöst, eller kan vi anta att generationerna behåller fattningen. Det vet vi inte, men troligen ligger svaret någonstans där emellan.
Kan man se fundamentalistiskt på SOA? Att måla upp en jämförelse mellan SOA och universum är ganska extremt, men kanske inte fundamentalistiskt. Kommer det att skapa fundamentalister som drar åt andra håll och vill blunda för utvecklingen av SOA? Ja, det är nog mer sannolikt. När vetenskapen blir för jobbig att leva med så vill man hindra den. Som en omvänd ordning mellan religion och vetenskap kommer SOA att få utstå häxjakter, korståg och rondellhundar.
Den som lever får se!
onsdag, september 05, 2007
Agila projekt misslyckas
Jag tycker det är intressant hur mycket kollektiv uppmärksamhet en metodik kan få. Jag säger kollektiv eftersom det känns som om det sveper en vind av förhoppningar bland utvecklare att få jobba annorlunda (går att jämföra med utvecklares förhållande till Patterns). Det agila med en projektmetodik bottnar oftast i faktumet att en utvecklare vill göra det den behärskar bäst, nämligen koda.
En utvecklare vill inte förstå en verksamhet, ett krav, någon annans synsätt. En utvecklare ser på saken från ett perspektiv som endast utvecklare kan se på saken. Bästa sättet för en oinsatt att göra sig förstådd är att låta utvecklaren sitta och koda. Koda fram något som den oinsatte kan ha åsikter om. Det är lite som Runge Kutta, om ni minns den? En approximeringsmetod för att lösa problem genom att närma sig lösning steg för steg genom korta intervall.
Tyvärr är det inte alls det som är poängen med agilitet. Agil handlar om att vara lättrörlig, inte att inte förstå eller ha en lösning på problemet initialt. Det handlar om att ändra målet, att lyfta blicken från slutaren, ställa om ISO, bländare och slutartid för att sedan sikta igen.
På frågan om varför en utvecklare har så annorlunda sätt att tänka beror på vad utvecklaren har i verktygslådan. Där i hittar man anledningen varför det skapar ett sådant glapp mellan den oinsatta och utvecklaren. Världen utanför är nämligen inte objektorienterad, men i vertygslådan finns bara objektorienterade vertyg. Med dessa verktyg kan man inte bygga det kunder frågar efter utan att genom ett antal steg och modelltransformeringar från en verksamhetsmodell till en objektorienterad. Idag finns ingen naturlig väg från den ena till den andra och det är på tiden att vi byter ut verktygen mot något som passar istället.
Se mer fakta om varför agila projekt misslyckas.
En utvecklare vill inte förstå en verksamhet, ett krav, någon annans synsätt. En utvecklare ser på saken från ett perspektiv som endast utvecklare kan se på saken. Bästa sättet för en oinsatt att göra sig förstådd är att låta utvecklaren sitta och koda. Koda fram något som den oinsatte kan ha åsikter om. Det är lite som Runge Kutta, om ni minns den? En approximeringsmetod för att lösa problem genom att närma sig lösning steg för steg genom korta intervall.
Tyvärr är det inte alls det som är poängen med agilitet. Agil handlar om att vara lättrörlig, inte att inte förstå eller ha en lösning på problemet initialt. Det handlar om att ändra målet, att lyfta blicken från slutaren, ställa om ISO, bländare och slutartid för att sedan sikta igen.
På frågan om varför en utvecklare har så annorlunda sätt att tänka beror på vad utvecklaren har i verktygslådan. Där i hittar man anledningen varför det skapar ett sådant glapp mellan den oinsatta och utvecklaren. Världen utanför är nämligen inte objektorienterad, men i vertygslådan finns bara objektorienterade vertyg. Med dessa verktyg kan man inte bygga det kunder frågar efter utan att genom ett antal steg och modelltransformeringar från en verksamhetsmodell till en objektorienterad. Idag finns ingen naturlig väg från den ena till den andra och det är på tiden att vi byter ut verktygen mot något som passar istället.
Se mer fakta om varför agila projekt misslyckas.
tisdag, augusti 21, 2007
SOA klarnar
Företaget Wellesley har gjort en undersökning om hur införande av en SOA har resulterat i en ROI eller inte. David O'Connell, en analytiker på Wellesley, säger att enbart 37% av de utfrågade anser att de fått tillbaka på investeringen.
En av anledningarna är att utvecklarna inte anser att använda redan skriven kod inte är en tillräcklig utmaning.
"Developers think it is cool to come up with a new piece of code," according to O'Connell. "When you're developing in an SOA environment you need ... to customize something that someone else developed. That is not instantly appealing to developers."
Det visade sig dock att 28% ansåg att de blev mer produktiva när de byggde applikationer ovan på en SOA. Enligt rapporten så återanvänder man 37% av tjänsterna i en SOA.
O'Connell föreslår därför att företagen ska skaffa ett service repository vilket skulle öka återanvändningen.
Studien visar även att den största anledningen till att införa SOA är BPM, Portaler, MDM och B2B.
En av anledningarna är att utvecklarna inte anser att använda redan skriven kod inte är en tillräcklig utmaning.
"Developers think it is cool to come up with a new piece of code," according to O'Connell. "When you're developing in an SOA environment you need ... to customize something that someone else developed. That is not instantly appealing to developers."
Det visade sig dock att 28% ansåg att de blev mer produktiva när de byggde applikationer ovan på en SOA. Enligt rapporten så återanvänder man 37% av tjänsterna i en SOA.
O'Connell föreslår därför att företagen ska skaffa ett service repository vilket skulle öka återanvändningen.
Studien visar även att den största anledningen till att införa SOA är BPM, Portaler, MDM och B2B.
tisdag, augusti 14, 2007
tisdag, augusti 07, 2007
torsdag, juli 26, 2007
Virtualisering och SOA
IDG.se skrev för ett litet tag sedan en artikel om kopplingen mellan virtualisering och SOA som jag antar byggde på den här artikeln i eWeek.com. Den följdes upp av ett antal kommentarer som visar på god SOA-förståelse i landet. Här är lite citat som är viktiga för förståelsen av en SOA.
"SOA kan jämföras med hårdvaruvirtualisering eftersom (som zixleg säger) båda teknikerna klipper beroendet till underliggande "lager"."
"Hypervisorn virtualiserar över hårdvaran, CLR & JRE virtualiserar över OS och SOA virtualiserar (något filosofiskt, men ändå) över applikationer."
"Det får samma fördelar med SOA som det ger med hårdvaruvirtualisering:
1. hög användingsgrad av resurserna
2. hög återanvändning av resurserna
3. hög managerbarhet över resurserna
4. hög förändringsbarhet av resursanvändningen"
"Det är ingen poäng att hosta soa lösningar i virtualiserade miljöer mer än det skulle vara för någon annan arkitektur ... dvs att hårdvaruvirtualisering inte är en möjliggörare för soa"
Jämförelsen mellan virtualisering och SOA pekade jag på tidigare i tre inlägg och anser att tillsammans (inte beroende av varandra dock) bidrar de tungt till en god Execution Foundation i en EA.
"SOA kan jämföras med hårdvaruvirtualisering eftersom (som zixleg säger) båda teknikerna klipper beroendet till underliggande "lager"."
"Hypervisorn virtualiserar över hårdvaran, CLR & JRE virtualiserar över OS och SOA virtualiserar (något filosofiskt, men ändå) över applikationer."
"Det får samma fördelar med SOA som det ger med hårdvaruvirtualisering:
1. hög användingsgrad av resurserna
2. hög återanvändning av resurserna
3. hög managerbarhet över resurserna
4. hög förändringsbarhet av resursanvändningen"
"Det är ingen poäng att hosta soa lösningar i virtualiserade miljöer mer än det skulle vara för någon annan arkitektur ... dvs att hårdvaruvirtualisering inte är en möjliggörare för soa"
Jämförelsen mellan virtualisering och SOA pekade jag på tidigare i tre inlägg och anser att tillsammans (inte beroende av varandra dock) bidrar de tungt till en god Execution Foundation i en EA.
onsdag, juli 25, 2007
Fler definitioner på SOA
Det pratas mer och mer SOA och ju mer det pratas SOA desto fler definitioner av SOA blir det.
Här är Microsofts syn på SOA i ett rykande färskt dokument.
Jag tycker nog min arbetsgivares definition är korrekt:
A loosely-coupled architecture designed to meet the business needs of the organization.
Och att min egen från 2005 (Vägen till tjänstebaserad arkitektur) inte är helt fel ute, än så länge:
En arkitektur som bygger på samverkan mellan små självfungerande tjänster som är definierade av verksamhetsprocesser och baserade på standardiserad teknologi.
Här är Microsofts syn på SOA i ett rykande färskt dokument.
Jag tycker nog min arbetsgivares definition är korrekt:
A loosely-coupled architecture designed to meet the business needs of the organization.
Och att min egen från 2005 (Vägen till tjänstebaserad arkitektur) inte är helt fel ute, än så länge:
En arkitektur som bygger på samverkan mellan små självfungerande tjänster som är definierade av verksamhetsprocesser och baserade på standardiserad teknologi.
torsdag, juli 19, 2007
Pattern-ister och GPSer
Jag skaffade en HTC 3300 för några veckor sedan. Den är utrustad med en GPS som jag var tvungen att pröva så fort som möjligt. Jag brukar köra inne i stan (Stockholm) som jag bott i i nu snart 15 år. Jag kan de flesta gator i centrum, men eftersom jag nu köpt en GPS så måste den ju användas.
En gång skulle jag åka mellan Kaptensgatan och Floragatan en vanlig vardagseftermiddag runt 4-tiden. GPSen föreslog att jag skulle åka ned på Strandvägen, ta Birgerjarlsgatan till Stureplan och sedan Sturegatan, Karlavägen, Floragatan. Öhh ... den vägen kändes inte rätt, varför valde den den mest trafikerade vägen så här dags. Den var inte ens kortast och definitivt inte snabbast. Jag körde istället upp direkt på Karlavägen bort till Floragatan och tjänade säkert en kvart på det.
Det slog mej senare att precis så här används Design Patterns i utvecklingsprojekt.
Istället för att tänka själva så kör man pattern-bingo bland utvecklarna. Istället för att tänka själv så name droppas det patterns som resulterar i omvägar, felsatsningar och tidsförluster. I många fall knuffas talang och erfarenhet undan till fördel för pattern-ister.
Det är viktigt att tänkande individer som kan programmering får det utrymme de förtjänar och att utvecklarnas GPSer (patterns) används sparsamt och inte blir till en överdrift.
En gång skulle jag åka mellan Kaptensgatan och Floragatan en vanlig vardagseftermiddag runt 4-tiden. GPSen föreslog att jag skulle åka ned på Strandvägen, ta Birgerjarlsgatan till Stureplan och sedan Sturegatan, Karlavägen, Floragatan. Öhh ... den vägen kändes inte rätt, varför valde den den mest trafikerade vägen så här dags. Den var inte ens kortast och definitivt inte snabbast. Jag körde istället upp direkt på Karlavägen bort till Floragatan och tjänade säkert en kvart på det.
Det slog mej senare att precis så här används Design Patterns i utvecklingsprojekt.
Istället för att tänka själva så kör man pattern-bingo bland utvecklarna. Istället för att tänka själv så name droppas det patterns som resulterar i omvägar, felsatsningar och tidsförluster. I många fall knuffas talang och erfarenhet undan till fördel för pattern-ister.
Det är viktigt att tänkande individer som kan programmering får det utrymme de förtjänar och att utvecklarnas GPSer (patterns) används sparsamt och inte blir till en överdrift.
tisdag, juli 10, 2007
BPEL4People bjuder in människor
BPEL4People är en specification som gör det möjligt att dela ut Tasks till personer i en arbetsprocess implementerad i WS-BPEL. Jag har prövat ActiveEndpoints Enterprise plugin för BPEL4People och visst skapar det möjligheter med utökningen av språket.
Vad det går ut på är att någonstans i processen så ska en aktivitet utföras av en person. Personen ingår i en grupp av personer som har samma roll. Det kan vara en låneutgivare på en bank som ska utföra en kreditkontroll (aktiviteten) i en låneansökan (processen). När aktiviteten exekveras så notifieras gruppen (rollen) att en ny uppgift har skickats.
Sedan loggar valfri låneutgivare in och får mer information om uppgiften och kanske därefter antar uppgiften. När uppgiften är utförd så matar låneutgivaren in eventuell respons och skickar tillbaka kontrollen till processen. Självfallet kan BPEL4People även ta hand om undantag och felhantering.
Vad det går ut på är att någonstans i processen så ska en aktivitet utföras av en person. Personen ingår i en grupp av personer som har samma roll. Det kan vara en låneutgivare på en bank som ska utföra en kreditkontroll (aktiviteten) i en låneansökan (processen). När aktiviteten exekveras så notifieras gruppen (rollen) att en ny uppgift har skickats.
Sedan loggar valfri låneutgivare in och får mer information om uppgiften och kanske därefter antar uppgiften. När uppgiften är utförd så matar låneutgivaren in eventuell respons och skickar tillbaka kontrollen till processen. Självfallet kan BPEL4People även ta hand om undantag och felhantering.
tisdag, juli 03, 2007
Processorienterad design
Jag hade en diskussion med Fredrik Normén idag där en intressant fråga kom upp. Antag en inköpsprocess där en av aktiviteterna ska notifiera chefen om att en ny order ska attesteras. Notifieringen skall ske via email, men en kodare känner igen diskussionen och vet att inom kort ska kanske ett annat sätt hantera notifieringen som exempelvis via SMS-meddelande. Frågan vi ställde oss var om man 1) ska skapa en specifik aktivitet för varje scenario som man i processen byter ut när kraven ändras eller 2) en generell aktivitet som kan hantera notifiering rent allmänt så att implementationen av processen alltid förblir densamma.
Det självklara svaret kan anses vara att man borde skriva en generell aktivitet som kan hantera olika transportsätt. Men eftersom processmotorer är byggda för att just kunna modifera processerna så borde det första alternativet inte ge något overhead vid förändring. Det kan till och med vara tydligare att i processen kunna se hur meddelandet ska skickas.
Jag skulle nog i alla fall vilja påstå att just styrkan med kombinationen av tjänster och process hantering skapar den bästa lösningen. Nedan så implementeras processen med en generell notifieringsaktivitet. Självfallet ska inte implementationen av aktiviteten köras inne i processmotorn utan skickas som ett service anrop via ett Mediation Layer, en Enterprise Service Bus (ESB). Däri ligger ansvaret för att hantera hur meddelandet ska nå användaren vilket kontrolleras genom policies för notifieringstjänsten.
För processen finns det inga fysiska tjänster att tillgå, utan enbart virtuella tjänster som exponeras genom ESB:n. Inne i bussen routas meddelandet beroende på innehåll och yttre omständigheter samt transformeras för att passa just det transportsättet och den mottagaren av den fysiska implementationen av notifieringstjänsten. Det här är en klassisk kombination av Business Process Management och Service Oriented Architecture som visar vad som ligger inom respektive arkitekturs ansvarsområde.
Det självklara svaret kan anses vara att man borde skriva en generell aktivitet som kan hantera olika transportsätt. Men eftersom processmotorer är byggda för att just kunna modifera processerna så borde det första alternativet inte ge något overhead vid förändring. Det kan till och med vara tydligare att i processen kunna se hur meddelandet ska skickas.
Jag skulle nog i alla fall vilja påstå att just styrkan med kombinationen av tjänster och process hantering skapar den bästa lösningen. Nedan så implementeras processen med en generell notifieringsaktivitet. Självfallet ska inte implementationen av aktiviteten köras inne i processmotorn utan skickas som ett service anrop via ett Mediation Layer, en Enterprise Service Bus (ESB). Däri ligger ansvaret för att hantera hur meddelandet ska nå användaren vilket kontrolleras genom policies för notifieringstjänsten.
För processen finns det inga fysiska tjänster att tillgå, utan enbart virtuella tjänster som exponeras genom ESB:n. Inne i bussen routas meddelandet beroende på innehåll och yttre omständigheter samt transformeras för att passa just det transportsättet och den mottagaren av den fysiska implementationen av notifieringstjänsten. Det här är en klassisk kombination av Business Process Management och Service Oriented Architecture som visar vad som ligger inom respektive arkitekturs ansvarsområde.
Varför blogga?
För ett lite tag sedan på .NET Rocks kunde man lyssna till Don Box och Chris Sells när dom diskuterade lärande med Carl and Richard. Både Don och Chris är bloggare som många andra, även undertecknad. I samtalet kom frågan upp varför man överhuvudtaget skriver, oavsett arena (bok, tidning, blog, etc). Jag funderade på några anledningar till varför folk bloggar.
1. Du lär dig saker genom att skriva
2. Du vill dela med dig av din kunskap
3. Du vill dokumentera dina tankar som en öppen dagbok
4. Du vill skapa debatt
5. Du vill göra avtryck i historien
6. Du vill använda det i ditt CV
7. Du är upprörd och vill berätta din åsikt
8. Du vill framföra dina åsikter genom att provocera
9. Du har något att berätta men kan inte utttrycka dig verbalt
10. Du har något att berätta men vill inte skriva en bok
11. Du "tycker om att skriva"
12. Du vill få ett kvitto på dina åsikter
13. Du vill "skriva av dig" så du kan glömma och gå vidare (terrapi)
14. Du skapar material som du vill ha kommentarer på och som senare kan användas i en bok du vill skriva
15. Tjäna pengar på bl a Google Ads
16. Imponera på din arbetsgivare
17. Du har en narcissistisk störning och vill synas
Även om de flesta punktern handlar om lärande och självförverkligande så finns det en stor mängd bloggar som skapar debatt och leder till diskussion. Det tycker jag blogging är bäst på och det är där bloggen skiljer sig från boken.
1. Du lär dig saker genom att skriva
2. Du vill dela med dig av din kunskap
3. Du vill dokumentera dina tankar som en öppen dagbok
4. Du vill skapa debatt
5. Du vill göra avtryck i historien
6. Du vill använda det i ditt CV
7. Du är upprörd och vill berätta din åsikt
8. Du vill framföra dina åsikter genom att provocera
9. Du har något att berätta men kan inte utttrycka dig verbalt
10. Du har något att berätta men vill inte skriva en bok
11. Du "tycker om att skriva"
12. Du vill få ett kvitto på dina åsikter
13. Du vill "skriva av dig" så du kan glömma och gå vidare (terrapi)
14. Du skapar material som du vill ha kommentarer på och som senare kan användas i en bok du vill skriva
15. Tjäna pengar på bl a Google Ads
16. Imponera på din arbetsgivare
17. Du har en narcissistisk störning och vill synas
Även om de flesta punktern handlar om lärande och självförverkligande så finns det en stor mängd bloggar som skapar debatt och leder till diskussion. Det tycker jag blogging är bäst på och det är där bloggen skiljer sig från boken.
måndag, juni 18, 2007
Revenge of the nerds (Getting Real)
När jag läste den här boken för ett år sedan så valde jag att inte kommentera den men eftersom den blivit en guide för så många nya utvecklare så vill jag ändå skriva några rader.
"Getting Real" en bok av 37Signals vinklar ett utvecklarperspektiv och ser det inte alls från en beställares. Den andas "Revenge of the nerds" och hyllar Agile Software Development, vilket är en metodik som är en reaktion mot UML-diagram, funktionsspecar, RUP, möten med chefer och kunder. Det går ut på att aldrig skriva ett dokument som beskriver hur en leverans ska se ut, utan istället hålla frågan öppen och se vart åt det barkar. Passar säkert jättebra när man utvecklar första versionen av en produkt där det än så länge inte finns en beställare. Men om det finns en beställare, en budget och beroenden från andra grupper så är Agile helt förkastligt. Det finns inga garantier att man ska få det man önskar utan är bara en utvecklares önskan att få sitta ostörd och jobba utan krav.
Boken har många absoluta påstående och är ibland skrivna som religiösa sanningar:
"Getting Real" en bok av 37Signals vinklar ett utvecklarperspektiv och ser det inte alls från en beställares. Den andas "Revenge of the nerds" och hyllar Agile Software Development, vilket är en metodik som är en reaktion mot UML-diagram, funktionsspecar, RUP, möten med chefer och kunder. Det går ut på att aldrig skriva ett dokument som beskriver hur en leverans ska se ut, utan istället hålla frågan öppen och se vart åt det barkar. Passar säkert jättebra när man utvecklar första versionen av en produkt där det än så länge inte finns en beställare. Men om det finns en beställare, en budget och beroenden från andra grupper så är Agile helt förkastligt. Det finns inga garantier att man ska få det man önskar utan är bara en utvecklares önskan att få sitta ostörd och jobba utan krav.
Boken har många absoluta påstående och är ibland skrivna som religiösa sanningar:
- "If you can't fit everything in within the time and budget allotted then don't expand the time and budget. Instead, pull back the scope. There's always time to add stuff later — later is eternal, now is fleeting."
- "Don't follow the leader"
- "You don't need to nail that perfect shade of green in week two. You don't need to move that "submit" button three pixels to the right in week three. Just get the stuff on the page for now. Then use it. Make sure it works. Later on you can adjust and perfect it."
- "Don't be a yes-man", "Make each feature work hard to be implemented.", "Every new feature request that comes to us — or from us — meets a no. We listen but don't act. The initial response is 'not now.'"
- "Don't expect to get it right the first time. Let the app grow and speak to you. Let it morph and evolve. With web-based software there's no need to ship perfection."
- "There are too many meetings. Push back on meetings that do not make sense or are unproductive."
- "So don't hire. Really. Don't hire people. Look for another way."
- "When it comes time to hire, don't think you need a guru or a tech-celebrity. Often, they're just primadonnas anyway. A happy yet average employee is better than a disgruntled expert."
- "Don't be afraid to say no to feature requests that are hard to do. Unless they're absolutely essential, save time/effort/confusion by leaving them out."
- "Don't just pick tools and practices based on industry standards or performance metrics. Look at the intangibles: Is there passion, pride, and craftmanship here?"
- "Don't worry about design, if you listen to your code a good design will appear...Listen to the technical people."
- "Don't write a functional specifications document"
- "Don't Do Dead Documents"
- "Avoiding functional specs is a good start but don't stop there; Prevent excess paperwork everywhere."
- "Build, don't write. If you need to explain something, try mocking it up and prototyping it rather than writing a longwinded document."
- "Don't waste your time typing up that long visionary tome; no one's going to read it."
- "Don't use acronyms or words that most people don't understand. Don't use internal lingo. Don't sound like an engineer talking to another engineer. Keep it short and sweet. Say what you need to and no more."
- "You don't need to be a swiss-army knife. You can just be a screwdriver. You don't need to build a diving watch that's safe at 5,000 meters if your customers are land-lovers who just want to know what the time is."
- "Be as open, honest, and transparent as possible. Don't keep secrets or hide behind spin. An informed customer is your best customer."
- "Also, don't create a culture of fear surrounding bugs. Bugs happen. Don't constantly seek someone to blame."
torsdag, juni 14, 2007
AOP & EAI - två av samma sort
AOP är för objekt som EAI är för applikationer. Både AOP och EAI är att fokusera på symptomen i stället för på orsaken.
onsdag, juni 13, 2007
SOA ur olika perspektiv
SOA är en motreaktion till monolitiskt applikations-orienterade IT-landskap. När man frågar folk om en definition av SOA så finns det en grund i problemen med de klassiska applikationerna. Alla ser SOA olika men samtidigt har de problem som exempelvis redundant funktionalitet och information, svårigheten att integrera funktion/data och omöjligheten att förändra applikationerna med tiden i banktanke.
VD:n
"SOA ger IT den rörlighet som krävs för att kunna driva ett företag/koncern där verksamheten förändrar sig i snabb takt med avseende på out-sourcing, omorganisationer, sammanslagningar, konsolideringar, m m."
IT-chefen
"SOA suddar ut applikationsgränser som ersätts av mindre sammankopplade tjänster som kan återanvändas, kopplas in/ur baserat på i tiden alltid föränderliga policies."
Processansvarige
"SOA underlättar automatiseringen av processer (BPM) som går på tvären genom affärsområdena i en organisation."
Affärsområdesansvarige
"SOA ger möjligheten att snabbt förändra verksamheten inom en funktion istället för att vara slav under LOB-applikationerna."
Applikationsansvarige
"SOA river ned applikations-silos och ersätter dom med virtuella applikationsgränser som kontrolleras m h a policies."
Affärsutvecklare
"SOA är den arkitektur mot var man kan mappa verksamhetens tjänster direkt mot ett IT-stöd."
Driftteknikern
"SOA skapar en transparans av alla rörliga delar i IT-landskapet som man centralt kan kontrollera och administrera (ESB), precis som Microsofts Virtual Machine Manager (reklam) kontrollerar hela IT-infrastrukturen."
Integratören
"SOA medför att jag kan lägga EAI åt sidan och ägna mej åt viktigare saker."
Systemarkitekten
"SOA resulterar i att när nya krav ska realiseras så finns redan ett repository där säkert 90% av alla tjänster redan är implementerade vilket medför att min instats kan halveras i tid och pengar."
Systemutvecklaren
"SOA medför att jag måste lära mej XML."
Krönikörer och IT-sommelierer
"Bäst att hoppa på SOA-spåret även om jag är några år sen och skriva om hur man kan koppla ihop SOA med roller, metodik, taxonomi och metaforer och hur väl det sammanfaller med saker som jag sagt tidigare även det förvirrar mej själv mest av alla."
Bloggaren
"SOA har förvirrat en hel industri vilket jag kan dra fördela av genom att skriva den här typen av inlägg."
Utbildaren
"Undrar hur länge jag kan lura mina elever att SOA är EAI + Web Service innan jag måste skriva om min gamla integrationskurs från 90-talet."
Analytikern
"SOA har varit en riktig mjölkko när det kommer till buzz-words! Vad kommer härnäst?"
Applikationsutvecklaren
"Jag bygger några Web Services on-top av min applikation och vips så har jag en SOA, eller?"
VD:n
"SOA ger IT den rörlighet som krävs för att kunna driva ett företag/koncern där verksamheten förändrar sig i snabb takt med avseende på out-sourcing, omorganisationer, sammanslagningar, konsolideringar, m m."
IT-chefen
"SOA suddar ut applikationsgränser som ersätts av mindre sammankopplade tjänster som kan återanvändas, kopplas in/ur baserat på i tiden alltid föränderliga policies."
Processansvarige
"SOA underlättar automatiseringen av processer (BPM) som går på tvären genom affärsområdena i en organisation."
Affärsområdesansvarige
"SOA ger möjligheten att snabbt förändra verksamheten inom en funktion istället för att vara slav under LOB-applikationerna."
Applikationsansvarige
"SOA river ned applikations-silos och ersätter dom med virtuella applikationsgränser som kontrolleras m h a policies."
Affärsutvecklare
"SOA är den arkitektur mot var man kan mappa verksamhetens tjänster direkt mot ett IT-stöd."
Driftteknikern
"SOA skapar en transparans av alla rörliga delar i IT-landskapet som man centralt kan kontrollera och administrera (ESB), precis som Microsofts Virtual Machine Manager (reklam) kontrollerar hela IT-infrastrukturen."
Integratören
"SOA medför att jag kan lägga EAI åt sidan och ägna mej åt viktigare saker."
Systemarkitekten
"SOA resulterar i att när nya krav ska realiseras så finns redan ett repository där säkert 90% av alla tjänster redan är implementerade vilket medför att min instats kan halveras i tid och pengar."
Systemutvecklaren
"SOA medför att jag måste lära mej XML."
Krönikörer och IT-sommelierer
"Bäst att hoppa på SOA-spåret även om jag är några år sen och skriva om hur man kan koppla ihop SOA med roller, metodik, taxonomi och metaforer och hur väl det sammanfaller med saker som jag sagt tidigare även det förvirrar mej själv mest av alla."
Bloggaren
"SOA har förvirrat en hel industri vilket jag kan dra fördela av genom att skriva den här typen av inlägg."
Utbildaren
"Undrar hur länge jag kan lura mina elever att SOA är EAI + Web Service innan jag måste skriva om min gamla integrationskurs från 90-talet."
Analytikern
"SOA har varit en riktig mjölkko när det kommer till buzz-words! Vad kommer härnäst?"
Applikationsutvecklaren
"Jag bygger några Web Services on-top av min applikation och vips så har jag en SOA, eller?"
tisdag, juni 12, 2007
BPM i vården
Tittade som vanligt på Uppdrag granskning som den här veckan handlade om hur mammografitester hamnade i arkiven utan att läkare hade granskat dom. I det här fallet hade den drabbade en cancertumör som aldrig upptäcktes på grund av att rutinerna inte fungerade.
Vanligtvis handlar det inte om liv eller död när rutiner brister, men det gör det i vården. Vad är det då för rutiner som brister och vad är rutiner över huvud taget? Rutiner innebär arbetssätt som tagits fram baserat på erfarenhet från tidigare fall och kunskap om dem. Att brista i sina rutiner innebär att man frångår arbetssättet och gör på något annat sätt.
Business Process Management (BPM) handlar om att skapa rutiner, automatisera rutiner, analysera erfarenheterna av rutinerna och förbättra rutinerna. Hade Sahlgrenska universitetssjukhuset automatiserat sina rutiner hade systemet upptäckt det här cancerfallet. Rutiner kommer alltid att brista p g a den mänskliga faktorn, även om SU verkar ha rena management problem dessutom.
BPM kommer spela en stor roll för att kvalitetssäkra rutinerna framöver, men i vården borde det implementeras omgående.
Vanligtvis handlar det inte om liv eller död när rutiner brister, men det gör det i vården. Vad är det då för rutiner som brister och vad är rutiner över huvud taget? Rutiner innebär arbetssätt som tagits fram baserat på erfarenhet från tidigare fall och kunskap om dem. Att brista i sina rutiner innebär att man frångår arbetssättet och gör på något annat sätt.
Business Process Management (BPM) handlar om att skapa rutiner, automatisera rutiner, analysera erfarenheterna av rutinerna och förbättra rutinerna. Hade Sahlgrenska universitetssjukhuset automatiserat sina rutiner hade systemet upptäckt det här cancerfallet. Rutiner kommer alltid att brista p g a den mänskliga faktorn, även om SU verkar ha rena management problem dessutom.
BPM kommer spela en stor roll för att kvalitetssäkra rutinerna framöver, men i vården borde det implementeras omgående.
måndag, maj 28, 2007
Neward sparkar på ORMen
Det är få gubbar som är så pass underhållande att lyssna till som Ted Neward. I .NET Rocks! diskuterar han objekt-RDB-mappning där samtalet ibland hettar till ordentligt med en kille som jobbar med nHibernate.
Lyssna här!
Lyssna här!
onsdag, maj 23, 2007
Separation of Concerns
Deltog i en diskussion om vad man med skiktade arkitekturer kan åstadkomma för att skapa föränderlighet i systemen vi bygger.
Förändringar i systemen sker alltid på sikt, men frågan är vilka förändringar. Antag två typer av förändringar, funktionella och tekniska:
Funktionella förändringar
Den skiktade arkitekturen kan inte alls svara upp mot funktionella förändringar, utan passar bättre för de tekniska kraven. Att kunna skapa nya lager eller att ersätta lager ger fördelar då man vill byta ut och lägga till teknik. Dimensionering kan hanteras genom att man skalar ut/upp runtime-miljön för ett lager. Hårdvaruvirtualisering bygger på skiktning i arkitekturen.
Framför allt tror jag att skiktade arkitekturer är populära för att man kan skapa 'Separation of Skills', dvs att vissa roller i exempelvis ett webutvecklingsprojekt kan jobba inom olika areas of interest, som man säger.
Visst kommer de tekniska förändringarna att kvarstå, men det är inget man tappar bara för att man inte bygger en traditionell skiktad arkitektur. Tvärtom så kommer SoC-design passa bättre även för de tekniska kraven.
Ser man till hur en skiktad design med lager på lager skulle hantera funktionella förändring så kan komplexiteten i relation till förändringstakten kunna se ut så här:
Tryggast är väl att det mest komplexa att ändra dvs processer kanske inte ändrar sig så ofta. Men det kan ju bero på att IT sitter och bromsar affärsutvecklingen med system som är byggda med skiktade arkitekturer.
Skapar man däremot en design där man skiljer de funktionella förändringarna åt logiskt så skulle det se annorlunda ut:
Förändringar i systemen sker alltid på sikt, men frågan är vilka förändringar. Antag två typer av förändringar, funktionella och tekniska:
Funktionella förändringar
- Regler - att kunna göra tillägg och förändringar av villkor i systemet som representerar affärsregler
- Processer - att ändra sekvensen av aktiviteter i en affärsprocess
- Information - att göra tillägg av nya informationsfält i den existerande datastrukturen
- Resurser - att i systemet ändra från att använda en viss resurs/tjänst till att använda en helt annan
- Händelser - att i systemet kunna hantera händelser som inte var påtänkta från början
- Applikationsserver - ex. ändra från IIS till Apache/Tomcat
- Databasserver - ex. ändra databasserver från SQL Server till MySQL
- Protokoll - ex. ändra kommunikationsprotokoll mellan logiska enheter i systemet
- Plattform - ex. flytta applikationen från Windows till Linux
- Hårdvara - ex. göra en tech-refresh av hårdvaran
- Säkerhet - ex. man vill göra applikationen åtkomlig över internet
- Dimensionering - ex. lyfta applikationen från 100 användare till 10000 användare
- Integration - ex. att man vill exponera funktioner och dataåtkomst via API:er
- Utökning - ex. bygga in nytt klientstöd för PDA:er och mobiltelefoner
Den skiktade arkitekturen kan inte alls svara upp mot funktionella förändringar, utan passar bättre för de tekniska kraven. Att kunna skapa nya lager eller att ersätta lager ger fördelar då man vill byta ut och lägga till teknik. Dimensionering kan hanteras genom att man skalar ut/upp runtime-miljön för ett lager. Hårdvaruvirtualisering bygger på skiktning i arkitekturen.
Framför allt tror jag att skiktade arkitekturer är populära för att man kan skapa 'Separation of Skills', dvs att vissa roller i exempelvis ett webutvecklingsprojekt kan jobba inom olika areas of interest, som man säger.
Visst kommer de tekniska förändringarna att kvarstå, men det är inget man tappar bara för att man inte bygger en traditionell skiktad arkitektur. Tvärtom så kommer SoC-design passa bättre även för de tekniska kraven.
Ser man till hur en skiktad design med lager på lager skulle hantera funktionella förändring så kan komplexiteten i relation till förändringstakten kunna se ut så här:
Tryggast är väl att det mest komplexa att ändra dvs processer kanske inte ändrar sig så ofta. Men det kan ju bero på att IT sitter och bromsar affärsutvecklingen med system som är byggda med skiktade arkitekturer.
Skapar man däremot en design där man skiljer de funktionella förändringarna åt logiskt så skulle det se annorlunda ut:
onsdag, maj 16, 2007
Väntar du också på bussen?
fredag, maj 04, 2007
Kategorisering av tjänster
En gång i månaden kommer The Architectural Journal med en ny utgåva. I nummer 11 finns det en artikel som hetter Ontology and Taxonomy of Services in a Service-Oriented Architecture där Shy Cohen beskriver vilka typer av tjänster som en Service Oriented Architecture byggs upp av:
Bus Services
Tror det återigen är viktigt att peka på att syftet med SOA inte är att kategorisera och generalisera över vilka tjänster man ska bygga, utan att se det som den infrastruktur som de s.k. Bus Service ska implementera. Dessutom är det lite väl sent att komma dragande med den här typen av artiklar nu när tekniken finns, kunderna är redo och det är dags att konkretisera istället för att flumma kring metaforer och ontologier.
Bus Services
- Communication Services - intermediära (mellan tjänster) tjänster som message routing, pub/sub, m m
- Utility Services - tjänster för Service Discovery, Identity Federation, m m
- Entity Services - tjänster som exponerar data entities
- Activity Services - tjänster som exponerar affärsspecifika funktioner
- Capability Services - tjänster som exponerar generella funktioner
- Process Services - tjänster som exponerar affärsprocesser
Tror det återigen är viktigt att peka på att syftet med SOA inte är att kategorisera och generalisera över vilka tjänster man ska bygga, utan att se det som den infrastruktur som de s.k. Bus Service ska implementera. Dessutom är det lite väl sent att komma dragande med den här typen av artiklar nu när tekniken finns, kunderna är redo och det är dags att konkretisera istället för att flumma kring metaforer och ontologier.
torsdag, mars 08, 2007
Vilka BPMS-leverantörer kommer att hänga med?
I Move with the flow så ställer jag frågan om framtidens BPM-stöd kommer att implementeras i ett centralt BPMS (dvs en produkt-suite som managerar alla automatiserade affärsprocesserna och arbetsflöden i företaget), eller om BPM-support kommer att erbjudas i varje enskild applikation. Om det nu är så att man kan centralisera implementationen av alla processer så betyder det att världen inte kommer att indelas i applikationer som det är idag, utan enbart tjänster som processerna nyttjar och orkestrerar. Det betyder att alla applikationsutvecklare måste bryta ned sina applikationer i små tjänster och konkurera om vem som har dom bästa tjänsterna, istället för dom bästa applikationerna. Hur troligt är det att SAP med flera skulle släppa sitt övertag man har tillfördel för BPMS-leverantörerna?
Nej, sannolikt kommer detta inte att ske utan att vi snarare kommer att se BPM-stöd implementeras i diverse applikationer och system framöver. Intressant är också att Microsoft samt några Open Source initiativ (ex. Ode) är de enda som kan erbjuda ramverk för BPM-stöd som applikationsutvecklare kan använda och hosta i applikationerna. Dessutom är det gratis att använda sig av detta ramverk, vilket man inte kan säga om man använder produkter från IBM, BEA, Oracle, SUN eller någon annan leverantör av process management/runtime support.
Frågan är också vilka som kommer att överleva den snabba takt som standarder kommer att ha inom det här området. Standarder som WS-*, BPEL, BPMN, m fl är idag i sina första versioner och många har lyckats leverera produkter baserat på dessa. Men när nya versioner släpps kommer många att tappa taget och släpa efter där enbart vissa stora leverantörer eller open source alternativ kommer att kunna överleva. Intalio är exempelvis är en BPMS-leverantör som öppnat sin källkod och det kommer nog inom sin tid visa sig vara lyckosamt för att hänga med utvecklingen av standarder.
Nej, sannolikt kommer detta inte att ske utan att vi snarare kommer att se BPM-stöd implementeras i diverse applikationer och system framöver. Intressant är också att Microsoft samt några Open Source initiativ (ex. Ode) är de enda som kan erbjuda ramverk för BPM-stöd som applikationsutvecklare kan använda och hosta i applikationerna. Dessutom är det gratis att använda sig av detta ramverk, vilket man inte kan säga om man använder produkter från IBM, BEA, Oracle, SUN eller någon annan leverantör av process management/runtime support.
Frågan är också vilka som kommer att överleva den snabba takt som standarder kommer att ha inom det här området. Standarder som WS-*, BPEL, BPMN, m fl är idag i sina första versioner och många har lyckats leverera produkter baserat på dessa. Men när nya versioner släpps kommer många att tappa taget och släpa efter där enbart vissa stora leverantörer eller open source alternativ kommer att kunna överleva. Intalio är exempelvis är en BPMS-leverantör som öppnat sin källkod och det kommer nog inom sin tid visa sig vara lyckosamt för att hänga med utvecklingen av standarder.
tisdag, februari 27, 2007
.NET-utvecklare - dags att lära sig WS-BPEL?
Passa på och få en inblick i WS-BPEL när OASIS (administrerar WS-BPEL specen) presenterar följande två webinars den 12-13 mars:
Microsoft satsar hårdare på BPEL
Du kanske redan har hört det men Microsoft annonserar nu att de under våren kommer att ha stöd för WS-BPEL 1.1 i WF mars CTP för import och export. Vid release senare i år av WF i Vista kommer stöd för WS-BPEL 2.0 att finnas. När det gäller BizTalk 2006 kommer MS inte att ge ytterliggare stöd som nu begränsar sig till WS-BPEL 1.0. När sedan BizTalk släpper nästa version så kommer WF vara en del av BTS och därmed även stödet för WS-BPEL 2.0.
Microsoft bygger en BPM-allians med partners
Igår på Gartner BPM Summit annonserade Microsoft en BPM-allians (BPA) tillsammans med ett antal företag, under parollen "People-Ready Process". BPM (Business Process Management) är en teknik som vänder sig till verksamheter som vill bygga upp IT-stöd för processhantering inom och mellan verksamhetens funktionella tjänster (HR, IT, Finans, etc).
Tekniken implementeras mha ett BPMS (Business Process Management Suite) där det ingår ett antal verktyg som samverkar med varandra för att skapa en miljö där processerna kan köras och hanteras. Microsoft har allierat sig med företag som representerar olika delar i ett BPMS:
Vad alliansen innebär kan du se mer om här.
Läs även David Chappells whitepaper om Microsofts BPM Suite.
Tekniken implementeras mha ett BPMS (Business Process Management Suite) där det ingår ett antal verktyg som samverkar med varandra för att skapa en miljö där processerna kan köras och hanteras. Microsoft har allierat sig med företag som representerar olika delar i ett BPMS:
- Business Process Modeling and Analysis
- Decision Management and Business Rules
- Business Process Management Suites
- Business Process and Human Workflow
- SOA Governance and Lifecycle Management
Vad alliansen innebär kan du se mer om här.
Läs även David Chappells whitepaper om Microsofts BPM Suite.
måndag, februari 12, 2007
Vad är en BOA?
Jag tycker om att hacka på objektorientering som i det här blogginlägget om Business-Oriented Architecture. Inget personligt men de svåraste problemen som företag idag har med IT vågar jag säga bottnar i objektorientering. När en programmerare ska lära sig ett programspråk så blir det ofta ett OO språk som Java, C++ eller C#, vilket gör att man från barnsben uppfostras i det felaktiga tänkandet. Under CORBA och COM tiden fanns det vissa ljuspunkter på himlen, men dessa trycktes tillbaka tillfördel för objektorienteringen. Idag är vi mer objektorienterade i vårat tänkande än någonsin. För att inte bli helt verklighetsfrämmande i objektvärlden så har man skapat abstraktioner (patterns och domänmodeller) som ska bygga broar mellan verkligheten och objektvärlden. Men det är en knackig väg som inte kan lyckas, det krävs att utvecklare lämnar OO och börjar tänka processer och tjänster.
söndag, februari 11, 2007
BPM in Action
Missa inte den här virtuella konferensen om BPM och BAM i mars.
Kolla även in den här intressanta bloggen.
Kolla även in den här intressanta bloggen.
tisdag, januari 16, 2007
Förutsägelser inför 2007
Det kanske är lite magstarkt att plita ned en spådom inför det här året, men här kommer ännu en profetia:
- Teknikfokuserade mjukvaruleverantörer kommer att närma sig de affärsorienterade genom att döpa eller branda om sina produkter från att vara en ESB till ett BPMS. De kommer att bygga in bättre support för processmodellering och inte bara erbjuda BPEL utan även andra standarder som BPMN. Budskapet kommer inte enbart att bygga på integrationen mellan funktions- och informationssilos (det gamla EAI-budskapet) utan även om processer.
- Affärsfokuserade mjukvaruleverantörer kommer att närma sig de teknikfokuserad. De inser att deras idag properitära system inte får riktig slagkraft om de inte supporterar Web Services och BPEL.
- BPEL kommer att få ännu större genomslag när många av dagens leverantörer av BPMS implementerar BPEL som processpråk.
- Detta är året då bl a Cornerstone kommer att erbjuda kurser i WS-BPEL.
- Det är detta år vi inser att runtime governance av web services inte kommer att vara värt att implementera till den nivå som SOA-drevet vill göra gällande. Det är inte på service-nivån som man skapar lösa kopplingar mellan applikationer/tjänster.
lördag, januari 06, 2007
Året som gick
Förra året skrev jag ned några punkter som jag trodde skulle resultera i allmänna insikter om SOA. Så här i efterhand går det att konstatera att jag inte alls hade rätt, utan fick istället själv en viktig insikt om SOA - nämligen att SOA aldrig kommer bli något annat än EAI med Web Services.
Diskussionen om SOA kommer aldrig att komma upp då man pratar om tjänster i ett verksamhetensperspektiv, utan enbart i exponeringssammanhang. Exponering av system/applikationer som ska integreras. Det kommer att innebära att en SOA-diskussion inte kommer att tränga in i diskussionen om tjänstenätverket som är fundamentet för en Full SOA Application.
Så istället är det mer intressant att följa det BPM community som mer och mer närmar sig de insikter jag skrev om SOA under 2006.
Diskussionen om SOA kommer aldrig att komma upp då man pratar om tjänster i ett verksamhetensperspektiv, utan enbart i exponeringssammanhang. Exponering av system/applikationer som ska integreras. Det kommer att innebära att en SOA-diskussion inte kommer att tränga in i diskussionen om tjänstenätverket som är fundamentet för en Full SOA Application.
Så istället är det mer intressant att följa det BPM community som mer och mer närmar sig de insikter jag skrev om SOA under 2006.
Prenumerera på:
Inlägg (Atom)