[fria24] Vilken teknik bör användas ?

[Anders Wallenquist]

Vad är huvudmålet? Föreslår:

1) Hitta pilotkund, göra ett första projekt som skall vara spektakulärt,
men litet och snabbt. Skaffa press och uppmärksamhet kring detta och
använda detta som brofäste till fler myndigheter/kommuner/landsting.
Tror en kommun vore lagom liten och lättare att peka på hur de sparar
pengar på fri programvara?

2) Eliminera de tekniska hinder som finns för att använda fri
programvara i offentlig miljö.

Jag tror att både 1) och 2) är viktigt, men att 1) är smartast att börja
med och 2) innebär den verkligt bästa nyttan på sikt.


Dario Lopez-Kästen wrote:

>
> Disclaimer:
>
> * jag är zope-utvecklare, jag gillar python skarpt, och jag får lön
> för att utveckla saker i Zope/Python.

Vad trevligt, var fanns du när jag letade efter dig med ljus och lykta ;-)

>
> * jag respekterar men föredrar inte PHP, överhuvudtaget, jag gillar
> inte sid-centrerade utvecklingsmodeller och jag ser inte att denna
> sorts utveckling kan var hållbar för framtiden - tvärtom ser jag att
> all utveckling av större och omfattande www-system, allt mer rör sig
> mot gammal, hederlig applikations utvekcling - AJAX och liknande
> teknologier är ett tecken på detta.

Drupal kan du jämföra med Zope, PHP får du jämföra med Python.

PHP och Python är lika mycket programmeringsspråk båda två, med samma
utvecklingsmodell och behöver inte jämföras med Java Server Pages eller
ASP om man inte vill.

>
> * Jag vill framför allt inte starta ett old-styöe plattformskrig, men
> jag vill bemöta litet av den FUD mot Zope/python som jag upplever
> finns i detta brev.
>
> * Jag vill helst att man utvekclar ngt som är plattformsagnostiskt -
> där man har protokoll som skall följas och inte låser sig i lo-fi
> teknikval, och att de system och delsystem man bygger skall kunna
> prata med varandra.

Det är en utgångspunkt där du har mitt fulla stöd, var benhård på öppna
standars och titta på API-erna i ett strategiskt perspektiv.

>> Vartenda webbhotell erbjuder LAMP, men det är tunnsått med Zope och
>> JBoss. En stor myndighet med gott om pengar har inga problem att införa
>> Zope och säkert göra fantastiska saker med Zope, men den lilla kommunen
>> har inte en chans. Det är inte helt självklart att JBoss eller Zope
>> vinner en TCO-jämförelse med t ex DotNet - kanske mot J2EE på Sun, men
>> DotNet på billig Intel-plattform kan vara tufft. SugarCRM som är LAMP
>> finns redan på programverket.org, P som i PHP.
>>
>> Har erfarenhet av kommuner och offentliga system, både stora och små.
>> Min rekommendation är att välja en plattform som även kan fungera hos de
>> mindre, men skalbar för lite tuffare sammanhang.
>>  
>>
>
> eh... jag ingår i ett team som driftar typ STORA Zope system (med
> personaliserade sidor för typ 100-200 samtidiga användare) och jag
> känner inte igen mig i vad du beskriver, alls. Zope är billigt att
> driftsätta i jämfört med många andra system, det handlar bara om att
> göra rätt saker och det r inte så svårt att göra rätt saker.

Exakt, Zope är en utmärkt kandidat som kommer till sin rätt i STORA
system, precis min poäng. Min poäng är också att du installerar inte ett
Zope-system på en förmiddag på Levonline från scratch.

> Man får ju jämföra på rätt sätt också. En anledning till att inte så
> många erbjuder JBoss och Zope är att de inte är "enkla", om man kan
> kalla dem så, CGI-aktiga system, utan de har egna request brokers,
> persistens-maskinerier, osv. Det handlar alltså inte om bara "parsa
> denna sidan" utan det handlar om kompletta system. Båda dessa klara
> sig utan en apache i frontend.

En applikationsserver i klass med Drupal är inte heller ett enkelt
CGI-aktigt system som bara handlar om att "parsa denna sidan" utan är
ett komplett system för SOA, Webservices, E-handel, CRM, CMS,
Bokningssystem, Publicering etc.

Jag är mer imponerad av de system i samma klass baserade på Zope än de
jag träffat på baserade i JBoss. Ett bra exempel, om man tittar på
Zope-spåret är http://launchpad.net och SchoolTool-systemet som också
utvecklas av Canonical. Bra kompetenta system på många vis, men de är
inte lätthanterliga.

Jag har varit inblandad i upphandlingar som exempelvis Kungsbacka,
Boden, Österåker, Vaxholms, Linköping, PPM, Posten, Motala-kommun gjort
för sina embryon till 24-timmars system. Bortsett från PPM och Posten så
är det SMÅ, nyckelfärdiga system som efterfrågas.

SKL behöver CRM, de tar in SugarCMS och gör en anpassning i den - det är
den nivån på arbete och projektomfattning man bör inse att man måste
klara. Det är den miljön man konkurrerar i.

Den upphandlande myndigheten kommer att anse att DotNet, MS-SQL (eller i
vissa fall Oracle) och W2K servrar (kanske W2003 i nya upphandlingar) är
befintligt. Behöver man köpa in något annat så tillkommer detta ovanpå i
totalkostnaden de utvärderar.

Jag är anhängare av KISS, keep it simple stupid. Min tolkning av KISS är
att ta något färdigt från hyllan, gör möjligtvis någon kundanpassning,
men släpp den modulen fri så att fler kan hjälpa till med underhållet.

> Enda gången det blir komplicerat med Zope är när man skall modellera
> HA-lösningar efter LAMP-princpen - detta behövs inte alls, och
> fungerar ofta dåligt med Zope, då blir det dyrt.
>
> Det zope-kräver är mycket minne i maskinerna, men den kräver inte
> superhårdvara, och den kräver CPU-affinity på multicpu hårvara - det
> är de enda speciella grejerna som jag könner till om zope.

HA-lösning vad är det?

> Zope går alldels utmärkt att blanda med PHP och java, och om man går
> SOA vägen så borde det inte vara några problem vad man bygger det i.

Mina synpunkter att LAMP fungerar för att utveckla serverfunktioner var
främst riktat mot påståendet att PHP inte var lämpligt för detta som
finns på webbplatsen. Om inte Zope ginge att integrera med främmande
system så skulle plattformen inte vara värd att diskutera.

> Inget ont om Drupal, jag har rekommenderat det själv till ett ställe,
> men jag är tveksam till att bygga infrastruktur i PHP; i ett sådant
> fall skulle jag rekommendera Perl, eller *brr* Java (som jag inte
> heller gillar ;-).

Java borde vara IMHO uteslutet om målsättningen är en i alla meningar
fri plattform.

Traditionell utvecklingsmetodik innebär att man väljer plattform;
klassbibliotek och utvecklingsmiljö och sätter igång att utveckla
systemet från scratch. Kompetenta klassbibliotek och ramverk har gjort
att vi kan rationalisera utvecklingsprocessen och minska våra kostnader.

Jag vill mena att detta är hur man gjorde igår. Det är få organisationer
som har lyxen att göra efter den gamla regelboken. Det handlar alltså
inte om att välja mellan PHP, Python eller Perl utan något som ligger
betydligt närmare en nyckelfärdig lösning.

Systemutveckling idag handlar om att vara systemintegratör som arbetar
med färdiga system och applikationer - att jämföra med gamla tidens
systemutveckling där systemutvecklaren arbetade med ett smörgåsbord av
klasser.

Affärssystemsleverantörerna har arbetat på detta vis en tid och
utvecklat ett eget litet universum av färdiga lösningar som de
återanvänder på sina kunder inom samma bransch eller funktionsbehov.

Fri programvara är ett smörgåsbord av färdiga applikationer, vi har vårt
universum av system som potentiellt kan fungera som pusselbitar som
självklart skall användas maximalt. Därför bör utgångspunkten vara att
standardisera API-er och gränssnitt för att kunna göra effektiva
integrationer. Utvärdera lösning A som ställs mot lösning B, fundera på
hur Single-sign-on eller i alla fall autenticering kan vara gemensam
mellan applikation A och applikation Z.

Fri 24 kommer rimligtvis ha ett gränssnitt mot medborgaren och ett
gränssnitt mot organisationen och befintliga system. Ett rimligt
antagande är att webb kan vara ett bra gränssnitt i många fall mot
medborgaren (80/20?) och SOA/Webservices kan vara ett i alla fall
politiskt korrekt gränssnitt in mot befintliga system.  I praktiken
kommer mycket av anpassningarna handla om kundanpassning mot befintliga
system, många är av äldre datum, många är gjorda för helt andra typer av
teknologier. Autenticering och finmaskiga rättighetssystem kommer vara
en viktig komponent.

Mitt förslag att utgå från Drupal, inom ramen för Drupal hitta några
tillämpningar med god impact att visa upp för omvärlden, arbeta in
genomtänkta integrationsmöjligheter mot befintliga system och ett
vackert yttre i Content delen, baseras på att snabbt kunna hitta något
som är demonstrerbart, identifiera en intresserad pilotkund att
samarbeta med, minimalt med utvecklingstid, maximalt fokus på kundnyttan
och bygga brofäste.

Om det är ärendehantering, bokning, informationsinhämtning och spridning
på plankontoret eller skoladministration kanske är underordnat. Det
kanske till och med är pilotkundcaset som får styra detta?

Avgörande faktorer kan kanske vara att kunna erbjuda ett gränssnitt mot
SHS, spridnings och hämtningssystemet, som används av många myndigheter?
En sådan modul/server kanske pratar SHS i ena änden och Webservices mot
våra fria applikationer? En generell server-funktion som gör det möjligt
att välja bland en mängd fria färdiga applikationer som bara behöver
fräschas upp på Webservices-fronten? Är SHS viktigaste hindret för fri
programvara inom offentlig sektor?

För att ha maximal nytta med fri programvara skall man tillåta sig att
utvärdera befintliga färdiga lösningar och välja bästa kandidaten varje
gång. Kvar blir öppna standarder och gränssnitten för integration mellan
applikationerna som det sammanhållande.

Givetvis tycker jag man skall utvärdera SchoolTool om pilotcaset handlar
om skoladministration. Men Drupal innehåller en mängd generiska
funktioner och tillämpningar som ökar sannorlikheten att det finns något
att hämta där i samband med  en potentiell dialog med en pilot.

Finns det någon pilotkund? (Vi har några ramavtal man kanske kan använda
som ingångar PPM, Österåker, Waxholm?)

Kan Mats Östling, SKL, vara en bra kontakt för att finna a) pilotkund b)
viktigaste "säljargument"/hinder eliminering?


/Anders W