Support en aftercare zijn zaken waarmee we van in het begin van een traject rekening houden, en die ook een impact hebben op een offerte. Het gaat hierbij om antwoorden op vragen zoals:
- Houdt het voorstel rekening met zero downtime deployment?
- Wordt de oplossing on premise of in de cloud gehost?
- Is het een bedrijfskritische applicatie of niet?
- Is er een goede oplossing voor de verwachte beschikbaarheid (7/7, 24u/24u of alleen tijdens kantooruren)?
- Zijn logging en monitoring opgenomen in het voorstel en beschikbaar voor technici (of zelfs voor gebruikers)?
- Is er gedacht aan privacy en security?
- Is er ruimte voorzien voor grondige testen?
- Is er een duidelijke en gedetailleerde technische omschrijving (infrastructuur tekening, documentatie, testen, monitoring en logging, enzovoort) voor de wiki van Digipolis?
We verwachten dat een oplossing niet alleen inhoudelijk straf is, maar ook aan devops denkt. De tijd die nodig is voor al deze zaken - en het bijbehorende budget - wordt best voorzien in de offerte.
Hoe garanderen we robuustheid voor hetgeen we opleveren?
Zoals vermeld in de IT-principes is het de bedoeling dat voor elke oplossingstraat primair gewerkt wordt met de Robuustheidstemplate. Eén van de belangrijkste betrachtingen is dat projecten/producten de robuustheidsfeatures inkantelen in hun sprintwerking of op hun backlog plaatsen om zo iteratief aan de robuustheid te werken.
Mogelijke support afspraken in Digipolis
Vanuit Digipolis bieden we drie mogelijke support afspraken aan: EAAS, DAAS en XAAS. In samenspraak met de klant kan het ook een support voorstel van de inschrijver zelf zijn. Leveranciers of Digipolis kunnen afhankelijk van de aard van het project of vastgesteld probleem verantwoordelijk zijn voor ondersteuning. Hoe meer afwijkingen op de standaarden van toepassing zijn, hoe meer externe ondersteuning nodig zal zijn. De bedoeling is dat de afspraken daarover worden vastgelegd, bijvoorbeeld in een RACI-matrix. Hieronder volgt een korte beschrijving van elk model.
EAAS (Extern a a Service)
Het grootste deel van de verantwoordelijkheden ligt bij de inschrijver. Dit is typisch het geval wanneer de oplossing niet conform onze standaarden wordt opgeleverd. Het support contract zal dan een vorm aannemen van een managed service. Dat kan met hosting bij de inschrijver, of met hosting bij Digipolis. Houd er rekening mee dat de laatste optie een impact heeft op de kostprijs. Zorg ervoor dat het volledige financiële plaatje voor alle kosten die verbonden zijn aan EAAS, inclusief hardware, software licenties, hosting, services, … ingediend zijn.
DAAS (DA as a Service)
Het grootste deel van de verantwoordelijkheden ligt bij Digipolis. Dit kan wanneer de service volledig conform de standaarden van Digipolis wordt opgeleverd én er binnen Digipolis een team is dat de verantwoordelijkheid neemt om incidenten inzake de service op te nemen. De inschrijver voor een opdracht schat in welke activiteiten door Digipolis opgenomen worden van zodra de oplossing in productie staat. Eventueel wordt er een budget voorzien wanneer de inschrijver hiervoor een team beschikbaar heeft.
XAAS (miXed as a Service)
Een combinatie van beide: Digipolis en de inschrijver hebben een gedeelde verantwoordelijkheid en nemen elk een deel van het onderhoud op zich. Het support contract kan dan alle vormen aannemen. De verdeling van de verantwoordelijkheden wordt er per engine met de inschrijver aangeduid in een RACI sheet (template) en uitgewerkt in een support overeenkomst (template).