En hårdt tiltrængt oprydning i Dynamicweb CMS – og hvad det betyder for kunderne

Dynamicweb 8 – som er den kommende opdatering af Dynamicweb CMS – indeholder en temmelig stor ændring. For langt de fleste kunder vil der være tale om en fuldstændig usynlig ændring, og forhåbentlig vil der ikke være mange, der vil mærke til ændringen. I hvert fald ikke i første omgang. Men de større kunder – som har megen specialudvikling – vil komme til at mærke til ændringen.
Der er tale om en såkaldt API Refactoring – eller på jysk: “Oprydning!”. Dynamicweb CMS er et af de ældste CMS-platforme, og rent arkitektonisk er det langt hen ad vejen den samme platform, som den, der blev lavet i 2001. I en lang periode var den vigtigste prioritet for Dynamicweb Software at tilføje ny standardfunktionalitet, som kunne sælges til kunderne. I den proces blev der tilføjet en masse ny kode – og det er langt hen af vejen det, som man forsøger at få ryddet op i nu.

 

Hurtigere udvikling

Det er bestemt en god ting. Hvis man har prøvet at lave specialudviklet funktionalitet til Dynamicweb CMS, så ved man, hvad jeg taler om. Det sværeste ved at lave moduler til Dynamicweb CMS er ikke selve programmeringen i sig selv – men at man helst skal have en del erfaring med at arbejde med Dynamicweb CMS. Simpelthen fordi der er så mange faldgruber i form af ikke-dokumenterede metoder, metoder, der ikke virker længere og metoder, der er godt gemt af vejen. Ofte ender man derfor med at lave rigtig mange ting selv.
Det er i modsætning til en platform som eksempelvis Umbraco, som er kendetegnet ved at være en simpel platform, som genanvender rigtig mange metoder fra Microsofts .net.
Konsekvensen af dette er, at selv om Dynamicweb CMS er et meget udbredt system, så er det faktisk svært at finde rigtigt dygtige udviklere til platformen. Og det er svært at oplære nye udviklere til Dynamicweb CMS fordi der er så mange spidsfindigheder, som man også skal lære. Derfor vil omkostningerne til at lave specialudvikling på en Umbraco – alt andet lige – som regel være lavere, end de tilsvarende på Dynamicweb CMS.
Som slutbruger/kunde på Dynamicweb CMS skal man derfor se denne oprydning som en rigtig god ting. Der bliver ryddet op, så fremtidig specialudvikling bliver nemmere, hurtigere og billigere at udføre. Men man skal også se det som en god ting i forhold til kvalitet og stabilitet. Jo færre linjer kode, der skal vedligeholdes, desto mindre risiko er der også i forbindelse med eksempelvis opgraderinger til platformen.

 

Men!

Som kunde/bruger skal man dog ikke forvente den store effekt lige med det samme. Partnerne og udviklerne på platformen skal først lære de nye metoder at kende, og det kan derfor let tage både halve og hele år inden oprydningen får en effekt ude hos kunderne. I den forbindelse kan Dynamicweb Software naturligvis lette processen en hel del igennem intensiv uddannelse – både offline og online. Ligesom partnerne naturligvis også har en stærk interesse i at uddanne deres medarbejdere hurtigst muligt.
Men den største forhindring for at denne oprydning får en positiv modtagelse hos kunderne, er den første vanskelige opgradering fra Dynamicweb 7 til Dynamicweb 8. En konsekvens af oprydningen er, at der er en række metoder og funktioner, som ikke benyttes længere, og der er metoder, som flyttes. Forhåbentlig betyder det, at der blot skal foretages nogle få hurtige ændringer til eksisterende websites, men der kan være risiko for, at der skal laves væsentligt mere end det.
I den forbindelse har Dynamicweb Software lanceret en CTP-version af Dynamicweb 8. Det vil sige en “Community Technology Preview”, som partnerne kan tilgå og afprøve specialudviklet kode på. Dynamicweb Software lancerer også en funktion, der kan checke om specialudviklet kode vil give problemer eller ej.
Det vil sige, at uanset hvordan man vender og drejer det, så vil opgraderingen til Dynamicweb 8 medføre et behov for at foretage en struktureret opdatering, som – hvis man har specialudviklet funktionalitet – bør foretages på en testserver. Man bør sætte tid af til at få vurderet den specialudviklede funktionalitet ordentligt, og man bør betragte denne ændring som om, at der er blevet tilføjet ny funktionalitet – dvs. der skal foretages en omfattende test. Denne test bliver naturligvis større, hvis der er megen specialudviklet funktionalitet.
Og så bør man – som jeg altid plejer at anbefale de større Dynamicweb-kunder – vente med at foretage opgraderingen til der er gået lidt tid. Helst minimum tre måneder. På den måde sikrer man sig, at de fejl – som altid vil være der i starten af en opgraderingscyklus – er blevet luget ud.

 

Konklusion

Konklusionen på dette er, at det bestemt er en god ting, at Dynamicweb Software rydder op i det gamle skidt. Det er faktisk ganske perfekt, og jeg håber, at fokus vil ligge på endnu mere af den slags fremover. Men det er helt afgørende, at der tilbydes så megen hjælp til partnerne som muligt, og i den forbindelse bør man sørge for, at hele organisationen i Dynamicweb Software forstår, hvad de er ved at kaste sig ud i. Den nye platform skal dokumenteres – partnerne skal undervises – og supportorganisationen hos Dynamicweb Software skal være 100% klar til at hjælpe partnerne proaktivt. Hvis man forstår det – så gør man det nemt for partnerne og så giver man i sidste ende kunden en god oplevelse. Hvis man ikke gør det, så risikerer man derimod en proces, som er fyldt med dårlige oplevelser.

 

Mere materiale

Hvis du ønsker at læse mere, så kan du gøre det her:
Advertisements

One thought on “En hårdt tiltrængt oprydning i Dynamicweb CMS – og hvad det betyder for kunderne

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s