Ä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.
söndag, april 06, 2008
fredag, februari 29, 2008
Agilt - ägarens mardröm
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.
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.
lördag, februari 23, 2008
Optimering av processer
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
torsdag, februari 21, 2008
BPM i topp bland CIOer
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 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
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.
fredag, februari 08, 2008
Business Process Management Maturity Model
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
söndag, februari 03, 2008
Modeller som vapen
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.
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
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.
Todd Biske, Senior Enterprise Architect, Monsanto
Bill Conroy, Head of Enteprise Architecture Division, Bank of America
Sam Vetto, Enterprise Architect, The Hartford
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
torsdag, januari 31, 2008
Gartner Business Process Management Summit
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.
tisdag, januari 29, 2008
Agila metoder passar bäst för DotComs
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".
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".
Prenumerera på:
Inlägg (Atom)