Choreographic techniques

The Three R's of SOA: Reuse, Reuse, Reuse!

2008-04-06T09:41:00.004+02:00

Är fördelen med SOA att kunna återanvända eller skapa rörlighet?

Det har alltid debatterats om SOA handlar om återanvändning eller rörlighet. När man säger återanvändning kan man antingen avse att ta till vara på redan existerande investeringar (ERP, CRM, osv) eller så pratar man om bättre förutsättningar för återanvändning från och med ett införande av SOA. Med rörlighet avses oftast förmågan i den tjänsteorienterade arkitekturen att förändras med affärens nya behov. Att kunna ställa om kommunikationen med tjänster baserat på regler och policies. Ex. Anta att ett företag som är beroende av import av komponenter i en produktionskedja kan styra om orderflödet baserat på dollarpriset.

Men vart ifrån kommer dom olika rösterna som så gärna vill få allmänheten att förstå fördelarna med SOA?

Att sätta återanvändning av existerande system och applikationer i första rummet är intressant för dem som lever på att det just deras gamla system fortfarande körs. IBM som är den största förespråkaren av återanvändning i samband med SOA "The Three R's of SOA: Reuse, Reuse, Reuse!". Det andra perspektivet på återanvändning är gammalt, dvs att mjukvaruindustrin alltid har försökt skapa förutsättningar för att återanvända kod, komponenter, patterns, etc. Det är på något sätt den våta drömmen för en hel bransch.

Vart kommer målen med rörlighet ifrån då? Ja inte är det från IBM eller från teknikbranschen. De kommer från den andra sidan, de som har tvingats leva med IBMs produkter eller med godtyckliga system där återanvändning varit i fokus när arkitekturen sattes. Att skapa rörlighet eller som man ofta säger, "align business with IT", handlar om att ha 1-1 mappning mellan verksamhetens delar och de delar som automatiserar dessa funktioner. SOA för in perspektivet att tjänst motsvarar tjänst - verksamhetstjänst mappas 1-1 mot dess implementation. Här pratar man inte SOA som vilka entitetstjänster som helst. Här pratar man inte om löst kopplade delar som om det gällde förhållandet mellan en drop-down lista och en SQL View.

Så länge dessa två motpoler som beskriver målet med SOA står mot varandra kommer inte SOA att skjuta fart. Återanvändning är ett direkt hinder för rörlighet där man historiskt kan peka på tragiska koncept som objektorientering där man lyckats skapa de mest statiska system pga återanvändning. Varje gång man återanvänder något skapar man ett beroende. Det kan vara databaser som delas av flera funktioner i en produktionslinje, det kan vara objektlager som används på samma sätt, eller för den delen tjänster som återanvänds mellan klienter och konsumenter. SOA bidrar inte alls till förutsättningen att lyckas med återanvändning. Det kan aldrig bli en teknisk fråga, det är inbyggt i oss som människor att skapa nytt. Speciellt gäller det utvecklare, som för det mesta har sin egna agenda och världsbild.

Agilt - ägarens mardröm

2008-02-29T11:01:00.001+01:00

Ponera att du bestämt dig för att byta bostad. Du har valt att flytta till ett hus, som du ska placera på en tomt som du köpt. Du har en bild framför dig av hur ditt hus ska se ut, hur många sovrum du skulle vilja ha, färg i köket, veranda att ställa grillen på, osv. Hur går du till väga för att realisera din dröm?

Du tar in en snickare så klart. Eller varför inte 10 stycken, eftersom du vill få upp huset innan sommaren så du kan börja grilla på verandan. Snickarna är redo, dom har nämligen alla en liten verktygslåda med sig fylld med hammare, skruvmejslar och annat bra-att-ha.

En självutnämnd snickare utan tålamod säger.

- "Vad önskas?"

Du förklarar.

- "Jag vill ha ett hus, med två sovrum och vitt kök och en veranda som jag kan grilla på."

Snickaren fyller i.

- "Bra, men vi behöver börja med en grund för annars har huset inget att stå på. Hur vill du ha grunden?"

Du säger.

- "Ähh, vet inte. Men bygg en bra som passar alla möjliga hus så är vi på säkra sidan."

Snickaren nickar.

- "Ok, då sätter vi igång. Kommer du på något på vägen så håll det för dig själv så tar vi det när grunden är färdig. Skulle det innebära att vi behöver ändra grunden så gör vi det så gärna när vi är klara."

Snickarna sätter igång. De upptäcker att de behöver verktyg utöver det dom har i verktygslådan. Dom upptäcker även att ingen hade lagt en grund tidigare, eftersom alla var snickare. Men hur svårt kan det vara ...

Under tiden som snickarna kliar sig i huvudet och lägger grunden till alla varianter av tilltänkta hus så börjar du se en tydligare bild av vad du önskar för hus.

När dom är klara med grunden säger du att.

- "Jag vill nog ha en källare i halva huset eftersom det visade sig att vi inte kan bygga på höjden och tomten är för liten för enbart ett plan."

Snickaren.

- "Inga problem. Vi tar bort grunden, gräver ut för källaren och lägger om grunden."

Snickarna sätter igång och slår på grunden med sina hammare men upptäcker att det inte går så de skaffar fram maskiner. Mer maskiner för att gräva ut för källaren och mer gjutning för den nya grunden. När dom är klara upptäcker dom att vatten börjar rinna in eftersom dom grävt mitt i en naturlig ådra i marken. Dom blir tvungna att gräva en ny dränering för grunden, under huset, eftersom det trängde in underifrån.

Snickarna blir med tiden skickliga på det mesta eftersom det visade sig att bygga hus inte bara handlade om att slå in spikar i en vägg. Dom har lärt sig köra maskiner, dra el och vatten, lägga en grund, med mera.

Du har tillslut fått ett hus precis som du ville ha det. Helt unikt, något som ingen annan har ... eller? Du känner dig lite frustrerad för det kostade aningen mer än du kalkylerade med efter att du fått offerter från entreprenörerna i början. Men samtidigt tar du på dig skulden själv eftersom snickarna gjorde vad dom kunde. Dom kan man ju inte ställa till svars för dom gjorde ju det jag sa.

Ja, det är så här mjukvara utvecklas idag med agila metoder. Det finns idag husägare som tagit sig igenom denna upplevelse, vilket troligen resulterat i både skilsmässor och alkoholproblem. Det här sättet att arbeta på när det gäller mjukvaruutveckling är den starkaste trenden just nu. Det pekar helt i fel riktning och mot allt sunt förnuft.

Optimering av processer

2008-02-23T12:26:00.003+01:00

När man kommer in på fördelarna med BPM hamnar man ofta i en diskussion kring effektivisering av processer. Det finns tre huvudtyper av förbättringar man kan göra.

Att optimera flödet i processen, ex:
- Parallellisera aktiviteter, istället för sekventiella steg
- Skapa asynkrona anrop från processen, istället för att vänta på resultat så man kan gå vidare och hantera svaret när det kommer
- Regelbaserade flöden som anpassar sig efter förutsättningarna
Att optimera enskilda processteg, ex:
- Utbilda aktören, m m för att ge aktören bästa förutsättningarna att utföra uppgiften
- Optimera systemstödet, dvs att ge aktören bättre systemstöd i uppgiften
  - Rollbaserade gränssnitt
  - Mer produktiva gränssnitt (ex Office)
  - Samlade informationsbilder
  - Samlade transaktioner (genom system-integration)
- Automatisera delvis, dvs att ge aktören ett systemstöd i uppgiften
- Automatisera helt och hållet, dvs att låta ett system utföra uppgiften istället för en människa
- Automatisera och implementera som sub-process; skapar integrerad mätbarhet
- Använda en annan tjänst som helt enkelt påstår sig vara snabbare än den aktuella
Att optimera tilldelningen av arbetet (oavsett om det är automatiserat eller ej), ex:
- Fördelning av arbete med hänsyn till belastning hos resurserna
- Fördelning av arbete med hänsyn till kunskap och andra förutsättningar hos resurserna
- Policy-styrd tilldelning, baserat på Service Level Agreements

Nu ska jag läsa min nyinköpta bok om Six Sigma för att dyka ner i en beprövad metod för processoptimering.

BPM i topp bland CIOer

2008-02-21T21:36:00.001+01:00

BI, ERP och CRM hör till de stora investeringarna om en CIO får bestämma, enligt IDG. Intressant är att när det kommer till BPM så sammanfattar man det med att - "BPM är fortfarande i topp bland de tekniska prioriteringarna.". Vidare menar man att "30 procent av de tillfrågade svarade att de skulle vilja ha ännu mer tid att utveckla sådana system."

BPM skiljer sig från BI, ERP, CRM, EAI och nämnda initiativ på den punkten att IT inte behöver kopplas in för att dra fördel av BPM. BPM är inte en "teknisk prioritering", utan en affärsdriven.

Dessutom krävs en stor mognadsgrad för att implementera BPM-lösningar med automatiserade processteg, vilket de flesta processimplementationer sällan eller adrig behöver komma i kontakt med för att få ut värdet av investeringen.

Därför skulle man kunna säga att BPM är en "killer-application" för SaaS ur det perspektiv att man kan isolera den tjänsten från interna verktyg och system. Kommunikation mellan ett system för BPM och verksamhetens aktörer hanteras oftast genom en Task Inbox eller Mail. Sällan eller aldrig, som sagt, kommer ett intregrationsscenario att krävas för de som vill starta med BPM oavsett generell IT-mognad.

BPM for Dummies

2008-02-21T20:47:00.000+01:00

Har du kommit i kontakt med BPM, CPI eller BAM och behöver en snabb överblick av ämnet så ska du läsa den här boken.

10 tips för processmodellering i BPMN

2008-02-08T13:11:00.000+01:00

Bruce Silver ger grundläggande tips på hur man modellerar affärsprocesser i BPMN.

Business Process Management Maturity Model

2008-02-08T11:14:00.002+01:00

Jag tror den här bilden från Gartner, som illustrerar en mognadsgrad inom Business Process Management, presenterades dels under den pågående konferensen men även den i höstas. Bilden visar hur man med kontrollen över sitt företagets processer leder till olika mognadsgrad.

Monitorer enskilda aktiviteter
Modellera och analysera processerna
Identifiera ägare av processer
Etablera kontroll över processerna
Skapa en direkt förhållande mellan modellerna över processer och regler till exekveringen av dem
Jämför möjliga alternativa processer i realtid i optimeringssyfte
Inför kontroll över kostnader baserat på aktiviteter istället för enheter i organisationen
Sammanför processerna med marknadsstrategier
Fördela processautomatisering och kontroll ut i organisationen, bland partners och kunder
Koppla samman mätning av förmåga och kapacitet i processen tillbaka till exekveringen av processen
Förädla tjänster och processer baserat på den lättrörlighet man åstadkommit

Modeller som vapen

2008-02-03T21:21:00.001+01:00

Det finns tre typer av människor. Vilken är du?

1) Den visionära människan
2) Den vanliga människan
3) Den cyniska människan

Den visionära människan är den som utnyttjar den vanliga människan, men som inte kan rå på den cyniska människan. Den vanliga människan är den som behöver något att tro på, medan den visionära människan, som känner till den vanliga människans svaghet, drar fördelar av det. Den cyniska människan står bredvid och ser på hur den vanliga människan faller offer för den visionära människans metoder, som egentligen bara går ut på att projicera det sunda förnuftet på en modell.

Modellen används som lösningen på diverse problem som den vanliga människan behöver hantera. Modellen passar in i den vanliga människans vardag och känns därför självklar för den vanliga människan. Den visionära människan blir en guru då han så skickligt kan skriva ned sin modell med ett par axiom som den vanliga människan kan repetera som lagar. Den vanliga människan vill inte se självklarheterna i modellen utan faller för dess charm och dyrkar den visionära människans predikan.

Den visionära och den cyniska människan kan följa hur den vanliga människan tar till sig modellen med hull och hår och applicerar den på även andra människors vardag. Olika vanliga människor med olika bakgrund var inte modellen skapt för. Den vanliga människan ser inte skillnaderna och att modellen inte passar in, samtidigt som den visionära människan backar tillbaka. Den visionära människan har i det här läget tappat kontrollen om situationen och befinner sig i andra tankar. Det är för sent och den vanliga människan kan inte längre styras. Den vanliga människan kan nu inte stoppas utan hamrar in sin modell i olika miljöer oavsett om den passar in eller ej.

Den cyniska människan förfäras över den gräshoppssvärm som drar fram men driver ändå utan framgång sin upplysning om skillnaderna som om den vanliga människan skulle bry sig. Drevet är igång och massan rör sig av sig självt.

Arkitektens roll på riktigt

2008-02-03T19:59:00.000+01:00

Den här podcasten spelades in i Dec -07 men släpptes genom SOA Consortium alldeles nyligen. Panelen består av tre Enterprise Architects som ger sin syn på sin egen roll, deras respektive företags SOA och BPM strategi. Mycket utlämnande av hur arkitekter arbetar med dom stora frågorna.

User Panel:
EA practitioners will look at the links, synergies and differences between SOA and enterprise architecture. How does SOA fit into the EA picture? How can it help make EA more valuable? Does SOA need to be part of a broader EA? Hear from the panelists -- their firsthand experience and lessons learned.

Moderators:
Richard Soley, Executive Director, SOA Consortium; Chairman and CEO Object Management Group
Nicholas Gall, VP Distinguished Analyst, Gartner

Panelists:
Todd Biske, Senior Enterprise Architect, Monsanto
Bill Conroy, Head of Enteprise Architecture Division, Bank of America
Sam Vetto, Enterprise Architect, The Hartford

Gartner Business Process Management Summit

2008-01-31T22:29:00.000+01:00

Gartners Business Process Management Summit är på gång nästa vecka och på hemsidan finns en länk till Daryl Plummers fantastiska SOA/BPM session från i höstas.

Agila metoder passar bäst för DotComs

2008-01-29T22:51:00.000+01:00

Refactoring har blivit en naturlig del i agile mjukvaruutveckling. Frågan är bara hur stor del den tar av en utvecklingscykel och blir nettoeffekten positiv för resultatet.

Det är ju allmänt känt att agila metoder passar bäst för små projekt, utan externa beroenden, som ska utveckla en ny mjukvara/applikation. Det i kombination med att produktägaren är klar över vilka features som kommer skapa affärsvärde. Summan av dom förutsättningarna kan sammanfattas med ett ord, DOTCOM.

Idag ser vi inte mycket DOTCOM-projekt, även om dom finns. Däremot finns det liknande karaktärsdrag hos andra projekt där agila metoder lyckas väl. Dom projekten delar ofta samma förutsättningar med avseende på storlek och omfattning. Projekt som däremot får in beroende till andra system, externa parter, integration, governance och del av en enterprise arkitektur kan inte lyckas lika väl med agila metoder.

Agila metoder går nämligen ut på att inte ta hänsyn. Scrum har exempelvis sina sprintar där man trycker in s.k. stories. Hur de implementeras är inte intressant, bara att dom implementeras. Hur kan man alltid göra om, då man refactorerar. Har man externa beroenden så måste man ta hänsyn, följa riktlinjer, förhålla sig till en integrationsplattform, masterdata, krav på återanvändning, m m. Agila metoder har ett sätt att tackla förhållningsregler, men då enbart inom projektet - nämligen genom refactoring eller "gör om, gör rätt".

Steve Vinoski - ett RESTafarian

2007-10-05T16:47:00.000+02:00

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?

SOA: Ett digitalt universum

2007-10-01T22:07:00.000+02:00

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!

Agila projekt misslyckas

2007-09-05T18:47:00.000+02:00

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.

SOA klarnar

2007-08-21T09:22:00.000+02:00

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.

Microsoft SOA Webcasts

2007-08-14T11:21:00.000+02:00

SOA Webcasts från Microsoft

SOA-OD

2007-08-07T15:49:00.000+02:00

Mer TIBCO humor ...

Påminner om Team America.

Virtualisering och SOA

2007-07-26T16:04:00.000+02:00

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.

Fler definitioner på SOA

2007-07-25T19:12:00.000+02:00

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.

Pattern-ister och GPSer

2007-07-19T13:40:00.000+02:00

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.

BPEL4People bjuder in människor

2007-07-10T22:54:00.000+02:00

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.

Processorienterad design

2007-07-03T22:16:00.000+02:00

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.

Varför blogga?

2007-07-03T17:02:00.000+02:00

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.

Revenge of the nerds (Getting Real)

2007-06-18T11:55:00.000+02:00

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:

"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."

Det finns även rätt självklara saker som man kan skriva under på:

"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."

AOP & EAI - två av samma sort

2007-06-14T13:31:00.000+02:00

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.