
Noget, der kendetegner mange af de projekter, vi udfører for vores kunder, er, at de starter fra et eksisterende projekt, der er gået skævt. At projektet er gået skævt kan skyldes misforståelser mellem den tidligere leverandør og kunden om, hvordan projektet skulle være, uhensigtsmæssig eller dårlig teknisk implementering eller bare dårlige rutiner. Om problemerne skyldes det ene eller det andet kan være svært at gennemskue uden en nærmere analyse, men med nedenstående 10-punkts-gennemgang er det måske nemmere at få overblik over, hvor eventuelle problemer kan ligge.
1. Ansvarsfordeling og proces
Første checkpunkt er ikke af teknisk karaktér - det handler om roller og ansvar for de forskellige dele af projektet og om, hvordan man samarbejder. Punktet kan relativt nemt afklares ved at identificere, hvordan forskellige typer af opgaver håndteres: Er det defineret hvem, der har ansvar for hvad, hvem der er kontaktperson for hvilke områder, hvem der kan afløse hvem, hvad er aftalt responstid, hvordan kvalificeres et krav som opfyldt og så videre. Er alle disse organisatoriske aspekter afdækket og dokumenteret, så det er klart for alle, hvordan nye features og eventuelle fejl håndteres på den nemmest mulige måde?
2. Miljøer, kildekodekontrol og backups
For at håndtere et stort system skal der som minimum være opsat et testmiljø, hvor nye features og rettelser kan testes og godkendes, inden de idriftsættes. Større systemer bør også have et stagingmiljø (en kopi af produktionsmiljøet med replikerede data). Udover dette bør der være fuld mulighed for at kunne gå tilbage i tiden (versionsstyring), således at hvis der sker uforudsete ting, kan man altid gå tilbage til tidligere versioner. Der bør også udarbejdes en backupprocedure, sådan at tidligere data altid kan findes frem, hvis der skulle opstå en uforudset fejl, eller hvis systemet bliver kompromitteret. Man bør tage en stikprøvetest af udrulning af backup for at sikre, at den er intakt, og at det i praksis kan lade sig gøre at rulle tilbage, hvis det skulle blive nødvendigt.
3. Fejlhåndtering og monitorering
Selv det mest gennemprøvede og gennemtestede system kan have fejl. Det, der adskiller et godt og et rigtig godt system fra hinanden, er blandt andet, hvordan fejl håndteres, når de opstår. Det første, der skal ske ved en fejl, er at brugeren skal have en forklaring (f.eks. ’Systemet er midlertidigt nede. Forsøg venligst igen om fem minutter’), og samtidig skal administrator have en e-mail /SMS-notifikation om den opståede fejl med detaljeret information, for at baggrunden kan undersøges nærmere og fejlen kan udbedres med det samme. Fejlhåndtering kan typisk pakkes ind af Microsoft Enterprise Library, som er et af de gængse standardframeworks til det formål. Du bør altså sikre, at dit system har en veldokumenteret model for fejlhåndtering og monitorering, hvis du ikke allerede har det?
4. Sporbarhed
Et uheld kan ske, men hvis man ikke ved, hvordan det er opstået, kan det være svært at udbedre og vil derfor med overvejende sandsynlighed gentage sig. Ved at fokusere på at udvikle sporbare systemer undgår man, at problemer gentager sig. Det betyder først og fremmest, at der skal være log på alle steder, hvor der kan opstå fejl (f.eks. e-mailafsendelse, IIS pool, og så videre). På den måde kan man undersøge i stedet for at gætte. En anden metode til at øge sporbarheden er at sørge for, at de rigtige notifikationssystemer er sat op. Sker der en fejl i produktionen, er det vigtigt, at den bliver opdaget hurtigt som en del af fejlhåndteringen (se næste punkt).
På den organisatoriske side bør man have sporbarhed under deployments og så videre ved at ændringer dokumenteres og registreres (med dato, tid, person), sådan at hvis der sker en fejl, kan der sættes et navn på.
5. Transaktionsstyring
Transaktionsstyring sikrer, at selv hvis noget går galt, så går det ikke rigtig galt. Banksystemer er et godt eksempel på systemer, der er pakket ind i transaktioner. Går en handling galt (f.eks. udbetaling af penge), skal pengene ikke trækkes fra kontoen. Alle systemer har interne afhængigheder, og går noget galt, bør man afbryde forløbet og rulle tilbage, sådan at en systemfejl ikke får utilsigtede fejl, der kan være svære at forklare og håndtere. Som systemansvarlig bør man sikre sig, at alle centrale funktionsområder er dækket af en korrekt transaktionslogik, sådan at eventuelle fejl ikke forårsager andre utilsigtede og relaterede fejl.
6. Dokumentation
En grundig dokumentation sikrer at programmører, systemansvarlige og andre kan komme og gå, uden at der opstår store problemer. Dokumentation sikrer desuden, at vigtig viden ikke går tabt (bliver glemt) undervejs, men også at procedurer (f.eks. angående release og deployment) overholdes, og at der ikke sker menneskelige fejl på grund af et for lavt informationsniveau. Dokumentation er en disciplin for sig og bør ikke undervurderes, hvis man vil have sikkerhed for sit system og uafhængighed for leverandøren.
7. Læring
Alle kan lave fejl, men hvis man ikke lærer af sine fejl, begås de igen og igen. Derfor er gentagne, retrospektive analyser af forløb meget væsentlige at tage fat på. Sker der uhensigtsmæssigheder, bør de diskuteres, og der bør udarbejdes et løsningsforslag, som gennemføres, hvorefter dette igen evalueres og om muligt forbedres. Ved at have en organisation, der hele tiden lærer, kan man også hele tiden forbedre produktkvaliteten og sikre bedre kvalitet i udviklingen.
8. Brug af standard systemer
Kan noget købes, er det ofte billigere end at bygge det selv. Problemer opstår ofte ved, at hjemmelavede funktioner overtager områder, som etablerede CMS-, økonomi-, mass mail,- og CRM-systemer kunne have håndteret bedre. Hvis der findes standarder på markedet indenfor et bestemt område af dit system, kan det ofte være en fordel at integrere til standardsystemet i stedet for at genopfinde den dybe tallerken. For at afklare dette kan man spørge, om der er noget i ens system, der med fordel kunne erstattes af et standardiseret system?
9. Best practice
Alle større opgaver består af en række delopgaver, der findes gode og dårlige løsninger på. Inden for de fleste implementeringsopgaver findes, hvad man kalder ’best practice’-metoder og procedurer. Hvis man følger disse kendte mønstre gennem hele projektet, minimeres risikoen for fejl, da der anvendes kendte og gennemprøvede modeller, hvor de fleste overraskelser er fjernet. Er dit projekt ikke bygget på best practice bør det ses igennem, og eventuelle ’Georg Gearløs’ løsninger bør erstattes af best practice inden for området.
10. Test
Lad ikke brugerne være testere uden at de er klar over det. Gode test starter med gode, interne procedurer tæt på udviklingen - eksempelvis browser,- og devicekompatibilitetstests. Systemer bør også være dækket ind af både automatiserede tests (unit test, valideringstest, stresstest, og så videre), og ved stabilisering bør regressionstest baseret på realistiske brugsscenarier anvendes. Kun når alt dette forarbejde er på plads, bør rigtige brugere inddrages – og naturligvis under kontrollerede omstændigheder.
Kan du svare ’ja’ til ovenstående 10 punkter, er der langt bedre chancer for, at dit IT-projekt lykkes. Når man er på forkant og har de rigtige procedurer på plads, er der en meget bedre chance for at udvikle god IT-skik og for at undgå overraskelser og uforudset weekendarbejde. Det positive er, at det aldrig er for sent at komme i gang med at få styr på sine procedurer. Til gengæld er det et arbejde, som fortsat kan forbedres.
I samarbejde med Compent har Team Danmark udviklet en app, der er skræddersyet til at imødekomme atleternes helt særlige behov. Appen samler alle kontaktflader ét sted og gør det nemt at kommunikere, holde sig opdateret og administrere diverse aktiviteter. Med appen har Team Danmark fået en one-stop-løsning, som atleterne kan tage med sig og bruge præcis, når det passer dem - både i Danmark og i udlandet.
Modeindustrien står overfor et stort problem. Mode brands anvender klodens begrænsede resourcer og overproducerer for at skabe mere forbrug og vækst. På denne måde har de et troværdighedsproblem overfor forbrugerne der kræver mere ansvarlighed. Med andre ord: Det er tid til at ændre denne model. Her kan du se præsentationen omkring cirkulær ecommerce på Umbraco codegarden 2019.
Torsdag aften blev årets bedste e-handelscases fejret i Øksnehallen til Foreningen for Dansk Internethandel (FDIH) årlige prisudeling. Compent var med Shamballa Jewels nomineret i kategorien ”Bedste e-handelscase 2019” for Shamballa Jewels Global Sales Platform. Vi er super stolte af at kunne gå hjem med 1. pladsen i et skarpt felt af gode ehandelscases.
Vi får indimellem forespørgsler på en on-site .NET / Umbraco konsulent der kan løse udviklingsopgaver on site. Modellen med on-site konsulenter er formodentligt det rigtige hvis man har en konkret udfordring med sin Navision eller SAP opsætning, men anvendelsen af kort tids on-site konsulenter er en risikabel affære, hvis man har en mere langsigtet strategi og har et decideret udviklingsprojekt.
Hvert år til Umbraco Codegarden-konferencen kåres de bedste Umbracoprojekter, og der uddeles i alt 10 forskellige priser i forskellige kategorier blandt flere hundrede indsendte projekter. Compent vandt i år i kategorien ”Best New Tech” med “Shamballa Jewels In-store Jewelry Designer”.
Vi har netop opgraderet vores interne baseline til Headless / .NET Core og beskriver her hovedpunkterne for, hvorfor du bør tænke en Headless arkitektur ind i dit næste Umbraco projekt. Et Headless CMS projekt betyder at der er fjernet de klassiske bindinger mellem CMS platform og præsentationslag. Det betyder i praksis at front-end er adskilt fysisk fra back-end, og man kan derfor udvikle sit præsentationslag uafhængigt af CMS platformens version.
Der udvikles mange Intranet på Umbraco - men der har længe ikke fandtes nogen standard platform man kan bruge fra our.umbraco. Med uIntra er det blevet nemmere at udvikle et Intranet på Umbraco uden at skulle starte helt fra bunden. Vi har netop lagt version 0.2.3.7 ud på our.umbraco til fri download. Blandt de nye funktioner er grupper, emoticons og kommentering på artikler samt en masse mindre opdateringer.
Umbraco forbindes ofte ikke med intranetbrug, hvor funktioner som decentral administration, arbejdsgruppefunktionalitet, medlemsstyring, dokumenthåndtering og rettighedsbaseret søgning er blandt de mest centrale features. Dette betyder dog ikke at Umbraco ikke kan anvendes til intranet, bare fordi alle features ikke kommer out-of-the-box i Umbraco.