Onze aanpak

1. Discover

Elke succesvolle IT-oplossing begint met een grondige verkenning. In de Discover-fase brengen we de behoeften en uitdagingen haarscherp in kaart. Dit doen we door een gestructureerde aanpak waarbij we diepgaand onderzoek combineren met strategisch en technisch inzicht.

Wat houdt de Discover-fase in?

  • We analyseren de vraag en uitdaging van de organisatie.
  • We verzamelen en structureren technische en functionele requirements en werken deze uit in een backlog.
  • We brengen de gewenste processen samen met de gewenste oplossing in kaart in één overzicht. Dit heet een Service Blueprint.
  • We modelleren de architectuur en definiëren een Data- en Domeinmodel.

Door deze gestructureerde werkwijze leggen we een stevige basis voor het verdere ontwikkeltraject. Waar de klant al strategische keuzes heeft gemaakt, zorgen wij ervoor dat deze optimaal in kaart worden gebracht om vervolgens een stevig en doordacht ontwerp te kunnen maken.

Met de Discover-fase zorgen we ervoor dat alle betrokkenen dezelfde visie delen en dat de juiste prioriteiten worden gesteld. Dit voorkomt verrassingen en zorgt ervoor dat we in de volgende fasen – Design, Develop en Drive – doelgericht en efficiënt te werk kunnen gaan.

Design

2. Design

In de design fase, vertalen we functionele eisen en wensen naar een prototype en technisch ontwerp. We beginnen altijd met het maken van een prototype om te valideren dat de oplossing voldoet aan de behoeften van mens en organisatie. Zo besparen we onnodige ontwerp- en ontwikkelkosten. Prototypes zijn namelijk sneller gemaakt dan software, zelfs wanneer die met low-code is ontwikkeld. Pas nadat we de functionele oplossing hebben gevalideerd, vertalen we deze architectuur en datamodellen.

Tijdens deze fase draait het voornamelijk om het vaststellen van wat precies moet worden opgelost en met welk doel. Hier zal een enterprise/domein architect voornamelijk de vraagstelling definiëren en valideren met de belanghebbenden. Dit wordt gedocumenteerd in enterprise- en referentiearchitecturen.

“Een enterprise-architectuur (EA) is een conceptuele blauwdruk die de structuur en werking van organisaties definieert. De bedoeling van enterprise-architectuur is om te bepalen hoe een organisatie haar huidige en toekomstige doelstellingen effectief kan bereiken.”

“Een referentiearchitectuur is als een handleiding die je vertelt hoe je mensen, processen, producten en diensten samenbrengt om een oplossing te creëren. Het laat zien hoe je specifieke technologieën het beste kunt gebruiken, waarbij je de best practices uit de sector volgt.”

Daarnaast hebben we gebruikersacceptatiecriteria nodig bij het opstellen van nieuwe functionaliteiten. Van tevoren checken we met de gebruiker wat de applicatie nodig heeft om te voldoen aan de eisen en daarmee goed genoeg is. Deze worden dan verwerkt in user stories.

Develop

3. Develop

Om in de development fase flexibel in te spelen op de behoeften van gebruikers, werken we agile en in sprints en geven we een demo. Tijdens een demo kan er feedback worden opgehaald met de gebruikers. Peer reviews en regressietesten zijn voor ons manieren om de software tussentijds te testen. Daarnaast vinden we het belangrijk dat de gebruiker nieuwe software accepteert voordat deze naar productie gaat. Met een gebruikersacceptatietest zorgen we ervoor dat nieuwe software pas wordt opgeleverd als de gebruikers tevreden zijn. Het moet bijdragen aan de werkzaamheden in het proces en meerwaarde toevoegen. Als de software op een gegeven moment groot genoeg is om ook echt waarde toe te voegen, dan gaat het over in de drive fase.

In deze fase wordt door een solution en/of technische (software, infrastructuur, data, cloud, security etc.) architect het ontwerp voor de technische oplossing gemaakt. Het doel van architectuur is om de meest optimale “fit for purpose” oplossing te bieden. Dit houdt in dat de oplossing effectief is en voldoet aan de behoeften, mogelijkheden en doelen van de organisatie, en tevens voldoet aan de eerdergenoemde Enterprise- en/of referentiearchitectuur. Daarnaast is architectuur is deze tijd ook agile en dus continu onderhevig aan veranderingen.

Drive

4. Drive

In de drive fase voegen we steeds nieuwe functionaliteiten toe door dezelfde stappen weer toe te voegen aan het proces. Met deze manier van werken heb je uiteindelijk een veel hogere ontwikkelsnelheid. In de drive fase nemen we ook nieuwe applicaties in beheer. Zo kunnen we ondersteunen bij het gebruik van de app en doen we het onderhoud zodat de applicatie probleemloos blijft werken.

Resultaat

De uitkomst van onze aanpak meten we in cijfers. Dat kan zijn als het gaat om een nieuw project en het nieuwe product moet zorgen voor een hogere omzet. Gaat het om een bestaand product? Dan kun je ook kijken naar het verbeteren van de winstmarge. De belangrijkste resultaten waar de focus op ligt zijn automation rate, marge en medewerkerstevredenheid.

Door het gebruik van low-code en door een goede analyse te doen voordat je begint met het ontwikkelen hoeft er minder geïnvesteerd te worden. Als je meer investeert in de discover en design fase, ben je minder geld kwijt in de develop fase en zal de ontwikkeling van de applicatie sneller worden doorlopen.

Benieuwd naar de mogelijkheden?

Ben je nieuwsgierig naar hoe jouw probleem opgelost kan worden met het 4D-model? Of ben je zelf al goed op weg met je eigen plan en wil je dat 1 van onze professionals met je mee kijkt? Neem dan vrijblijvend contact met ons op!

Jimmy Iliohan