Her er vinderne af københavnsk Drupal-udbud til 50 millioner

Fem udviklingshuse og en række underleverandører er blevet optaget i ny rammeaftale om stort Drupal-udbud fra Københavns Kommune og kan se frem til at skulle dele op mod 50 millioner kroner.

De store smil var fremme hos en række danske Drupalhuse, da det fredag blev offentliggjort, hvem vinderne af en ny rammeaftale til en værdi på op mod 50 millioner kroner.

»Vi har arbejdet i meget lang tid med rammeudbudet for Københavns Kommune, så vi er glade for at være med,« siger direktør i Peytz og Co. Christian Peytz til Version2.

Læs også: Københavns Kommune satser 50 millioner på Drupal-platform

Peytz og Co. er sammen med underleverandørerne DIS/Play og Reload en af de fem vindere af rammeaftalen. Men hvor meget aftalen kommer til at kaste af sig i kroner og øre er endnu for tidligt at sige, da kommunen først nu skal til at sætte de enkelte delopgaver i miniudbud blandt de valgte leverandører.

»Vi ved endnu ikke, hvad og hvor meget vi skal lave. Men kommunen har meldt ret åbent ud, at der er arbejde nok til alle de valgte,« siger Christian Peytz til Version2.

Det bekræfter administrerende direktør i Reload, Rasmus Luckow-Nielsen:

Læs også: Derfor valgte Københavns Kommune Drupal til nyt intranet

»I princippet kan vi jo ende i en situation, hvor vi slet ikke får nogen ordrer. Men hvis tidsplanen skal holde, får alle leverandører nok rimeligt travlt« siger Rasmus Luckow-Nielsen til Version2.

Begge direktører ser dog en udfordring i at få nok kompetente Drupal-udviklere, men i Drupalmiljøet er den situation ingen nyhed.

De 5 virksomheder på rammeaftalen er:

  • Peytz & Co. med underleverandørerne Reload og og DIS/Play
  • Konsortiet 'Wunderkraut, Headnet og 1508'
  • Konsortium bestående af Bysted og Propeople
  • Konsortium bestående af Advice Digital og Eksponent med Obrigado som underleverandør.
  • Visma med underleverandørene Linkfactory og Pentia

Opdateret 6. november 11.30: Københavns Kommune har bekræftet navnene på leverandørerne - Eksponent og Pentia er tilføjet som underleverandører.
Opdateret 6. november 11.45: Headnet, 1508 og Wunderkraut er sammen i et konsortium
Opdateret 6. november 20.16: Bysted og Propeople er sammen i et konsortium.
Opdateret 7. november 08.17: Advice Digital og Eksponent er sammen i et konsortium.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (11)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Simon Shine

Det er skønt at læse at et sådan samarbejde kan ske på tværs af de store udviklingshuse, og at en open source-løsning som Drupal kan fungere som teknologisk bindeled.

Men ligesom facebooks behov for at omskrive PHP's runtime til C++, kunne man spørge sig selv om Drupal er holdbart i længden.

Har I nogensinde prøvet Københavns Kommunes biblioteks hjemmeside? Den er meget pæn, men er I gale hvor er den langsom.

  • 0
  • 0
Thomas Hansen

@Simon
Langsom? Det er måske fordi det er udenfor primetime lige nu, men hvilke sider mener du? Hvis du mener søgeside og materiale visning, så skal du tage i betragtning at der sendes forespørgelsen videre til Brønden som indeholder alle de bibliografiske poster og som ikke er Drupal. Og hvis det er lånestatus siderne, så hentes det hele i bibliotekets system, som heller ikke er Drupal. Så det er begrænset hvor meget man kan udlede om Drupals performance ud fra biblioket.kk.dk.

Derudover skal det nævnes at bibliotek.kk.dk i sin nuværende form kører på Drupal 6. KK kommer til at bruge Drupal 7, hvor der har været opmærksomhed omkring performance.

  • 2
  • 0
Steen Thomassen

@Simon
Jeg er meget enig i det Thomas skriver. Min erfaring, specielt efter har haft oplevet 2 hjemmesider med PHP blev presset, da de blev omtalt nogle af de større medier, var det ikke var PHP som var flaskehalsen, men det bagvedliggende miljø som databasen o.lign. Hvis man bruger php-modulet APC (Alternative PHP Cache), så bruges der mindre tid til fortolkning af PHP - det kan mærkes. Og i selve Drupal-miljøet kan også gøres mere robust med et cache modul, så databasen kan blive aflastet.

  • 0
  • 0
Simon Shine

Ja, det er selvfølgelig urimeligt at sammenligne så stor en virksomhed med en serie af kommunale projekter. Og det er selvfølgelig også urimeligt at kritisere Drupal for at være ineffektivt når det har udviklet sig til en standard inden for web-løsninger.

Drupal er også mit foretrukne valg til websites af en bestemt størrelse, men jeg kan alligevel kun karakterisere det som et lokalt optimum. Min personlige erfaring med Drupal er at Drupal-udvikling og -vedligeholdelse foregår på en ret anderledes måde sammenlignet med almindelig software-udvikling, hvor kun det at skrive moduler kan sammenlignes (og versionsstyres), mens al konfiguration + data havner i en kryptisk suppe i databasen.

  • 0
  • 0
Mikkel Høgh

Har I nogensinde prøvet Københavns Kommunes biblioteks hjemmeside? Den er meget pæn, men er I gale hvor er den langsom.

Det er ikke (kun) Drupal's skyld – grafen her er over Københavns Bibliotekers loadtider: https://speakerdeck.com/mikl/building-real-time-systems-on-top-of-drupal...

Som du kan se har selve PHP-delen relativt pæne svartider, vores største udfordringer er 3. parts webservices (det grønne på grafen), som vi er meget afhængige af. Database-opslag fylder stort set heller ikke noget på performance-grafen.

Hermed ikke sagt at det ikke kunne være bedre, men sidens relative sløvhed har ikke så meget med at vi bruger Drupal at gøre, men i høj grad fordi vi henter og tygger store mængder data fra eksterne webservices.

(og ja, skulle nogen være i tvivl – jeg har lavet en stor del af udviklingsarbejdet på bibliotek.kk.dk og er med på Ding core team, som varetager udviklingsarbejdet. Så på ingen måde upartisk).

  • 1
  • 0
Mikkel Høgh

Min personlige erfaring med Drupal er at Drupal-udvikling og -vedligeholdelse foregår på en ret anderledes måde sammenlignet med almindelig software-udvikling, hvor kun det at skrive moduler kan sammenlignes (og versionsstyres), mens al konfiguration + data havner i en kryptisk suppe i databasen.

Sådan er det ikke nødvendigvis. På de Drupal-sites jeg arbejder på (såsom førnævnte bibliotek.kk.dk) er al konfigurationen lagt ned i den med Git versionsstyrede kildekode ved hjælp af moduler som Features og Strongarm. Selve indholdsdata ligger dog stadig i databasen, men det er ikke specielt unikt for Drupal.

  • 1
  • 0
Jesper Lund Stocholm
  • 2
  • 0
Jens Beltofte

Og i den sammenhæng burde det nævnes, at man i Drupal 8 har integreret et configuration management system, så konfiguration der tidligere lå i databasen, i stedet flyttes til filer i YAML format, så det let kan flyttes mellem forskellige versioner af systemet. Drupal 8 kommer først til næste efterår, men denne funktionalitet blev i sidste uge ifm. BADCamp comitted til Drupal 8 kernen :-) Brugte selv nogle timer i går på, at konvertere et tredjepartsmodul til Drupal 8 og til brug af configuration i stedet for den gamle variables-tabel og nogle custom tabeller.

  • 1
  • 0
Lars Nielsen

Det er rigtigt at Drupal 8 ser meget lovende ud, men set i forhold til udviklingstiden på Drupal 7's contrib-moduler, så skal vi nok ikke forvente at Drupal 8 er produktionsklar før tidligst i slutningen af 2014!?

  • 1
  • 1
Mikkel Høgh

set i forhold til udviklingstiden på Drupal 7's contrib-moduler, så skal vi nok ikke forvente at Drupal 8 er produktionsklar før tidligst i slutningen af 2014!?

Tjaeh, den største forhindring for min anvendelse af Drupal 7 da den udkom var opdateringen af Views, og da Views er en del af Drupal 8, så bliver det nok et noget mindre problem denne gang. Det er dog lidt afhængig af hvilken type site man skal bygge :)

  • 1
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize