Digital Ambition Team

Welcome to the future of VolkerWessels Telecom

About

The Digital Ambition Team of VolkerWessels Telecom is a dynamic team that focusses on developing Open Source solutions for the business.

Our pride

Operational Data Hub

An Operational Data Hub (ODH) platform was created to enable the digital transformation of VWT.

ODH

The ODH implements an enterprise application integration architecture in which a central data hub facilitates all applications to connect and exchange data. This central data hub serves as the all-inclusive source of truth, capturing all information and business events, enabling the data driven enterprise.

CI/CD

An open source security-built-in CI/CD environment, supporting agile software development is the foundation of the ODH platform. This CI/CD environment allows agile software development with built-in enterprise grade compliance and control.

  • Features
  • Enterprise Application Integration platform
  • Services run-the-business and observe-the-business
  • Business Intelligence (BI) services
  • Data Science platform
  • Hub-model integration keeps you in control of application integration
  • Zero-maintenance Data catalog
  • Built-in security framework
  • Supports full CI/CD into production environment
  • Principles
  • Software defined
  • Serverless
  • Cloud native
  • Security by design
  • Data integrated
  • Open Source
  • Supported operating models
  • Anything between IT Ops and NoOps, including DevOps and DevSecOps
  • Delivering control by GitOps, supporting NoOps by automating everything

Our principles

The way we work

Cloud native

Designed according to cloud-native architecture

Serverless

Just bring your code, pay-per-use

Open Source

Source code is publicly available

Software defined

IT infrastructure as code

Data integrated

Data not locked-up in applications and data silo’s, but available and shared

Security by design

Security is not added afterwards or a separate asset, but it is built-in in software, SDLC and developers’ minds

Languages & Tools

Our favorites

Python

Angular

Docker

Google Cloud Platform Icon

OpenAPI

Google Cloud Platform Icon

Google Cloud Platform

Github

Ubuntu

Portfolio

Recent Work

Organisations

Where we are

Open source

Contribution Policy

It is incredibly helpful when issues or bugs are reported. To ensure that these issues can be solved as quickly and as goal oriented as possible, we've but together some guidelines for submitting issues.
  • Use a clear title and be descriptive. This is important, because it allows us to evaluate importance between issues.
  • Start the issue with a description of where you found the issue. This allows us to read the rest with a clear insight of what component we need to look at.
  • Add the error message so we know what the issue is.
  • Describe how we can reproduce the issue. Try to describe the exact steps you took.
  • Include the output of any scripts that ran during or before the issue occurred.
  • Describe what you expected to happen and how that is different to what happened.
  • If you created a solution, please create a Pull Request and link it.
New ideas or enhancements are always helpful and welcome! To help us understand the idea better, we've put together some guidelines for submitting these suggestions.
  • Use a clear title and be descriptive.
  • Start the issue with a description of what component will need to receive the enhancement. This allows us to read the rest with a clear insight of what component we need to look at.
  • Describe what the enhancement is and what is should do. Be as clear as possible, and try to add possible outputs to the description.
  • Describe why the enhancement should be added to the project.
  • Add examples of the new enhancement.
  • Already changed some code? Create a Pull Request and link it to the suggestion!
  • Use past tense (Do: Removed ..., don't: Remove .... Do: Added ..., don't: Add ...)
  • Act as you take the action (Do: Moved ..., don't Moves ...)
  • Messages should not contain emojis. (Do: Deleted ..., don't: :apple: ...)
  • References to issues should be added, if possible (Do: ... #2, don't: ... Trello-12)
  • We use Jira Tickets, you shouldn't (Do: ... #2, don't: ... DAT-0000)
Architecture Decision Records
We use ADR's to ensure that decisions made by different developers will still result in the same guidelines being followed. While the list greatly expands outside of the scope of this project, it might still be an interesting read: Our Architecture Decision Records
Code
We follow best practices and coding styles that are described by the creator. For some languages, we increased the guidelines:
Tests
Running the following test/checks/validators/linters will increase the integrity of the project.
Cloudbuilder-SAST
We run these tests on every project See the project on GitHub
Cloudbuilder-DAST
We run these tests on projects that are deployed and accessible on the web See the project on GitHub
Cloudbuilder-unittest
We run these tests on API projects that are deployed and accessible on the web See the project on GitHub
Extra

Became curious or just want to grab a cup of coffee?

Contact us! View our GitHub page