Någon som kan rekommendera någon kurs med inriktning på arkitektur och mönster inom .NET?

Gärna i Göteborg.

Du får hänga med på SweNug träffarna i GBG. de är gratis tar upp många olika ämnen.
Sedan missade du just en intressant kurs/seminarie om Pimp my code som arrangerades av Cornerstone som tog upp lite design mönster m.m.

SwwNug kommer då åt via www.swenug.com eller maila mig för komma med i mailistan.
är arrangör av Swenug gbg ihop med en till. johan.normen@hiq.se så kan jag lägga till dig.
Näst ut nu blir Linq den 22 Nov alla dessa träffar är efter 17:00 och kostar inget.
Nästa ämne efter Linq blir Team System 2008...

Mvh Johan

Sundblad och sunblad kommer snart ut med en online utbildning inom arkitektur med inriktning på .net.
finns en preview av kursen här http://www.2xsundblad.com/OnlineArchTraining/ArchSOSystemsOverview.html

Deras kurs är mer inriktad på enterprise arktiektur när kopplat till verksamheten fokuserat på SOA. Så om det är det du är ute efter så kan det ju vara intressant.

Luras inte in i deras träsk ;)

Ta en titt på Cornerstone det finns även i GBG, de har ibland lite specialkurser.
www.cornerstone.se

Sen har du ju Informator i gbg också.

sundbladarnas certifierings program tog iaf upp mönster, och inte enbart enterprisearkitektur och soa. och jag tror nog den här online kursen kommer innehålla båda eftersom den tagit upp 5 olika arkitekt roller. men visst det kan va på lite för hög nivå.

Men många av deras pattern var väl deras egna påfund? Eller deras ideér hur de skall implementeras.
Roliga med just patterns är att de går att göra massa olika implementationer på dem och inte en enda strikt...

Många certifieringar som finns idag är lite farliga, de är som en robot gör så här annars gör du fel...
Men så gullig är inte världen av kod :-) Det finns inget rätt eller fel... bara bättre o sämre baserat på vem betraktaren är :-)

Så skall man plugga desingmönster kan man börja med GOF Design Pattern boken helt ok bok.
De säger oxå att deras kodexempel inte är en bibel på hur de skall kodas utan bara just exempel på hur man kan lösa ett problem med ett visst möster vid framtida liknande problem.

Sen finns det massa andra söta Patterns böcker, Martin Fowler har skrivit en helt ok, Enterprise patterns, plus många fler... Så mitt tips är: Lås er aldrig till just en persons idéer utan ta del av många för att inte bli stackars låsta robotar där ute :-)

mvh Johan

nja de gick igenom några "vanliga" gof mönster på pattern kursen och rekomenderade böcker bland annat de du nämde av gof och fowler.

och visst certifieringar ska man alltid ta med en nypa salt, och tänka själv bör man ju göra.

men frågan om kurser , jag hittar bara ett fåtal när jag gjorde en snabb googling de verkar ju mer kod inriktade än vad sundblads kurser är.

http://www.jonssonlepp.se/Utbildning/Kurs/?CourseID=141
http://www.learningtree.se/courses/se511.htm

Tack för alla svar.

denna kurs verkar intressant.
http://www.jonssonlepp.se/Utbildning/Kurs/?CourseID=141

Hej Patrik,

Tyvärr måste jag gå emot dig här. Vi nämner enterprise-arkitektur i vår kommande online-kurs, men fokus i kursen ligger absolut inte på det. Däremot har du alldeles rätt i att vi har ett starkt fokus på att mjukvaruarkitektur skall vara kopplad till verksamhetens arkitektur. Det är en röd tråd genom allt det vi gör, och jag tror att det är en förutsättning för att vi som systemutvecklare skall göra verklig nytta. En stor del av de "onödiga" IT-kostnader företagen har beror på att alltför många av oss underskattar behovet av sådan koppling.

Jag kan också berätta att vi om någon vecka kommer att lansera 2xSundblad Academy (http://academy.2xSundblad.com - dock inte öppnad än) med ett curriculum om 10 kurser (den första lanseras och blir tillgänglig samtidigt som akademin. Samtliga kurser är och förblir baserade på Microsoft Silverlight. Den första innehåller cirka 150 XAML-filer och ungefär lika många videoclips). Fem av kurserna kommer att handla om arkitektur, fem om implementering av arkitektur. I de kurserna går vi självklart hela vägen ner till färdig kod.

Bästa hälsningar
/Sten

Till Johan Normén:

Hej Johan. Du skriver ju litet då och då i olika sammanhang om oss och våra aktiviteter, men jag känner aldrig igen oss i det du skriver. Ibland, som idag, när jag läser dina inlägg önskar jag att du hade gått på någon av våra aktiviteter/utbildningar så att du fick bara en liten, liten uppfattning om vad vi gör och hur vårt budskap ser ut.

Helt apropå, Gartner Group säger att 2008 kommer SOA att bli den dominerande mjukvaruarkitekturen och därmed avsluta den 40-åriga dominansen av monolitiska mjukvaruarkitekturer. De säger också att den viktigaste fördelen med SOA är den "business agility" som kommer av möjligheten att närmare än hittills koppla mjukvaruarkitektur till verksamhetsarkitektur. Så vi är inte helt ensamma i vår inställning.

Bästa hälsningar
/Sten

Hej Sten,

Ja, jag har sett ert nya initiativ och det är jättespännande. Vad gäller mitt använande av enterprise arktiektur så är det inte i baserat på den definition som IASA presenterade för några månader sedan och alltså inte samma definition som ni har i er kurs. Vad jag i mitt inlägg avsåg vara "enterprise-arktitektur" var arktiektur mer lämpat åt stora "enterprises" än den typ av lösningar som är allmänt målgruppen på pellesoft.

Det är också så att era kurser har, förutom en stark koppling till verksamheten, också har ett starkt SOA fokus (eller har det ändrats? ) och SOA i all dess prakt är inte vad man vanligtvtis menar när man pratar om design mönster utan är ett vedertaget uttryck för objekt-orienterade mönster a'la GOF, PoEAA eller DDD i de kretsar som brukar vara här.

Sammanfattningsvis, all respekt för era kurser och det värde de ger en organisation som skall implementera SOA, men det var inte vad jag uppfattade att frågeställaren var ute efter.

"Helt apropå, Gartner Group säger att 2008 kommer SOA att bli den dominerande mjukvaruarkitekturen och därmed avsluta den 40-åriga dominansen av monolitiska mjukvaruarkitekturer. De säger också att den viktigaste fördelen med SOA är den "business agility" som kommer av möjligheten att närmare än hittills koppla mjukvaruarkitektur till verksamhetsarkitektur. Så vi är inte helt ensamma i vår inställning."

Nja, bussiness agility kommer vara det dominerande under 2008. Men SOA är ju tyvärr illa definerat och alldeles för ofta förknippat med andra typer av practices som kanske inte är lika smickrande.

Jag väntar fortfarande på att få se någon på riktigt kombinera bussiness agility med project agility och programming agility istället för att bara fokusera på en och diskvalificera de andra. Eller, jag väntar fortfarande på att få se en definition av SOA som inte bara anser att bussiness agility på cyklar av 1 år eller mer är det viktiga när mjukvara är inblandat.

Hej igen Patrik,

Tack för de vänliga orden om vårt nya initiativ. Vi tycker också att det är oerhört spännande, och vi har redan fått mycket positiv feedback från olika håll runt om i världen, så vi tror det kan bli riktigt bra.

Jag förstår vad du menar med din användning av begreppet enterprise-arkitktur. Du menar egentligen "arkitektur som passar för större företag och organisationer":-). Men du gör mig förvånad när du säger att den typen av lösningar skulle vara mindre intressant för deltagare i pellesoft. Är det verkligen så?

Bara som en liten upplysning vill jag också nämna att vi inte riktigt delar den syn som kommit fram i IASAs dokument om bland annat enterprisearkitektens roll. Men det har vi tydligt deklarerat för den grupp som tagit fram dokumentet. Skillnaden beror på att gruppen arbetat med ett medvetet och valt renodlat IT-perspektiv, och då är deras definition helt OK. Men vi har som sagt en något annorlunda bild.

Du har också helt rätt i att våra kurser inte bara har en stark koppling till verksamheten utan också ett starkt SOA-fokus. Och jag håller med dig om att när man diskuterar serviceorienterad ARKITEKTUR (förlåt versalerna, men jag ville tydligt skilja på arkitektur och implementation) talar man inte om designmönster som GOF etcetra. Då talar vi hellre om service-orienterade arkitekturmönster som ligger på en annan abstraktionsnivå. Men då man IMPLEMENTERAR en SOA-baserad tjänst kan både objektorienterade designmönster och applikationsblock komma till pass.

Hej igen Patrik,

Det här är svar/kommentar - egentligen också fråga - till ditt andra svarsinlägg, det om Gartner Group.

Det börjar bli en vana att hålla med dig, men jag måste göra det igen. Visst är SOA (på många håll) inte bara dåligt definierat och tyvärr ofta även fullständigt missförstått. Alltför många tror att SOA har med teknik att göra, och det har det ju bara till ringa del. SOA är framförallt en verksamhetsfråga, och där ligger dels SOAs styrka och dels möjligheten att på hittills oanade sätt anpassa IT-strukturer till verksamhetsstrukturer.

Du skriver också "jag väntar fortfarande på att få se en definition av SOA som inte bara anser att bussiness agility på cyklar av 1 år eller mer är det viktiga när mjukvara är inblandat." Det låter intressant, men jag förstår det inte. Vore jättekul om du ville utveckla den tanken litet mer.

Hej Sten,

Jag var faktiskt aktiv i era presentationer då ni presenterade många idéer då .Net kom. Har även vartit med på dragningar där ni pratat SOA. Jag har även arbetat med massa kunder som reffererat till er då de baserat sina system på er sätt. Och som även tagit cert hos er.

Problement har nog mer vart att de kanske inte förstått er, för det är inte lätt att lära ut arkitektur då det kan byggas på så många olika sätt. Det är bara att följa många arkitekturtrådar här på Pellesoft så märker man hur svårt många har med det hela. Hur lätt de missförstått saker m.m.
Där av vill jag inte rekommendera enbart er som källa utan att de skall titta runt på olika saker.
Vore fel av mig som kallar mig enterprise arkitekt att faktiskt bara refferera till ett mönster. Jag säger inte att det är dåligt mönster heller, bara att arkitektur är så mycket mer än så.

Rörande statistikbolag så tilltalar inte det mig :-( SOA får gärna bli 2008s mönster, men hoppas då det blir inne där det hör hemma. SOA är en av många arkitekturer hur mycket man än vridet och vänder på det så passar det inte alla lösningar.

Mvh Johan

Till Johan N:
Jag har svårt att förstå vad du säger, så jag har två frågor till dig:

1) När du säger att du som enterprisearkitekt inte kan referera till bara ett mönster, vad menar du egentligen då (i debatt med mig)?
2) När du kallar dig enterprisearkitekt, vad menar du då att du har för ansvar och uppgifter?

<b>"Vi tycker också att det är oerhört spännande, och vi har redan fått mycket positiv feedback från olika håll runt om i världen, så vi tror det kan bli riktigt bra."</b>

En av de saker jag är väldigt nyfiken på är hur formatet slår igenom. Traditionellt har e-learningen haft en hel del utmaningar för IT-relaterad utbildning, men det känns som att er nisch kan vara ett utmärkt område för online-baserad inlärning. Vi laborerar hela tiden med olika format och det ni valt är ett av de vi kommit fram till har störst chans att lyckas, så igen, väldigt intressant att se hur utfallet blir.

<b>"Men du gör mig förvånad när du säger att den typen av lösningar skulle vara mindre intressant för deltagare i pellesoft. Är det verkligen så?"</b>

Det är min uppfattning efter att både utbildat .NET communityn i snart 7 år och varit aktiv bland annat här på pellesoft att många lösningar som byggs idag inte nödvändigtvis får tillräckligt många fördelar av SOA för att kunna räkna hem den overhead som det kan innebära för ett utvecklingsprojekt. Där menar jag finns andra typer av arkitektur och metoder för att komma närmare verksamheten som är lite mer lättviktiga men ändå tillåter migrering till en SOA om det så skulle krävas. Jag tänker då tex på DDD där ett stort fokus är att ta verksamheten närmare projektet utan att för den sakens skull nödvändigtvis krävër att organisationen linjerar sin verksamhet enligt SOA. Det kräver en viss mognadsgrad hos verksamheten för att införandet av SOA skall räknas som lyckosamt. Många är inte där idag, många har knappt definerade processer på plats.

<b>"Och jag håller med dig om att när man diskuterar serviceorienterad ARKITEKTUR (förlåt versalerna, men jag ville tydligt skilja på arkitektur och implementation) talar man inte om designmönster som GOF etcetra. Då talar vi hellre om service-orienterade arkitekturmönster som ligger på en annan abstraktionsnivå. Men då man IMPLEMENTERAR en SOA-baserad tjänst kan både objektorienterade designmönster och applikationsblock komma till pass."</b>

Det här är glädjande att höra dig säga, så sent som mars 2006 fick jag uppfattningen att du och Per hade åskiten att objektorienterade mönster var ett problem för en arkitektur för bussiness agility. (jag tänker på inlägget "Taking sides with clemens" som verkar försvunnit i flytten av er blogg). Jag tycker dock att artikeln ni skrev i Juni förra året, "Software Architecture vs. Software Engineering", ganska bra sammanfattar varför arkitektur och implementation bör vara åtskilda och inte påverka varandra i för stor utsträckning.


<b>"Du skriver också "jag väntar fortfarande på att få se en definition av SOA som inte bara anser att bussiness agility på cyklar av 1 år eller mer är det viktiga när mjukvara är inblandat." Det låter intressant, men jag förstår det inte. Vore jättekul om du ville utveckla den tanken litet mer."</b>

Min erfarenhet är att många som praktiserar SOA oftast faller in i vattenfallsmodeller och många SOA evangelister anser att den logiska följden av SOA är att vi får återgå till "top-down" och "big up front design". Det är också min känsla att SOA evangelister oftast diskvalificerar agila projektmodeller och agila utvecklingsmetoder, jag anser att de har fel och skulle vilja se mer arbete göras runt integrationen mellan bussiness agility och project/development agility för att få flexibiliteten i hela verksamheten.

Jag har haft långa diskussioner med bla Dan North och Greg Hophe från Thoughtworks(eller Hophe har ju gått till google) och Beat Schwegler om hur ett sådant giftermål kan formaliseras men jag har som sagt idag inte sett så mycket arbete runt det. Jag skulle vilja kalla det ASO (Agile Service Orientation) om inte begreppet redan är upptaget.

<b>Det är min uppfattning efter att både utbildat .NET communityn i snart 7 år och varit aktiv bland annat här på pellesoft att många lösningar som byggs idag inte nödvändigtvis får tillräckligt många fördelar av SOA för att kunna räkna hem den overhead som det kan innebära för ett utvecklingsprojekt</b>

Kommenterar mig själv, vad gäller de projekt jag själv varit aktiv i så har jag länge varit väldigt försiktig med att införa någon form av SO innan verksamheten visat upp de rätta tecknen eller sagt de rätta magiska orden. Jag har istället arbetat mycket mer objektorienterat a'la DDD och bara använt SO i de fall integration varit nödvändigt.

Det är bara på senare år mina kunder, och verksamheten jag arbetar i, visat upp den mognadsgrad och ställt krav från verksamheten som kräver att flytta system till en SOA, men det är ett fåtal och om man fick mäta dem med Microsofts APIO så skulle jag vilja säga att de fortfarande är kvar på "Basic" nivån i stor utsträckning.

1) När du säger att du som enterprisearkitekt inte kan referera till bara ett mönster, vad menar du egentligen då (i debatt med mig)?
- Jag syftar på varför jag rekomenderar folk att inte bara titta på ett mönster (ex SOA) utan på andra stora mönster som finns. En arkitekt skall känna till olika lösningar/mönster, anser jag som passar deras affärsområden och organisation. Med mönster menar jag på en högre nivå. Dvs SOA är ju ett mönster över system som mer eller mindre agilt kopplas samman via lösa gränsnitt där ett konrakt måste existera.

2) När du kallar dig enterprisearkitekt, vad menar du då att du har för ansvar och uppgifter?
- Min roll (när jag får sådana uppdrag) är att lyssna på vad kunden vill ha, känna av utvecklingsteamet, ta reda på kunskaper i huset, sedan ihop med dem ta fram en plan, ramverk, grundstomme m.m. för deras organisation, teknik, ev server arkitektur m.m. Då jag gillar Agil metodik föreslår jag även någon form av metodik de kan nytja i framtagandet av sitt system, beror på antal utvecklare de är i teamet m.m. hur de gillar att jobba etc.
XP, SCRUM eller vad som kan passa dem. Så ansvarområderna är ganska breda, där jag även tar till expertice på vissa områden jag inte är så bra på. Min roll är inte direkt en roll utan blir ju flera olika arkitekroller. Men jag brukar gruppera in det i ordet enterprise arkitetkt för det förklarar att områderna man sysslar med är brerda. (må vara fel att göra så?) men ordet arkitekt är ju rätt abstrakt. Och det finns ju tvister vad en arkitekt egentligen är.

Precis som många tror att SOA görs med Dataset och web-services och inte kan göras på annat sätt exempelvis med .Net remoting via TCP i bitstreams där man kan använda DTOer (Data transfer Objects.). Det är oftast här det faller tycker jag när man pratar SOA man visar exempelkod som andra sen tror är SOA. Fast som i själva verket är en av många implementationer. Nu kom jag lite utanför ämnet rörande frågan dock :-/

Mvh Johan

>Hej Johan. Du skriver ju litet då och då i olika sammanhang om oss och våra aktiviteter, men jag känner aldrig igen oss i det du skriver.

Jag vill nog påstå att jag inte skrev något fel i min post innan du skrev till mig i forumet.
Om du tänkte på: Luras inte in i deras träsk ;) Så var det ironi om att inte fastna i bara SOA.

Vet dock att vi vart i heta diskusioner rörande dataset, tabeldriven utveckling, varför inte DDD? etc..
Men det är ett annat ämne och redan ett avslutat kapitell. Alla tycker vi olika.

Var bara tvungen att tillägga detta. Dock har jag bara erfarenheter av sånt ni presenterat tidigare och de saker jag pratat om i diskussioner med en utvecklarer ni haft hos er samt sånt som ni publicerade på er blogg.

Mvh Johan

Hej igen Patrik,

Enligt det här meningsutbytet verkar vi vara överens om ganska mycket. Det som främst verkar skilja oss åt är vad vi ägnar huvuddelen av vår tid åt. Vi här på 2xSundblad ägnar oss helt och hållet åt SOA och connected systems medan du ägnar dig mer åt domändriven utveckling. Det finns helt klart en plats för båda, och det kommer inte att förändras om Gartner har rätt och SOA blir mer dominerande.

Ibland när vi inte verkar vara överens verkar det bero på missförstånd. Du skriver: <b>Det här är glädjande att höra dig säga, så sent som mars 2006 fick jag uppfattningen att du och Per hade åsikten att objektorienterade mönster var ett problem för en arkitektur för bussiness agility. (jag tänker på inlägget "Taking sides with clemens" som verkar försvunnit i flytten av er blogg). </b> Det jag skrev var att en SOA-ansats kräver - eller bör kräva - studium av "business processes, business information, and business rules", och att "chances are, in such a state-less, loosely coupled, and business-driven environment, that domain-driven design of the components that make up a service is not nearly as relevant as it is when architecting an application silo. " Det tror jag fortfarande på, även om jag absolut inte diskvalificerar domändriven design av koden i en entity service.

Det som är mest intressant (för mig) med ditt inlägg är din erfarenhet att <b>många som praktiserar SOA oftast faller in i vattenfallsmodeller och många SOA evangelister anser att den logiska följden av SOA är att vi får återgå till "top-down" och "big up front design". </b> Där är jag helt överens med dig, både om att många SOA-evangelister predikar så och om att det är väldigt olyckligt att det är så. Det finns absolut inget samband mellan SOA och Big Up Front Design eller Grand Master Plan. Tvärtom är det så att försök med Big Up Front Design eller Grand Master Plan nästan säkert dödar en SOA-ansats. Vårt budskap är helt annorlunda.

Vi menar att en SOA-ansats dock måste vara företagsomspännande, och att det måste finnas en vision av hur den i stora drag skall se ut i en avlägsen framtid. Denna vision vägleder SOA-satsningen, men tillväxten av den måste vara organisk. Den måste styras av krav och behov från vanliga människor i vanliga jobb, helst i små agila projekt. Och när varje tjänst växer organiskt, och över många år, då växer också hela mjukvaruportföljen organiskt. Det finns ingen som helst möjlighet att planera det i förväg.

Det här är en central del av vårt budskap, och det kommer att genomsyra hela vår planerade kursserie. Vi tänker också publicera en "gratislektion" så att var och en kan få en riktigt bra bild av hur våra kurser ser ut innan de bestämmer sig för att delta, och troligen blir det för den första kursen en lektion som heter "Architecting For Organic Growth". Jag tror du kommer att gilla den.

<b>"Enligt det här meningsutbytet verkar vi vara överens om ganska mycket. Det som främst verkar skilja oss åt är vad vi ägnar huvuddelen av vår tid åt."</b>
Skrämmande tanke ;)

I stort håller jag med i vad du säger, men:

<b>"Det tror jag fortfarande på, även om jag absolut inte diskvalificerar domändriven design av koden i en entity service."</b>

Anser jag vara lite snävt. Ja Domain Model Pattern och ORM som DDD förespråkar är ett ypperligt val för implementation av en entity service. Men DDD är inte begränsat till rekommendationer om hur information skall struktureras utan förespråkar också tillvägagångssätt för implementation av kod av mer "affärsregler"-karaktär, kod som mycket väl skulle kunna vara insidan på båda utility services och task services om man väljer att koda dem och inte använda någon form av BPM verktyg eller någon annan högre abstraktion.

Den viktigaste poängen i DDD / SOA diskussionen att ta med sig anser jag vara det sista D'et i DDD som står för Design. Vi pratar inte om DDA utan DDD vilket i väldigt stor utsträckning handlar om implementation, insidan, medans SOA bör i lika stor utsträckning definera utsidan.

<b>"Vi tänker också publicera en "gratislektion" så att var och en kan få en riktigt bra bild av hur våra kurser ser ut innan de bestämmer sig för att delta, och troligen blir det för den första kursen en lektion som heter "Architecting For Organic Growth". </b>

Jag håller utkik och mailar feedback när jag sett den.

<b>Den viktigaste poängen i DDD / SOA diskussionen att ta med sig anser jag vara det sista D'et i DDD som står för Design. Vi pratar inte om DDA utan DDD vilket i väldigt stor utsträckning handlar om implementation, insidan, medans SOA bör i lika stor utsträckning definera utsidan.</b>

Tänk om alla förstod det!

<b>Men DDD är inte begränsat till rekommendationer om hur information skall struktureras utan förespråkar också tillvägagångssätt för implementation av kod av mer "affärsregler"-karaktär, kod som mycket väl skulle kunna vara insidan på båda utility services och task services om man väljer att koda dem och inte använda någon form av BPM verktyg eller någon annan högre abstraktion.</b>

Jag vet! Det är därför jag "absolut inte diskvalificerar domändriven design av koden i en entity service".;-)

En sak som jag funderat lite över är hur SOA som det struktureras idag med mycket fokus på arkitekternas roller m.m. skulle fungera i en Agile metodik så som SCRUM. Där man egentligen inte har någon arkitekt. Alla i teamet är typ systemdesigners ihop.

Man har SCRUM mastern, (typ lite som en projektledare fast ändå inte), man har team members de som bygger systemet sen har man Product Owner. Man kan ju utse en arkitekt om de olika team members tycker det är ok eller ej. Men saken med SCRUM är att alla är med och tar fram systemet iterativt i korta iterationer med ex TDD (Test Driven Development). SOA tjänster kan ju skapar med TDD då det faktiskt går utifrån in. Men Arkitekternas roller försvinner lite här. Alla på Dotway skall certifieras till SCRUM masters nu där vår approach blir mer o mer att förmedla en Agile metodik.

Det jag känner rörande SOA är att det är mer en vattenfallsprocess dvs. mer al’a RUP.

Agila metodiker speciellt SCRUM växer mer och mer nu och många stora företag kör nästan enbart SCRUM i dag. Dock de mer Java-orienterade bolagen, men många .Net orienterade företag har visat stor nyfikenhet till detta. TDD och Enhetstestning allmänt, även domän driven utveckling ökar kraftigt vilket vi på Dotway märkt av. SOA är ett intresseområde också, men på en implementationsbasis då de inte riktigt vet hur de skall implementera sina tjänstemoduler m.m på rätt sätt. Här ser jag en stor svaghet och det är här SOA folk tyvärr lägger ner minst tid på att förklara hur de skall göra. Kommentarer man fått är typ kontrakten är viktiga modulerna är viktiga vi har dem men sen då?

Vi får oftast frågor om detta dagligen, här skulle jag vilja se ett ökat intresse. Hur vi än vrider på det så är vi idag mer Agila utvecklare där vi har många roller i en och samma person.

Mvh Johan

Hej Johan,

Du har så rätt när du säger att det finns en stor osäkerhet när det gäller SOA, hur SOA skall fungera ihop med agil utveckling, och hur SOA-baserade tjänster skall implementeras. Ännu viktigare, som vi ser det, är att det finns osäkerhet om vad SOA egentligen är och hur man skall se på SOA i ett mera övergripande perspektiv.

Det är här vi tror att vi med våra onlinekurser skall kunna göra stor nytta. Inte minst onlineformatet kan bli till stor hjälp, för det är minst lika svårt att ta till sig vad SOA är som det för tjugotalet år sedan var att ta till sig vad objektorientering var och är. En onlinekurs kan man titta på i lugn och ro, se på bilder och bildspel, lyssna på förklaringar och budskap (videoformat), och ta om sådant som är svårt hur många gånger som helst.

Vad vi gör glasklart tydligt i våra kurser är att SOA inte är ett sätt att strukturera koden i ett projekt. SOA är strategiskt och företagsövergripande. Det många inte riktigt förstått är att man därför bör inleda en SOA-satsning med att ta fram en vision för en framtida SOA-miljö. Visionen är övergripande och saknar helt och hållet detaljinformation. Den utgör alltså <b>inte </b> en Grand Master Plan eller en Big Up Font Design. Den fungerar bara som en vägvisare till vägledning för enterprise-arkitekten, business-arkitekten, och software-arkitekten. (Jag använder mig med flit av svengelska här för tydlighetens skull. Det är lättare att få engelskspråkiga än svenskspråkiga definitioner av dessa termer.)

När det gäller din kommentar om SOA, vattenfallsprocesser, och RUP vill jag hänvisa till mitt svar till Patrik 2008-01-22 10:58:10 i denna tråd.

Du säger också om SCRUM att man <b>där egentligen inte har någon arkitekt. Alla i teamet är typ systemdesigners ihop.</b> Det är det som gör att SOA och metoder som SCRUM passar så bra ihop. Arkitekten/arkitekterna har redan gjort sitt arbete när SCRUM-projektet startar. Verksamhetsarkitekten (business architect) har analyserat verksamheten och kommit med förslag till förbättringar. Bland dessa förslag finns idéer om förbättrat IT-stöd, som verksamhetsarkitekten utarbetat tillsammans med mjukvaruarkitekten (software architect). Mjukvaruarkitekten har definierat tydliga och detaljerade kontrakt och kopplat dessa kontrakt till tjänster.

Allt detta är redan gjort när SCRUM-projektet startas. Arkitekturen finns redan och utgör en restriktion på SCRUM-projektet. SCRUM-projektets designers har, precis som du säger, till uppgift att finna ut det bästa sättet att implementera given arkitektur.

Det sköna i det här är att SCRUM-projekten kan arbeta väldigt fokuserat. Säg att ett projekt handlar om att utveckla respektive vidareutveckla fem användarapplikationer, tio process- och användningsfallstjänster, och fem entitetstjänster. Man kan då sätta upp ett SCRUM-projekt för att utveckla användarapplikationerna och se till att projektets medlemmar är bra på användargränssnitt och användarinteraktion. Man kan sätta upp två SCRUM-projekt för process- och användningsfallstänsterna och se till att projektmedlemmarna är bra på arbetsflöden och operativa verksamhetsregler. Slutligen kan man sätta upp ett SCRUM-projekt för entitetstjänsterna och se till att man har med folk som är bra på databasdesign, databasaccess, och strukturella verksamhetsregler. Det är också här man kan ha mest nytta av en DDD-ansats, även om jag vill betona att det inte alltid är den självklart mest lämpliga utformningen av en entitetstjänst.

En sådan organisation leder till att du har korta, begränsade projekt som snabbt kan ta fram en fungerande version av det som behövs. De arbetar under begränsning av en arkitektur som säkerställer att projektresultatet inte bara löser de omedelbara problemen utan också blir en bit i enterprise-arkitektens pussel och därmed undviker onödiga och dyrbara framtida integrationsproblem. Allt detta leder till goda chanser till hög kvalitet, något som förstärks av att varje applikation/tjänst tas fram av specialister på just den typen av applikation/tjänst. Precis de värden som metoder som SCRUM syftar till, skulle jag vilja säga.

Arkitekten då? Arkitekten är ansvarig för den övergripande strukturen och för kontrakten, men skall i princip inte lägga sig i implementationen. Hon är därför, som du också påpekar, i stort sett frånvarande. Men inte helt! Hur bra jobb arkitekten än har gjort måste man räkna med att något kontrakt här och där måste ändras. Då måste arkitekten finnas till hands för förhandlingar om justeringar. Det man måste förstå är att varje kontrakt används i mer än ett projekt, så ingen kan på egen hand bara ändra i dem. Det är det som är poängen med kontrakt. Men om det behövs måste man ha en procedur för att göra det, och då måste arkitekten vara närvarande.

Du säger avslutningsvis att <b>vi idag är mer agila utvecklare där vi har många roller i en och samma person</b>. Jag håller helt med och vill gärna använda arkitekten som exempel. Enligt vår erfarenhet, inte minst från våra arkitektutbildningar, är det mycket vanligt att en och samma person spelar både arkitektens och ingenjörens roll. Man kan alltså tänka sig en Johan som först är mjukvaruarkitekt och förhandlar med verksamhetsarkitekten och med verksamhetsfolk för att få fram en övergripande struktur och ett antal kontrakt. När SCRUM-projekten startar tar Johan på sig ingenjörsmössan och deltar som ingenjör i ett eller flera av de aktuella projekten för att utforma implementationsstrukturer.

Så händer något som gör att ett kontrakt kanske måste ändras. Då inleder ingenjören Johan förhandlingar med arkitekten Johan, som i sin tur bjuder in andra berörda ingenjörer från de andra SCRUM-projekten, och kanske verksamhetsarkitekten och verksamhetsfolk, till förhandlingar. Detta leder eventuellt – men bara eventuellt – till kontraktsförändringar. Då tar Johan åter på sig ingenjörsmössan och fortsätter att scrumma.

Jag är ledsen att svaret blev så långt, men det gick inte att svara kortare på de frågor du tar upp. Svaret är också bara en bråkdel av innehållet i våra 10 planerade kurser, varav fem handlar om arkitektur och fem om implementering av arkitektur.

Just de frågor du tar upp är centrala, och när jag läser dem (och besvarar dem) blir jag glad över att vår första kurs som släpps om en eller två veckor är en övergripande kurs. Jag blir mer och mer övertygad om att en sådan behövs extra mycket, eftersom den vänder sig till så många kategorier och kan bli en bra plattform för fortsatta studier och egna experiment.

Hej Sten,

Intressant. Tror absolut er nya kurssatsning kommer höja dessa förståelser och de ev missförstånd som finns här ute.

Du säger okcså att arbetet redan är gjort innan SCRUM-processen sätts igång. Jag är inte helt med här även om jag förstår din text.
I vårt fall när vi tog fram en tjänste orienterad applikation så hade vi SCRUM hela vägen. Alla var med och tog fram kontrakten ihop med stakeholders m.m. Tycker det gick bra, men då faller återigen SOA arkitektens roll då ingen sådan fanns här. Alla satt vi exempelvis med Team System och vi var alla lika involverade i de scheman och modeller som togs fram. Jag tror det är samma här som med allt annat det finns ingen <b>silver bullet</b> och heller inger bra svar på detta heller. Utan det är mer smak och tycke. Hur en organisation vill jobba m.m.

Jag var delaktig i IASA gbg förra året, och det är inte lätt detta rörande vad är en arkitekt och vad spelar han/hon för roll. Många som är oense här. hehe... Det är ju som politiken. :-)

mvh Johan