Let`s zoom in on my first assignment

An overview what I will discuss in my next series more in depth

Previously on...

I finished up my previous series about how I started to explore the consultant side of the IT sector.

This blog post starts a new series. Below you can find a bullet list of what is used in this project. The topics on which I'll be blogging are DevOps, Analyses, Development, Acceptance Environments, Documentation and Knowledge sharing. This way, I have some structure on what I can write about next.

Through this, I want to inspire others or have discussions about why other approaches can be more beneficial.


I help deliver a project that will enable a user to signup into the customer portal using a registration system. The customer asked me to develop two Web App services that are functioning as REST APIs.

When a user signs up, he will have two options:

  • using Auth0 and ItsMe, so the user can be verified using the ItsMe app

  • using personal data with verification sent by sms or email.

Technology used


I do not have access to create pipelines and resources in Azure DevOps. However, I do function as a lead for my services so I do work closely with the DevOps persons when problems arise or information is needed.

  • All services make use of continuous integration as well as continuous development. The customer describes what branching strategy I should use.

  • The entire solution is deployed using Web App ASE on Azure.


This has already been done by the enterprise architect and the business analyst. What I did was help with:

  • Clarifications and documents to reflect what is development

  • Challenging content of access tokens

  • Challenging REST-call signatures


The setup of the solution consists of a service-oriented architecture. With some good faith, you can see some resemblance with the microservice-oriented architecture.

Acceptance Environments

The business analyst will validate the services using SoapUI and PostMan. Whenever an error occurs, extra system tests and/or unit tests are written.


The analysis needs to reflect what is going to be developed, as well as what is developed. However, I make it my mission to put as much of the documentation in swagger.

Knowledge sharing

  • Each week, there is one hour that the .Net developers on the project meet to exchange strange issues, nice discoveries and so on.

  • Using the 4 eyes principle, we can help out each other.

  • When there is some discussion where the customer does want to have some answer, I do talk to my XPirit colleagues about it. After having the discussion, I write a concise email to the customer with the problem and how we recommend approaching this.


With this post, I have mentioned a lot of technologies, architectures, and ways of working that I will explain more about in the next posts. Let me know what topic you want to know more off in this context.

Did you find this article valuable?

Support Kristof Riebbels by becoming a sponsor. Any amount is appreciated!