Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
The way we develop our products and collaborate together is based on the Scaled Agile Framework (SAFe), be it with some adaptations to better match our ABB Digiteam way of doing things and the number of people in our team.
Big challenges are broken down in smaller, manageable parts. In doing so a constant flow emerges and as a team we can see our solutions grow.
Transparent overview on the work done and to be done
Divide our work in manageable parts
Plan enough and plan in a flexible way
Getting the responsabilities in the right place
Our Rolling Wave based roadmap looks ahead for at least one year.
The Groeispurts of ten weeks systematically end with a Centrale Planningsdag.
Every Groeispurt consists out of four sprints and one IPI.
The release of product features that have been developed and tested is not necessarily linked to the pace we follow at our three levels.
We use a comprehensive roadmap. We find it important to define for who a specific functionality will provide value. This roadmap can be found in our online-tool which is linked to JIRA. JIRA is used by the productteams to plan and follow-up sprints and spurts.
Creating and adjusting the roadmap is a continuous process: this is adjusted every spurt in function of the results and experiences of the past spurt and any additional goals or changed priorities.
A 'groeispurt' has a duration of ten weeks. It contains four development sprints and one Innovation and Planning Iteration. During the last week of a groeispurt a Centrale Planningsdag (CPD) is held where the goals for the next groeispurt are being determined and feature planning for the products are made and agreed upon.
Because we all work in periods of ten weeks, we keep sufficient focus on setting the necessary steps in the development of our products and at the same time we remain agile to cope with ever changing contexts. In doing so the scrum teams have a clear focus on the spurt and sprint goals for the upcoming ten weeks, leaving room for focus shift in the next Groeispurt in case priorities within ABB are all of a sudden changing.
A sprint is well defined period of two weeks in which the product team starts working together to achieve a clear sprint goal. Sprints are following each other immediately and have fixed elements/ rituals:
Sprint Planning
Standup
Sprint demo
Sprint Retrospective
Backlog refinement
Next to the development of features, which is a core focus for every product scrum team, there is a need as well for other activities that make product teams grow. For that reason every last two weeks of a Groeispurt are atypical because it explicitly makes room for …
Innovation and experiments
Training
Planning activities for the next Groeispurt
When? The Innovation and Planning (IPI) iteration is organized at the end of a Groeispurt.
To organize the activities that are typically done in the IPI we made a calendar and plotted the must-have activities on that calendar. In plotting the activities we took into account some preferences of the team regarding meeting days and tried to group the innovation activities as one block to prevent focus drift between innovation and planning meetings. This calendar is being used as well to put placeholders for certain IPI activities in the personal calendars of people who need to attend.
Typical IPI-activities are: testing new technologies, sharing newly developped functionalities with other teams, knowledge transfer, scoping sessions & brainstorms, retrospectives, …
Our IPI calendar at ABB currently looks like:
WEEK 1 IPI: FOCUS on sprintplanning IPI - Innovation - Inspect and adapt
WEEK 2 IPI: Focus on Groeispurtplanning (CPD and prep) - Retrospective and Sprintdemo IPI
The capacity of an IPI can not be used to reach the Groeispurt targets and thus may not be considered as an extra sprint to build product features. The sprint should be used to give the teams time to work on innovation for future purposes, to document what was built, to prepare and plan the next Groeispurt and to look back on how the team performed in the Groeispurt that is approaching its end.
The central planning day is a crucial moment to look back at the Groeispurt that is ending and to look ahead and plan for the next Groeispurt. Therefore it is situated inbetween two Groeispurts.
It provides time for all actors involved in our agile product development to …
show wat has been realised in a series of plenary product demo's.
plan the next Groeispurt using the preparation that has been made in the days proceeding the CPD. Ultimately epics (product features) will be planned for execution. Their execution will contribute to the oplossingen they are linked to.
align with other product teams to realise shared solutions.
Het programma van een CPD is gebaseerd op de onderdelen van het standaardprogramma dat binnen het Scaled Agile Framework wordt beschreven maar de activiteiten worden doorheen de volledige IPI verspreid. De belangrijkste finale afstemming gebeurt op een één dag.
When? The central planning day (CPD) is organised every second Thursday of the IPI.
What? | Purpose | Attendees | |
---|---|---|---|
Day/Part
Monday
Tuesday
Wednesday
Thursday
Friday
AM
Sprintplanning IPI
Innovation
Innovation
Innovation
Inspect and Adapt
AM
(Retrospectieve)
Capacity check DEV + Design
PM
Innovation
Innovation
Innovation
Innovation
Inspect and Adapt
PM
(Retrospective)
AM
Impact Mapping
Impact Mapping
Story Mapping
CPD
Retrospective
AM
Story Mapping
Story Mapping
Impact Mapping
PM
Impact Mapping
Impact Mapping
Capacity Check PM's ifv planning
CPD
Sprintdemo IPI
PM
Story Mapping
Story Mapping
Prepare backlog for sprint 1
In advance (before the CPD)
Impact mapping for every value stream
Overview of possible deliverables
PM's & PO's,
Solution level
Designers
Business Analists
Business-reps
In advance
Retrospective for every product team
Look back and learn from experiences in the previous groeispurt
Every team member of a product team
In advance
Preparation CPD with the product team
What is to be done next, in the upcoming groeispurt. - Storymapping - Planning on CPD-canvas
PM en PO
Development leads
In advance
Capacitycheck - sync with dev's and designers
Matching demand and supply of developers and designers for the upcoming groeispurt
RedPencil
Hannes
Veronique
In advance
Capacitycheck - sync with PO's and PM's
Feedback to PM's and PO's on the availability + capacity of developers and designers to PM's and PO's.
PO's
PM's
Veronique
9h00 - 9h15
Introduction to the CPD (IT-director + Manager Digital Solutions)
Introduction, setting the stage
PM's & PO's
Product teams
Business-reps
Solution level
9h15 - 10h30
(product)demo's for every value stream on achievements previous Groeispurt
Show what has been delivered by the product teams for all relevant value streams
PM's & PO's
Product teams
Business-reps
Solution level
10h30 - 15h00
Break-outsessions per value stream
Final rundown of the planning for the various product teams collaborating in value streams
PM's & PO's
Relevant product teams
Business-reps
15h00 - 15h30
Finalizing groeispurt planning per product
Moment for PM's and PO's to finalize the product planning before presenting it on the plenairy session.
PM's & PO's
15h30-16h30
Presentation of sprint planning and sprint goals per product
Presentation of the planning per product team. The presentation implies an implicit confidence vote by the teams involved.
PM's & PO's
Productteams
Business-reps
Solution level
Gelinkt Notuleren is a web application that helps with the creation and publication of agendas, minutes and decisions for Local Authorities.
The aim of Gelinkt Notuleren is not to compete directly with existing notetaking software. The purpose of the application is to show that taking minutes that are enriched with linked open data is possible, and to help local governments without a notetaking package.
The Embeddable is part of Gelinkt Notuleren. It is a smart word processor that ensures that specific information from meeting minutes is enriched with data, in a structured way, so that we can extract and reuse that information afterwards.
These data models are available in Dutch.
The embeddable is part of Gelinkt Notuleren. It is a smart text editor that can ensure that specific information from minutes is enriched with data, in a structured way, so that we can extract and reuse that information afterwards.
External suppliers of notetaking software that help local governments with the creation of minutes, can also reuse this embeddable in their software package to extract the data. They are not obligated to use the embeddable, as long as they publish the information according to the standard.
Gelinkt Notuleren collects knowledge from decisions that local governments make. This knowledge is then made available for reuse.
Discover how we develop our applications on the page .
An open-source text editor that enriches specific information from minutes with data, in a structured way, so that we can extract and reuse that information afterwards.
The Embeddable is a building block of Gelinkt Notuleren. It is a smart, open-source text editor that enriches specific information from minutes with data, in a structured way, so that we can extract and reuse that information afterwards.
Third-party note-taking software that help local boards create minutes, can also reuse this embeddable in their software package to extract the data.
We provide this word processor as an embeddable (easily plugged in) for that boards or their software vendors can use in their notetaking packages. We also open up this embeddable under the name of Say Editor for anyone who wants to enrich their word processing with knowledge.
To find more detailed information about Say editor, visit https://say-editor.com/.
The embeddable consists out of multiple building blocks that make linked note taking possible.
We use multiple data sources to enrich notes and minutes:
The Flemish Codex – references to the legal grounds in decisions.
Mandates – to track attendees, appointing and dismissing.
Executives – to track attendees.
We have created separate small apps that can be plugged in the text editor.
Toolbar: basic text editing functionalities.
Templates: to make it easier to start with note taking.
Citation plugin: makes use of the Flemish Codex, and you can use it to reference legal grounds in decisions.
Voting: vote on decisions.
Attendees: track who was part of the meeting, and was part of certain decisions.
Import – export: make sure you can import- and export decisions (in progress).
Annotations: annotate text with specific linked information, like mandates
Signing: signing minutes, excerpts, agendas, decision lists.
Authentication: log in via Gebruikersbeheer (user management ACM-IDM)
Anonymise: Remove personal information for public view.
Read the documents of Say Editor to see how they are set up: https://say-editor.com/docs.
All of our applications are built in the same way. Read the Architecture page before you get started with our repositories.
Add your own text editor in your ember app:
The Agency of Home Affairs works closely together with the department Mobiliteit en Openbare Werken (MOW – Mobility and Public Works) and Agentschap Wegen en Verkeer (AWV – Roads and Traffic Agency). Together they are creating a register of measures including signs and markings on the road.
Discover how to set up the code under the section DEVELOPMENT > Architecture.
Main feature passports forLBLOD:
Find specific feature passports for Register van Maatregelen here:
We build our application based on linked open data models. Find them here:
Some examples we use:
The Flemish Government has built a web component library. We are not currently using it:
In its current form, the 3.0 version, this library is available when we use their Web platform. Within our application architecture, we do not use that Web platform, and therefore cannot use the Web component library.
The 3.0 version is not open source. We create open source applications, and thus need open source solution. Our applications are based on their Web components, an older version, when they were still published open source.
To build our applications with, we created an open source component library.
The library is based on the old web components of the Flemish Government, version 2.0. This is where we built our applications with in the beginning, when they were still published open source. To make sure we could fix bugs, extend the library for specific application components and publish our applications open source, we created Appuniversum. Anyone who wishes to use this library, more specifically in the context of projects for the Flemish Government, may do so.
This component library currently consists of two parts: Appuniversum & Ember-Appuniversum.
The Appuniversum base consists only of HTML and CSS. Anyone can use these basic elements (HTML elements that do not require JavaScript) in their applications, regardless of the technological choices they have made in terms of JavaScript libraries. Read more about the guidelines on the documentation site.
Our applications use Ember.js as their Javascript framework. Only Kalliope uses a different platform, offered as a software package from a vendor.
For this reason, we build our web components in Ember. These cannot be easily exchanged with other application builders within VO, but they may always reuse our code. Webuniversum uses Vue.js.
Contribute here: https://github.com/appuniversum/
Find more information about ember on the architeccture page ember.js.
Central Planning Day, Innovation and Planning Iteration, Workshops, ...
Visualisation collaboration
Need access? Ask Miet Claes
Conducting workshops with clients
Need access? Ask Anne Van Looveren
Find standard slides here:
Local Decisions as Linked Open Data (LBLOD) is a program. It includes all ABB projects on linked data and local decision making.
Linked data is a digital method of structuring and publishing information so that people and (search) machines can consult it on the internet.
To ensure that this information can be made publicly available in an open and linked way, the parties in the ecosystem have devised various solutions and developed applications for them.
Local decisions contain valuable authentic data for everyone.
As a citizen, I want to know when my street is inaccessible because of works.
As an entrepreneur, I want to know what obligations I have to fulfil.
As an association, I want to know if I can get subsidies, and how much.
As a member of civil society, I want to know how local authorities shape their cultural policy.
By publishing the data in local decisions as linked open data, organisations can reuse that data more easily. Linked data is standardised, making it easy for machines to find and process it. Anyone can work with the information in the local acts thanks to LBLOD.
A concrete example: agencies and departments of the Flemish government can themselves extract the information they need from the published decrees. Local authorities do not have to send or deliver this information every time.
English subtitles available in the player!
The products and services at ABB are based on Linked Open Data. Public data, not privacy-sensitive data, are collected and shared in such a way that people within and outside of the government can use, reuse and enrich.
How to conduct user interviews and tests online.
Since 2020 we have been conducting remote, online, user tests and interviews. We have found a pretty flexible way to perform that testing. Below you can find a suggestion of how to conduct those user interviews and tests, but make sure you adjust the tools according to your needs!
scope
Decide with your team members what you are going to test and why. This will dictate what questions you'll ask, what type of test you'll conduct and who you will contact.
What
Which assumptions do you know you have, and which ones do you want to test?
What answers are you looking for?
What do you know you don't know yet?
Who
Who can answer these questions for you? Who will work with the application? Who do you need to convince to get the entire team to work with your app?
How
How you're going to test is going to depend on what you are testing. If you are testing raw ideas, you'll probably share wireframes (via screen sharing for example). If you are testing an application, you'll need a dev environment ready and you'll probably want people to share their screen with you.
Why
What do you want to do with these answers afterwards? Do you want to make sure you know what new features to develop, or which ones to improve? Or would you want to set up webinars afterwards to get people to use it? Many options.
inhoud test
Define the structure of your meeting.
Will it have an interview part? Will you send the questions up front?
Will you test with wireframes, mockups, a prototype or something else?
Which parts are there to your test?
Conclusions
For drawing conclusions overall, after each session, we already add conclusion tabs to the template, per interview- and test section. These conclusion tabs you can already prepare up front; because they help you define up front what you want to know. Sometimes you need multiple questions to gather one insight.
timing
Allocate time to the different parts of your test and interview. Allocate the most time to what is important. Make sure you have some time to run out; you don't want your meeting to be stuffed to the brim. Things will go wrong.
No clue how to time it? Do an internal pre-test with some colleagues to give yourself a better idea.
name
, type of participant
, organisation
, type of organisation
, contact person
, tag
Get an overview of who you need to talk to to get the relevant information for your project – and what steps you can undertake if you cannot find those people right away.
Usually the product manager sets up the meetings via personal contacts, or partnerships that are relevant to the product or via the client (VVSG – Vereniging van Vlaamse Steden en Gemeenten, Inter, Klankbordgroep Gent).
Fill out their name
, type of participant
(think of which type of people you need to see to get a good grasp on your answers, broad and diverse enough), organisation
and type of organisation
(also relevant for your end results) and who the contact person
is (probably your product manager; this is helpful during the introduction or when someone does not show up). The tag
can help you to anonymise information later on, but is optional.
date
, time
, location
Before anyone starts contacting interviewees, make sure you block out enough placeholder time ahead with the appointed team members; so the product manager can align agenda's with the interviewees.
Make sure you have a bit more time allocated to the meeting than you planned for in the interview / test (because things will go wrong).
Location: make sure everyone knows up front where the meeting will take place. Add them to the document to make sure you can switch easily.
interviewer
, notulist
, specialist
Appoint an interviewer
, and someone that takes notes (notulist
). If they switch, it'll be different every session; just make sure everyone knows up front.
Sometimes it's helpful to have a specialist
on board (like a jurist) to answer specific questions about the topic you're dealing with. Try answering these questions at the end of the session, because it's easy to get lost in details and go off-topic.
More than 2 people can be overwhelming to the test subject, so find out what's the best for the outcome.
Consider turning off camera's for people that are not taking the interview, but do involve everyone in the introduction (smile & wave) and when saying goodbye.
The goal of the introduction is to make people feel at home and set expectations.
The interviewer takes te lead and lets everyone (including the notetaker, specialist, ...) introduce themselves briefly. Mention the contact person (see attendees) if needed to make sure everyone knows why they are here.
A virtual round of the table is hard; you don't know who's next to you. The interviewer calls out everyone one by one to introduce themselves.
The interviewer goes over the setup.
What can they expect, what do you expect
Explain what is going to happen and why; what you want people to focus on.
Explain the structure of the meeting before they start – so they know what's coming.
GDPR: Explain what happens to the notes, and what their rights are.
Sometimes interviewees think they have to elaborate, do things differently than usual or "do a good job" (most of us want to!) . Try to debunk that.
If something goes wrong, that's excellent.
Make sure everyone knows it's okay to make mistakes, be confused and have questions – and that it is valuable information. We are testing the application (or service or idea or...), not their skillset.
Honesty is key to get value out of these sessions.
The interviewees should know that they can't insult (or compliment!) anyone in the room.
Their lead
The interviewees don't need to be extra elaborate or extra fast – they can just act the way they would as if they're at home or in the office.
Think out loud
Urge your test subjects to think out loud (and show their frustration) to help the interviewer and notetaker understand what is going on.
Leave room for questions!
To understand the feedback you're getting from your interviewees, you need some context. The interviewer and the interviewee are mostly speaking. As little intervention as possible from is expected others. If the notetaker missed something, it's okay to speak up.
Ask targeted questions if there are multiple people in the room, don't leave it open-ended (in a remote situation this usually causes silence)
Only ask one question at a time.
This is easier to answer
You'll most likely get an answer
It's easier to note down.
Think of what you need to know, and what to leave out. This depends from test to test.
Some examples:
Demography & Job
– ask about their function, and what they do on a daily base. This can frame how often they would be interact with your product (or service or..).
Digital skills
– if you have little knowledge about your interviewees, it will be helpful to know what their digital skillset is. If they spend a lot of time using their computer during their job, chances are high they'll onboard your application much quicker than someone that only uses their ipad during the weekend; and they might need more guidance.
Applications
– if they use similar or other applications to complete the job you're interested in, you know which patterns they might be used to or what quality they expect.
Previous use
- it's possible people have already used your application. You might want to figure out what they think about your application now; and see if it's different after they've seen your new features or adapted features.
These questions will also help you to create archetypes (persona's) later on, that can guide you when building features.
Add as many rows as needed to keep an overview.
If you are interviewing multiple people at the same time (depending on your situation this can happen, even if it is not always ideal) add initials or tag of the person that is giving an answer or to the information you are writing down.
If multiple people are editing, make sure you're not overriding what they just wrote down.
Decide when and how you're going to ask these questions:
Up front (via mail)
Reduces meeting time; which everyone likes.
If it's a lot of questions, it can feel like an annoying assignment – chances of it getting completed get lower with every question. This is especially the case with busy people.
You can ask "why" or elaborate during the meeting.
During the test
Elongates meeting time.
No "homework" feeling.
Easier to ask questions and go deeper when they are filling it out.
Can take long when doing this together.
The interviewer and the interviewee are mostly speaking. As little intervention as possible from is expected others. If the notetaker missed something, it's okay to speak up.
Ask targeted questions if there are multiple people in the room, don't leave it open-ended (in a remote situation this usually causes silence)
Only ask one question at a time.
This is easier to answer
You'll most likely get an answer
It's easier to note down.
Make sure you have a separate, stabile test-environment – where anyone can safely add test-data. Warn the developers not to deploy when you are testing!
Make sure people can share their screen if needed.
Have a back-up scenario available that allows you to to share your screen and perform the tasks they want to complete, just in case it doesn't work out. Make sure you don't steer or influence especially in this case.
If you are testing raw ideas, you'll probably share wireframes (via screen sharing for example).
Make sure people can see the relevant applications on your screen.
Turn off notifications to not be disturbed.
Make sure people don't have to see a cluttered background, irrelevant information or irrelevant tabs pass by.
Take it easy. Don't make people motion-sick. Give them time to inspect.
Your testing questions will depend on which type of test it will be. The main setup is giving someone an assignment, see how they complete it, and ask them nudging questions to discover what is going on in their mind.
When you have a clickable prototype:
"Create a new file"
"Fill out the form"
When you have a concept in a wireframe or mock-up
"If you would want to create a new file, how would you go about it?"
Refrain from giving people answers. If they ask you "is it this button?", you can ask them to try it out, and discover it together. Assure them nothing can go wrong.
Add as many rows as needed to keep an overview.
If you are interviewing multiple people at the same time (depending on your situation this can happen, even if it is not always ideal) add initials or tag of the person that is completing the task/answering a question or to the information you are writing down.
If multiple people are editing, make sure you're not overriding what they just wrote down.
What to fill out
Opdracht gelukt
Did they succeed?
Think of a system up front like "yes / no / almost"
This will help you when draw conclusions faster in the end
Omschrijving interactie
How did it go?
Where did they get stuck?
What went well?
Add rows if needed
Opmerkingen
If you have anything to add, like thoughts or suggestions (from anyone in the room), you can add it to the comments field.
To make sure you know what's happening inside people's minds, and why they make certain decisions, you can help them think out loud by asking questions:
What do you see here?
What can you do here?
Did this button meet your expectations?
The interviewer and the interviewee are mostly speaking. As little intervention as possible from is expected others. If the notetaker missed something, it's okay to speak up.
If you decide to do a guided test, and want to teach people how to work with your application (or service or..) more than discover what to improve, you can show them or help them complete a task. Then give them time to try it themselves. After a while you can ask them how it went.
How did it go for you? Did it work out?
If they don't give you a lot of details, you can ask what went well and what did not, and get into a conversation if needed.
The one question that you probably want an answer to is "Would you use this application/service/...?" You can ask any variety on this, but this will probably give you the best insight.
Ask for feedback on your test as well, see if there is room for any improvement.
This is also a great time to ask if you can contact them again in the future to be part of other tests or even enter your customer advisory board.
Tell people what is going to happen.
Will you send them an e-mail with follow-up? When?
When will they be able to see something? Do you want to keep them up-to-date?
Do you want them to participate in other tests?
Ask them if they want to!
When you're done with all the interviews, you can start drawing conclusions. This is will be different for each set-up. Up front, you can however define which conclusions you know you already want to draw – but you don't know what you don't know, so this will change.
Valuestreams are used to describe the sequence of activities (end to end) needed to deliver a product or service to a customer (as an organization. The value streams of ABB where Digiteam is contributing to - at the time of writing- are:
Met gelinkte sjablonen maken lokale besturen kwaliteitsvolle besluiten met authentieke herbruikbare gegevens
Gelinkt publiceren en melden zorgt voor doorzoekbare besluitinformatie
Gestroomlijnd communiceren tussen Vlaanderen en lokale besturen
Vereenvoudigde en interactieve toegankelijkheidsinformatie leidt tot meer data en een groter inclusiviteitsbewustzijn
Het duurzaam, betrouwbaar en herbruikbaar open stellen van (contact)gegevens van lokale besturen
Het beleid rond geloofsgemeenschappen steunt op duurzame, betrouwbare en herbruikbare informatie
Kennisgedreven digitale end-to-end dossierbehandeling
Ondersteunende waardeketens
De IT-dienstverlening wordt op een duurzame, kwaliteitsvolle en efficiënte manier ontwikkeld en ondersteund
A new idea for a solution always fits into an existing or new value stream.
Value streams are coordinated and synced on a solution level.
Ideally every value stream has a clear and representative description.
A solution describes the way Digiteam contributes to the enhancement or the creation of a values stream. Every solution that is built within Digiteam must contribute to one (or more) value streams.
A solution might need development in one or more products. When various products are involved, alignment is very important to deliver the solution in the existing cadence.
A solution can be built and delivered over more than one groeispurten/ growthspurts.
Solutions are initiated, described and managed at solution level.
Whom is responsible for the management of the solution can either be
A dedicated member of the solution level, or
A PM when the solution has a very good fit with the product he or she is managing.
Every solution is described clearly and in a condesed way on a Solution Index Card
We use Epics to clarify how an end user functionality in the product concerned should be developed. An Epic is a description of a functional block that, once built and made available in the product to end users, will deliver a certain value to the business owner. The time needed to realize an Epic is usually longer than a sprint. At ABB, we try to dimension Epics in such a way that they can be delivered in 1 growth spurt. We do this because the planning focus on a central planning day - in principle - does not extend beyond 1 growth spurt.
Microsoft Teams is used as the central communication tool for online communication. All classic agile scrum 'ceremonies' are held using Microsoft Teams (e.g. sprint planning. stand-up, Backlog Refinement, Sprint demo's) as well as the Groeispurt Preparation activities such as Impact- and Story Mapping, Spurt Planning and Spurt Retrospectives.
Furthermore, a number of products use Teams Channels to communicate efficiently on certain relevant topics related to builing, testing, releasing and operating the application(s).
Questions? Contact Serge serge.gillebeert@vlaanderen.be
Sharepoint is used to properly and securely capture administrative matters of the operation and documents that contain personal information. For example, the attendance calendar and contracts are maintained in this way.
Questions? Sarah Macquoy sarah.macquoy@vlaanderen.be
We us Miro for various purposes. Product teams engage in Impact Mappings and Story Mappings at various times. During the Central Planning Day we prepare the product planning on Spurt level using a Miro board for every product. During the IPI Miro is also used to carry out Spurt retrospectives where needed.
Some product teams make an even greater use of Miro also preparing product roadmaps and product releases in Miro.
The prototyping tool Figma is used for user interface and user experience design. It enables the product teams to collaborate in real time on user interfaces: it helps us to design relevant screens for users and it helps us to describe as well as possible how the screens should work to the scrum (dev) team that will build the pages. Next up it helps the test team to get the relevant info on what to test without having to read long documents describing the user interface and user experience.
The prototype tool Figma is used for designing user interfaces and user experiences. It enables the product teams to collaborate on user interfaces in real time: it helps them to design relevant screens for users and it helps describing how the screens should work. Furthermore it helps the testing team to get the relevant information about what to test without having to read long documents describing the user interface and user experience.
Jira is widely used within Digiteam ABB as the central tool to operate our sprints and growthspurts. It contains the product backlogs and is used to refine, plan and run a sprint. Furthermore a growing number of product teams are using the releases feature and the roadmap feature to plan and operate the product roadmap.
A Feature Passport contains all the information to describe a specific functionality of a product. In this way we ensure that everyone understands what we are going to build and what its status is.
Welkom! Welcome! Bienvenue! Herzlich willkommen! Bienvenidos! добро пожаловать!
ABB contributes to sustainable and democratic living together in diversity by connecting and strengthening citizens and authorities
More information about ABB: https://www.vlaanderen.be/agentschap-binnenlands-bestuur [Dutch]
ABB is an agile organisation that inspires policy and provides answers for the administrative and social challenges of today and tomorrow
We connect and strengthen citizens and local government through:
The promotion of equal opportunities and living together of citizens in diversity. The supply of a policy framework and instruments which boast the relationship between citizens and local government. The strengthening of the governance capacity of local government, so that tasks can be implemented on the level nearest to the citizen
Collaboration & Agility We find solutions together, believe in the power of collaboration and are open to new challenges.
Trust & Integrity We give and earn trust and promote integrity.
Openness We provide clear information, share our knowledge and operate with transparency.
Decisiveness We say what we do and do what we say.
More than 3000 Local Governments in Flanders write decisions that contain valuable information – every day. We want to make sure that by using linked open data, they can publish their information and (legal) documents directly, and make direct data exchange possible. We make sure we have reusable resources, so that information can flow to other governments & services, citizens, organisations and companies.
ABB provides support for quality & efficiency, to strengthen those local governments.
We build services and products to create that value. Linked data is made possible in 4 ways:
We co-created a Linked Open Data Standard, together with the local governments: a standard way of sharing data between the involved parties.
We validate vendors that provide software that supports note taking for local governments; and make sure they exchange and publish their data in a correct manner. More info [Dutch].
We created "Linked Minutes" (Gelink Notuleren): basic, free decision-making software for local governments without a software vendor – to support linked data.
We are building an innovative open source linked data text editor that allows end users to create machine-readable information 'without effort'. We reuse this editor in our own applications and make sure that external parties can also easily reuse it.
This information is captured in the "Box Office for Local Governments" (Loket voor Lokale besturen) – a platform for data sharing and communication between local governments and the agency for home affairs.
We make this public data available for other governments & services and private re-users.
The Agency of home affairs deliver support via their helpdesk, give trainings and develop solutions to support local governments.
Discover the ecosystem, the solutions and applications that bring citizens and governments closer together [click here to enlarge].
All of our code is open-source, in line with our vision and values: https://github.com/lblod.
6 Policy fields
Local governance
Urban Policy
Brussels
Equal Opportunities
Flemish Periphery
Feature passports exist to support a documentation culture; which is encouraged when building open source applications – as we want to enable people to contribute whenever they want.
Feature passports exists to communicate with team members about the common understanding and status of features that are (about to be) implemented or improved upon.
Use feature passports to:
Write down knowledge that lives in people's heads
Comment & discuss
Find a source of truth for execution (but keep rule 2 in mind, it is not set in stone)
Onboard & update team members
Making sure everyone understands what we are going to build, and what the status is.
Overview of past, present and upcoming growth spurts
Calendar is .
This page contains many of the abbreviations that are used on a daily basis within ABB: Agentschap Binnenlands Bestuur. They will help new people joining our team to get quicker up to speed.
PLEASE, help us to make this list complete. If you bump into an abbreviation or concept we use and you don't find an explanation for it here or if you know one yourself that is not featured on this page then add it to this page to make it more useful and keep it up to date. THANK YOU!
ACM/IDM: Access Management/ Identity Management is the Access Management of the Flemish government (ACM) and the User Management of the Flemish government (IDM). The ACM-part determines the ways a user can log into an application, the IDM-part determines the access roles granted to a user after being logged in.
AGB: Autonoom GemeenteBedrijf / Autonomous Municipal Company is an independent agency of the founding city or municipality and therefore has its own legal identity/ personality. An AGB is always a 100% subsidiary of the founding municipality. An AGB itself can participate in other legal entities in which other (public or private partners) also participate. An AGB is governed by a board of directors. A management committee is responsible for the day-to-day management. The board of directors is composed by the municipal council and consists of a majority of members of the municipal council. Since the composition of the municipal council changes after the six-yearly municipal elections, the board of directors is also reconstituted.
APB: Autonoom ProvincieBedrijf / Autonomous provincial company (APB) is a form of provincial external independence. It is set up by the province, has its own legal personality with a public-law status and carries out specific tasks of provincial importance. All tasks of provincial importance are eligible to be taken care of by the APB.
AVG: Algemene Verordening Gegevensbescherming/ General Data Protection Regulation: The GDPR stipulates that member states consult the supervisory authority when drawing up draft regulations relating to the processing of personal data. At Flemish level, the VTC is the competent authority from whom such advice should be sought. Every organisation should perform a risk assessment and implement fitting technical and organisation measures for every data processing activity. Refer to DPO and DPIA.
BBC-DR: Beleids-en Beheerscyclus - Digitale Rapportering is a module in Loket Lokale Besturen helping local authorities to comply to / fulfill legal requirements with respect to (financial?) reporting over past periods.
BC&K: Beleidscoördinatie en Kennisorgansiatie is a team of Agentschap Binnenlands Bestuur that has the following tasks and responsibilities.
BIM: Building Information Model is is a digital model of an existing and/or planned construction, made up of objects to which information is linked. In addition to the geometry and position of, for example, a wall, such a model can also contain information such as the building material to be used (masonry or reinforced concrete), costs, the dimensions of an opening for a window frame and the course of the pipework. The object-oriented information can be linked to several things such as phasing, functions, required structural strength, specific connection to surrounding objects, and so on.
BNB: Burgernabije Besluitendatabank/ Public descisions database for civilians is a public decision database of Agentschap Binnenlands Bestuur that aims at making available all public decisions that were reported or submitted by the local authorities and that are related to themes that concern citizens.
BSBVR: Beleid Steden, Brussel & Vlaamse Rand is a team of Agentschap Binnenlands Bestuur that has the following tasks and responsibilities.
BVR: Besluit van de Vlaamse Regering / Decision of the Flemish Government
CEB: Centraal Bestuur van de Eredienst / The central boards of the worship service mainly have financial tasks. In certain cases, they also stimulate communication and coordination at municipal and provincial level.
CPD: Centrale PlanningsDag / Central Planning Day, the core planning and demo event of every growthspurt that takes place every second Thursday of the IPI - Innovation and Planning Iteration. During this event the product teams demo what value has been delivered to the users or ABB as an organization. The demo is being watched by a large number of stakeholders and the various team members. After the demo's the teams gather in breakout sessions to plan the upcoming growthspurt. The CPD is concluded with a plenary session where the results of the planning sessions are being presented. Main focus during this final part of the CPD is on the spurtgoals for every product(team).
COP: A community of practice takes place around a certain role in the operation or specific competencies. During these meetings, examples are shared, new techniques are taught or even new practices are developed.
CVP: Centrale Vindplaats is a repository for structured information derived from meeting minutes, decisions, codelists etc . The data can be requested using SPARQL queries on endpoints of this centrale vindplaats.
DPIA: Data Protection Impact Assessment, is an assessment which documents the technical and organizational measures (how we build controls into techology or how we organize people against risks) the agency implements to protect personal data processed by the agency. Every application should have a personal data processing risk assessment documenten. If there are significant risks to the protection of personal data, we perform a DPIA, which the DPO must advize on. Management must accept residual risks.
DPO: Data protection officer, ensures, in an independent manner, that an organization applies the laws protecting individuals' personal data. (Ref Wikipedia https://en.wikipedia.org/wiki/Data_protection_officer) In Europe, this is the GDPR https://en.wikipedia.org/wiki/General_Data_Protection_Regulation aka AVG, Algemene Verordening Gegevensbescherming.
Embeddable is a 'stripped' version of the application GN/ Linked Minutes that helps local authorities create, annotate and publish agendas, decisions and minutes according to the linked open data principle. This embeddable version is aimed at software suppliers of local governments. The goal of this tool is that they can easily integrate it into the software they have supplied to their customers (local authorities). In this way they do not have to invest time in developing and maintaining core components. The benefit for us as supervising agency is that the quality of the annotated data in the decisions made with this embeddable is up to our standards guaranteeing the reusability of the data.
EVA: Extern Verzelfstandigd Agentschap/ Municipal externally autonomous agency is a services with it's own legal personality. It may take a public or private form.
FP: a Feature Passport is a document that describes one specific feature in a way that is understandable for the (non-technical) stakeholders, the current team members, and potential professionals who will be contributing to the product in the future. It travels with the feature from conception/ design/ development over testing into release. Changing the feature at a later time will go hand in hand with updating the feature passport accordingly.
GEB: Gegevensbescherminseffectenbeoordeling. This is a DPIA, a data protection impact assessment. Refer to DPIA.
GKII: Gelijke Kansen, Integratie & Inburgering is a team of Agentschap Binnenlands Bestuur that has the following tasks and responsibilities.
GN: Gelinkt Notuleren / Linked Minutes is an application that helps local authorities to create, annotate and publish agendas, decisions and minutes according to the linked open data principle. It builds on information from, among other things, the Flemish Codex, the mandate database and the manager database.
GSM: Gemeente-stadsmonitor is is a digital 'environmental scanning tool' that maps the broad environment of every Flemish municipality and city. The monitor contains more than 300 environmental indicators or series of figures, of which more than 100 are collected by means of a three-yearly citizen survey.
GZG: Gemeenten Zonder Gemeentehuis/ Municipalities without a town hall is subsidy program that supports local authorities in Flanders to jointly develop innovative, digital solutions to make their services more efficient and customer-oriented. The first call was opened in September 2021, the last call ran until September 30, 2022. Agentschap Binnenlands Bestuur is closely involved in the management of this program.
IF: Inspectie Financien monitors expenditure and the proper use of government resources, including ABB and more specifically Digiteam. For example, a planned government contract of a certain amount must be submitted to IF for verification, or at certain times reports must be made about what we have done with our resources.
IGS: InterGemeentelijk Samenwerkingsverband/ Intermunicipal partnership is a generic term for the joint provision of public services by several municipalities. The cooperating municipalities are usually (but not always) neighboring municipalities.
IPDC: the Intergovernmental Products and Services Catalog (IPDC) provides an overview of the various services provided by the local, Flemish and federal government. The IPDC is integrated into the 'Single Digital Gateway' of the European Union making sure that (selected) local, Flemish and Federal services are visible on https://europa.eu/youreurope/
IPI: Innovation and Planning Iteration, the fifth and final sprint of a (growth)spurt in which the team makes time for planning and innovation. The idea is to create a break from delivering product features and deliberatly creating room to plan carefully and try out/ experiment things that might come in handy in the future.
IRGN: Interactieve Reglementen Gelinkt Notuleren is an application aimed at local authorities who need help/ guidance in drawing up additional regulations for road traffic. The application consists of two modules:
a front office application for local governments based on the Gelinkt Minutes application of the Agency for Home Affairs (ABB). This allows users to create a new supplementary or temporary regulation.
a management module (central and open register of traffic signs and measures) maintained by the Department of Mobility and Public Works and the Agency for Roads and Traffic. This management module will eventually be used as a source for other mobility applications, for example as a sign library for the Traffic signs.Vlaanderen application.
KALLIOPE: product name for the case (dossier) management system used by the Agency for Home Affairs for managing files related to its operational activities. In the system - which is based on a generic Case Management product of an external party configured to the needs of ABB - 'dossiers' of certain types are managed. For its operation, Kalliope has integrations with other applications of the agency such as: the Digital Loket for digital communication regarding cases (dossiers) with local authorities, the organization portal for keeping contact information of authorities up to date.
LBLOD: Lokale Besluiten als Linked Open Data / Local Decisions as Linked Open Data (LBLOD) is a program. It includes all ABB projects on linked data and local decision making. By publishing the data in local decisions as linked open data, organisations can reuse that data more easily. Linked data is standardised, making it easy for machines to find and process it. Anyone can work with the information in the local acts thanks to LBLOD.
LDES: A Linked Data Event Stream is a new data publishing approach which allows you to publish any dataset as a collection of immutable objects. The focus of an LDES is to allow clients to replicate the history of a dataset and efficiently synchronize with its latest changes.
LF: Lokale Financien/ Local Finances is a team of Agentschap Binnenlands Bestuur that has the following tasks and responsibilities.
LLB: Loket Lokale Besturen/ Counter for Local Authorities is an online application of Agentschap Binnenlands Bestuur for data sharing between local authorities and the agency. It consists of different modules used for different communication topics or purposes.
LOW: Lokale Organisatie & Werking is a team of Agentschap Binnenlands Bestuur that has the following tasks and responsibilities.
LPDC: Lokale Producten en DienstenCatalogus/ local products and services catalog is a digital repository that provides an overview of the various services provided by the local governments. The repository is managed by the local authorities through a webapplication built and maintained by ABB. The creation, the update or deletion of services is synced with the IPDC.
LSVP: Lokale Samenwerking, Verzelfstandiging & Personeel is a team of Agentschap Binnenlands Bestuur that has the following tasks and responsibilities.
METIS: the front end of the Centrale Vindplaats
MVP: Minimum Viable Product is is a product with enough features to attract early-adopter customers and validate a product idea early in the product development cycle. In industries such as software, the MVP can help the product team receive user feedback as quickly as possible to iterate and improve the product.
OP: Organisatieportaal / Organization Portal is a web application used by people at Agentschap Binnenlands Bestuur to visualize and edit data about governing public organizations of local authorities and worship services and people linked to these organizations.
OSLO: Open Standards for Linking Organizations is an unambiguous standard for the exchange of information brought to life by the Government of Flanders. The intention is to ensure more cohesion, better comprehensibility and better findability of information and services. In this way, everyone can use the data more easily.
PEVA: Privaatrechtelijk Extern Verzelfstandigd Agentschap/ Private Law External Independent Agency: The municipal externally autonomous agencies (EVAs) are services with their own legal personality. They may take a public or private form. The public-law municipal EVAs are autonomous municipal companies (AGBs) and municipal autonomous port companies. Private-law municipal EVAs (PEVAs) are companies, associations (especially non-profit organisations) or foundations.
PM: Product Manager is responsible for defining desirable, viable, feasible, and sustainable solutions that meet customer needs and supporting development across the product life cycle. He or she works closely together with the Product Owner.
PO: Product Owner is an Agile team member primarily responsible for maximizing the value delivered by the team by ensuring that the team backlog is aligned with customer and stakeholder needs.
POC: a Proof of Concept is a demonstration of a product in which work is focused on determining whether an idea can be turned into a reality. A POC's goal is not to seek market demand for the concept or choose the best way to produce it. Rather than focusing on building or developing the idea, it tests whether the idea is feasible and viable.
RDFA: Resource Description Framework in Attributes is a W3C Recommendation that adds a set of attribute-level extensions to HTML, XHTML and various XML-based document types for embedding rich metadata within Web documents. The Resource Description Framework (RDF) data-model mapping enables its use for embedding RDF subject-predicate-object expressions within XHTML documents. It also enables the extraction of RDF model triples by compliant user agents. Ultimately, this recommendation is followed by organizations that want to make their data/ content machine readable.
RVM: Register van Maatregelen/ Register of measures is a central digital register for all kinds of measures. Agentschap Binnenlands Bestuur is creating this central repository together with other agencies of the Goverment of Flanders. The register features traffic signs and traffic roadmarks, ...
Register van Reglementaire Bijlagen en Codelijsten / Register of regulatory attachments and codelists is - contrary to the RVM - a register that does not contain single measures but entire templates and codelists that come in handy when drawing up regulations.
RO: Representatief Orgaan/ Representative Organ/ Body is a formal group of people (e.g. diocese, synod, ...) who have an advisory role towards the worship services that are linked to the representative organ.
SAFe: Scaled Agile Framework is a framework for Business Agility. SAFe combines fundamental practices of Lean, Agile, and DevOps into a theoretical operating system that should help organizations in delivering innovative products and services faster, more predictably, and with higher quality.
SPARQL: “SPARQL Protocol and RDF Query Language”, enables users to query information from databases or any data source that can be mapped to RDF. The SPARQL standard is designed and endorsed by the W3C and helps users and developers focus on what they would like to know instead of how a database is organized.
SSU Reporting: Solution Stand-Up Reporting is a biweekly meeting, every first Monday of a sprint, where the product manager and product owners of the various products meet with the members of the Solution Management Team to report on the progress made during the previous sprint in realizing sprint/ spurt objectives and returning value for the organization.
VDOM: a Virtual document object model that is used in the rdfa-editor as a programming concept where an ideal, or “virtual”, representation of a UI is kept in memory and synced with the “real” DOM by a library.
VIP: Vastgoed Informatie Platform or The Property Information Platform is an initiative of the municipalities, in collaboration with VVSG, the real estate sector (CIB & FedNot) and the Flemish Government. Digital Flanders is responsible for the development of the platform and operational management. The aim of VIP is to become a digital portal where the applicant for real estate information can request the necessary data in the context of a sale or long-term rental in one simple way. The platform then collects all data from the available, connected sources (central registers & municipalities).
VLOCA: Vlaamse Open City Architectuur/ Flemish Open City Architecture is a trajectory that offers an initiator of a city project a standardized approach in establishing the architectural elements of an open city project. VLOCA's standardized approach and deliverables ensure that every open city project is formed in the same way, can benefit from each other's achievements and ultimately results in an optimally interoperable solution throughout Flanders.
BRM: the Backlog Refinement Meeting is a get together of the product team (scum team, product owner, scrum master and product manager eventually) to refine the backlog as a preparation for an upcoming sprint. More information on the BRM is to be found .
LDB: Leidinggevenden DataBank/ Executives Database is a repository that is maintained by the local authorities . It contains (contact)information of persons maintaining executive positions at the local authorities.
MDB: Mandatendatabank / Mandates database is a repository containing contact details of persons who hold leadership positions in Municipalities, Districts, Provinces and OCMW's. Local authorities maintain the data of the mandatees .
The SAFe framework consists of multiple roles. On this page you will find a description of most of the roles defined at Digiteam ABB.
A Product team consists of a Product Owner, Scrum Master and a delivery team. Using Scrum the product team delivers functionality and solutions within the existing cadence.
Product teams have all necessary skills to develiver value each and every sprint. They are multidisciplinary. Next to that scrum teams are self-steering and mutually determine who takes up which parts.
The Product Owner translates the product vision (always focused on the customer experience) into functional actions and with the purpose, together with business experts and IT-colleagues, to arrive at processes, services and applications that meet customer needs and deliver value within the value streams of ABB. This is done according to the agreed standards in terms of time, quality and costs.
partners with the Product Manager;
translates the vision on the product into functional actions in order to saveguard the objectives;
stimulates the team to define 'quality' stories and to prioritize the backlog;
maximizes value for the stakeholders together with the product team;
ensures that what is delivered matches the needs of the stakeholders;
retrieves valuable information inside and outside of the organization and builds up stable internal and external networks for this;
applies the techniques of agile product management and business analysis according to the established quality requirements and procedures;
The development team is multi disciplinary and therefore consists not only of developers but also designers, analysts, architects and testers. These are often not exclusively allocated to one product at Digiteam ABB.
The Product Manager defines on a strategic level the vision for the customers on a product with the aim of translating this vision into a roadmap for the product and solutions. This is done in line with the agreed standards in terms of time, quality and costs.
works closely with a wide range of people to identify stakeholder needs and understand the solution context;
encourages and organizes collaboration within the team so that the product creates value for stakeholders;
develops a vision for the product, draws up a roadmap and translates it into solutions that the team continues to work on;
demonstrates how a solution positively impacts a value stream and thus can provide value for internal and external customers;
opens up new areas for which the product can deliver value;
identifies and contacts potential users and integration partners;
works in tandem with the Product Owner who translates the vision into concrete epics and stories for the product team;
(optional) a PM can also be responsible for a solution that involves more than his/her product.
The product manager cannot work out and determine the solutions on the product roadmap on his or her own. He or she can call on a business analyst for this, who will work out the best business solution together with others (designers, architects, product owner) using a methodology and a set of tools.
The business analyst therefore helps to translate the high-level solution into epics in which the best possible implementation of the solution on the product roadmap is plotted out so that it can be implemented and - after delivery - also realizes the predetermined value.
Once the 'business problem statement' has been well understood and the most suitable solution has been documented, the business analyst offers further support during the writing and updating of the epics so that they can be (technically) implemented and subsequently meet the expected objectives.
In order to stimulate knowledge sharing about and consistency in, for example, the techniques used, Communities of Practices are periodically organized by the (Solution)Train Engineer. A COP takes place around a certain role in the operation or specific competences. During these meetings, examples are shared, new techniques are taught or even new practices are developed.
Monitors the effective value realization from solutions by
clarifing the potential of solutions based on input from other stakeholders. For example by using value tokens, solution tokens & impact maps;
stimulating and supporting contact between project team and (end) users;
launching solutions inside and outside ABB.
The train Engineer ensures that the necessary process and technical coordination (between products) takes place and even encourages this. Ideally, this starts from the roadmap and the value streams.
In addition, the train conductor supervises the learning and continuous improvement of the SAFe operation. This both within the Project Team and more broadly throughout ABB.
works closely with the Product Owners and Product Managers to encourage and guide alignment;
ensures that the value streams and roadmap are up-to-date and known;
organizes and facilitates important consultation moments (Central Planning Day, Communities of Practices, Solution Stand-ups);
organizes periodic retrospectives and ensures that improvements based on the insights come about;
provides support and 'first aid' on Agile working from product to solution level.
The Digital Solutions manager incorporates solutions in the Solution Roadmap. Coordinates information, resources and capacity so that solutions can be developed.
The ICT architect determines the architectural roadmap and technology strategy. Within this framework, it monitors the best fit of solution with technology.
The ICT director brings in possible value questions from the organization and monitors the strategic alignment.
Linked minutes also shows software vendors how to comply with the decree obligations.
Support Linked Decision Making Gelinkt Notuleren aims to support decision making, but does not exist to disrupt the market.
The functionalities we offer exist to enable linked decision making
is a complete overview of the current members of the product teams.
is a complete overview of the current members of the Solution level at ABB Digiteam.
Gelinkt Notuleren gives local governments the opportunity to [Dutch] - even if they do not have a software vendor, or work with a software vendor that cannot meet the decree obligation to use open standards. Linked minutes also shows software vendors how to [Dutch].
Find the functionalities here:
Read about how they work:
As a team we work day to day to strengthen our democracy by actively informing and involving citizens and business in (local) descision making. Furtermore we strive to simplify digital services through maintaining and reusing information efficiently through a single digital entry.
Read more about this in the document below describing our vision and mission, about our values as an organization:
or listen to Veronique and Pieter talking about our vision and mission as a team:
At Digiteam ABB - even more than before the pandemic - we work very efficiently and effectively (together) remotely. All Agile sprint and spurt rituals associated with our result-oriented SAFE operation remain digital. Inside and outside meetings, there is plenty of room and trust for social interaction. Working time/ Availability has never been an issue: everyone is there when needed or has made agreements to cover any absence.
Although there is little or no work content that requires this, several team members indicate that it is desirable to see each other in a physical way at regular time intervals, e.g. to have lunch or drink coffee together, to talk to each other in a different environment than home, .. However, it turns out that it is not easy to meet each other if everyone is present at the workplace at different times. Moreover since the start of the pandemic our teams have grown significantly, which means that a complete return to the situation before the pandemic is not entirely feasible.
To ensure that we meet each other more easily, we plotted out the following agreements:
We try - as much as possible - to be in Brussels on Mondays and in Ghent on Fridays.
At least on the Monday of the biweekly sprint reporting, we block space in our agendas to eat or drink coffee together.
At first we want to test this with the product managers and product owners, analysts, the members of the solution team and other colleagues who work across the products. When developers, designers and testers need physical presence and interaction, they are of course also very welcome to join in on those days. Of course, this does not prohibits any additional or other arrangements within each product team.
We realize that people can be less productive on days when they are on the road. We are aware of the impact this has on the results and stress level of individual colleagues. Open feedback is an important value within our team and that applies here too: talking about it helps to keep mutual expectations sharp.
This section describes the acceptance criteria we try to establish for work delivered by the product teams
Acceptance criteria help to form a boundary that assists product team members to understand what is included and what is excluded from the scope of a particular product feature (epic) or a user story that belongs to an epic.
1. An acceptance criterion should always be written from a user’s perspective. It should be written anytime before the epic or user story is assumed as ready to enter the sprint planning.
2. Each acceptance criterion must be independently testable and thus have a clear pass or fail scenarios.
3. Acceptance criteria should entail both functional and non-functional criteria.
4. Acceptanc criteria can be formulated as check list items (rule oriented) or using Given/When/Then (scenario oriented)
We call the acceptance criteria for epics the Definition of Done. They entail all the criteria that must be met before an epic (product feature) can be considered done and ready for release. Typically they consist of functional checks used by testers and business spocs to validate that the epic meets the requirements and will deliver the value we attach to it. Next to that it also contains a list of non-functional items that need to be in place before closing the epic: e.g. monitoring in place, reporting logs enabled, performance checked, code documented, impact on existing (other) features checked, ...
Acceptance criteria for user stories are smaller in size and scoped to the content of the user story. Any generic/ non-functional acceptance criteria that matter for one or more stories can be grouped under the epic acceptance criteria and can be referred to in the user story acceptance criteria. They should be good enough to test and validate the story itself. Below are a couple of examples found on the internet that illustrate 2 ways of recoring acceptance criteria on user story level.
Minutes are generally not completed during the session, but processed asynchronously.
The context in which the agenda items are handled can now be provided.
For each agenda item the attendees, the votes and the decision are entered. Multiple votes can be held per agenda item.
Our manual gives a clear view on how GN works [Dutch].
It is important that each department and all secretarial staff have the role Writer here. This is set on the Gebruikersbeheer (User Management – ACM-IDM), usually by the IT service of the local government.
Readers
can view all agenda items.
Writers
can view and edit all agenda items.
In Gelinkt Notuleren, files can be prepared in the Agendapunten (Agenda Items) tab. It is also possible to create a session directly and add agenda items there - but this is less flexible.
From the moment an agenda item is agendized and linked to a session, the agenda item will have its geagendeerd (planned)
status added to it, and you won't be able to add it to any other session.
Agenda items that were adjourned can be copied so they do not have to be rebuilt.
Part
Information
Linked information
To be published in:
Start date
The day the session went ahead.
Yes
Minutes, excerpts
Start time
When the session was started by the chair(wo)man.
Yes
Minutes, decision list, excerpts
Attendees session
Who was present at the start of the session.
Yes
Minutes, decision list, excerpts
Absentees session
Who was absent at the start of the session.
Yes
Minutes, decision list, excerpts
President (or replacement)
Who assumed the role of chairman of the council.
Yes
Minutes, decision list, excerpts
Secretary (or replacement)
Who assumed the role of secretary of the council.
Yes
Minutes, decision list, excerpts
Part
Information
Linked information
To be published in
Attendees agenda item
Who was present for the agenda item.
Yes
Minutes, excerpts
Absentees agenda item
Who was absent for the agenda item.
Yes
Minutes, excerpts
Disclosure of agenda item
The actual treatment of the agenda item: public or closed.
Yes
Minutes, excerpts
Subject vote
What is the vote about?
Yes
Minutes, decision list, excerpts
Type of vote
Secret or open.
Yes
Minutes, decision list, excerpts
Proponents
Number of proponents: numbers only if it's a secret vote, name of the attendee also if open.
Yes
Minutes, decision list, excerpts
Opponents
Number of opponents: numbers only if it's a secret vote, name of the attendee also if open.
Yes
Minutes, decision list, excerpts
Abstainers
Number of abstainers: numbers only if it's a secret vote, name of the attendee also if open.
Yes
Minutes, decision list, excerpts
Result of a vote
What is the consequence of this vote.
Yes
Minutes, decision list, excerpts
Closure of the session
When did the chair(wo)man close the session
Yes
Minutes
How does a session go, and how do we support it?
Both the agenda, decision list, minutes and excerpts should be signed.
One can sign digitally via Linked Notification. Signing is done based on the identity of the authorised persons. These individuals log in via ACM-IDM, and can then be signed simply by clicking "sign".
Certain documents are required to be published and/or reported: https://lokaalbestuur.vlaanderen.be/werking-bestuur/bekendmakingsplicht [Dutch]
There are different deadlines for each document here:
Agenda: publication 8 days before the session
Decision list: publication and notification 10 days after the meeting
Minutes: publication and notification after approval at the next meeting.
Depending on the type of decision, other agenda items are published and reported separately. These have different deadlines.
One can publish and report without signing. It is important that the board does have a signed version available to be legally compliant.
Our manual gives a clear view on how GN works [Dutch].
The draft agenda, supplemental agenda, and urgent agenda are published linked through the software vendor (such as Gelinkt Notuleren, for example) and are posted on the website. When published through GN, it lands on the publishing environment. Local governments can link to this page.
Reporting can be done automatically through a vendor, semi-automatically through gelinkt Notuleren (with a review in Box office for Local Governments/Loket voor Lokale Besturen) or manually through Box office for Local Governments (Loket voor Lokale Besturen).
Subtitles available in player.
At the next session, the minutes from the previous session are approved (or the session after, if there are still adjustments to be made).
There are certain documents, such as environmental permits, that can be delivered to certain parties even before the minutes are approved. It is possible to sign, publish and report these separately.
This can also be explicitly printed out in Gelinkt Notuleren.
After the agenda items have been prepared, they are delivered to the secretary's office to be added to the agenda. The agenda is generally prepared by a member of the secretarial staff and/or the managing director. Then it is checked and completed by the general manager.
*This is not an official term. This term is used here to refer to the process.
The draft agenda is communicated to the council before the meeting and published to for citizens. This agenda may still be modified.
Councillors may still submit agenda items up to a few days before the meeting. This will then be re-communicated and published as a supplemental agenda.
Up until just before the meeting, board members can still submit agenda items. The urgent agenda is also communicated and published as a supplementary agenda.
The draft agenda, supplemental agenda and emergency agenda are communicated to council members. This is generally done by a member of the secretarial staff or general manager, via the software package or by mail. Digital communication is encouraged.
The draft agenda, supplemental agenda, and urgent agenda are published linked through the software vendor (such as Gelinkt Notuleren, for example) and are posted on the website. When published via GN, it arrives on a publishing environment such as that of Linked Noticing. Boards can link to this page from their website.
Our manual gives a clear view on how GN works [Dutch].
For agenda setting, you need the role writer
.
Through Gelinkt Notuleren, the people who do not need writing privileges, but do review the agenda, can use the role reader
to view the agenda items that have been put on the agenda.
Within Gelinkt Notuleren, you create an agenda within a session - so it must be created first. You fill in the information from the session that you have available in advance:
After that, the agenda items that were prepared are added to the session.
First, the agenda item is linked to the session. Then a title and description (optional) are added to the session for that agenda item. This title and description are used when publishing the agendas.
This title and description may differ from the title and description of the agenda item itself. The title in the agenda item itself is used in the decision list, minutes and excerpts.
From the moment an agenda item is agendized and linked to a session, the agenda item will have its geagendeerd (planned)
status added to it, and you won't be able to add it to any other session.
A local government prepares agenda items - also called dossiers or draft decisions - separately. This is done by the assigned department(s) within that local government. It also happens that employees of the secretariat prepare agenda items that do not require specific knowledge, such as the approval of the minutes of the previous meeting.
The agenda items are prepared for various governing bodies. In the application you log in as an employee of a Municipality, Autonomous Municipal Corporation or Province.
Municipality (Gemeente)
City Council (Gemeenteraad)
Municipal College (CBS – College Burgemeester & Schepenen)
Mayor Autonomous (Burgemeester)
Autonomous Municipal Corporation (AGB – Autonoom Gemeentebedrijf)
OCMW
Special Committee (Bijzonder comité)
Permanent Office (Vast Bureau)
Province (Provincie)
Provincial Council (Provincieraad)
Deputation (Deputatie)
Autonomous Provincial Administration (APB – Autonoom Provinciebedrijf)
Our manual gives a clear view on how GN works [Dutch].
Reader
can view all agenda items.
Writer
can view and edit all agenda items.
In Gelinkt Notuleren, files can be prepared in the Agendapunten (Agenda Items) tab. It is also possible to create a session directly and add agenda items there - but that is less flexible.
Agenda items that were adjourned can be copied so they do not have to be rebuilt.
There are 3 statuses
Concept (Draft)
The agenda item is in preparation, but has not yet been linked to a session. The agenda item can be modified at any time.
Geagendeerd (Planned)
The item has been included in a preparation for a meeting. The agenda may still change, and the agenda item may be modified.
Gepubliceerd (Published)
The event has been linked to a meeting and has been published. The item cannot be modified anymore.
At this stage only Concept
is applicable.
Whenever you start a new agenda item, you start with one of 2 generic templates: decisions (with an optional vote) and free text. Examples of agenda items:
Decisions
Approving of minutes of the last session
Regulations
Announcements
Free text
Discussion points
Varia
We offer 2 styles for decisions:
New style: uses headings to separate authorities, legal context and rationale. Some boards use additional headings, but we make no further distinction here.
Classic style: use "gelet op (considering)" and "overwegende dat (whereas)" to separate legal context and rationale.
Roles It is important that each department and all secretarial staff have the role Writer
here. This is set on the , usually by the IT service of the local government.
Part
Information
Linked information
To be published in
Governing Body
For which body was this session scheduled.
Yes
Agenda
Planned date
The day on which the hearing is scheduled.
Yes
Agenda
Planned hour
When the session was scheduled to begin.
Yes
Agenda
Location
Where will the session take place.
Not yet
/
Part
Information
Linked information
To be published in
Public title (in session, for agenda)
This title is used when publishing the agenda.
Yes
Agenda
Brief public description (in session, for agenda)
Can give more information about the decision. Not every board does this, some copy the title. Used when publishing the agenda
Yes
Agenda
Planned disclosure
The expectation on which the agenda item will be handled: public or closed.
Yes
Agenda
Part | Information | Linked information | To be published in |
Public title (in agenda item itself) | This title is used when publishing the extracts, minutes and decision lists. | Yes | Uittreksels, notulen, besluitenlijst |
Brief public description (in agenda item itself) | Can give more information about the decision. Not every board does this, some copy the title. Used when publishing the excerpts, minutes and decision lists | Yes | Excerpts, minutes, decision list |
Governing Body | What governing body is this about? | No | Minutes |
Authorities | Through the citation plugin, the board enters the legal basis that determines that the body has jurisdiction. | Yes | Minutes, excerpts |
Legal context | Through the citation plugin, the board enters the legal contexts that are related. | Yes | Minutes, excerpts |
Rationale | The board submits the justifications. | No | Minutes, excerpts |
Decision | The decision consists of one or more article(s). | Yes | Minutes, excerpts |
Articles | An item consists of an item number and its contents. | Yes | Minutes, excerpts |
Article number | Sequential numbers. | Yes | Minutes, excerpts |
Article content | Content | Yes | Minutes, excerpts |
Secretarial staff / Medewerkers van de secretarie Perform administrative work for the public organisation, such as the municipality or public social welfare center.
General Manager / Algemeen directeur The general manager is responsible for the general and coordinating management of the services of the municipality and of the public center for social welfare. The general director, together with his staff, realizes the decreed and legally prescribed tasks and policy objectives.
Agenda item in draft / draft decision / Agendapunt in concept / ontwerpbesluit A draft (possibly to be added to or modified) of the resolution that would result from this agenda item.
Internal agenda / Interne agenda An agenda (possibly to be added to or modified), which can be reviewed internally.
Draft agenda / Ontwerpagenda An agenda (possibly to be added to or modified), which can be reviewed internally.
Additional agenda / Aanvullende agenda The draft agenda may be revised after publication. After revision, it will be republished as a supplementary agenda. It may also be supplemented.
Urgent agenda / Spoedeisende agenda Agenda with items introduced by the council until just before the meeting.
Under construction
Contribute to our code here:
Discover how we develop our app under DEVELOPMENT > Architecture.
To take full advantage of our applications, please use Firefox or Chrome.
However, it is possible that certain functionalities do not work as they should. Should you notice this, you can always let us know via: DigitaalABB@vlaanderen.be.
Our applications are provided for you to sign in securely through Gebruikersbeheer Vlaanderen.
To access our applications, you must be known as a user in Gebruikersbeheer Vlaanderen.
The local administrator who is on each board can give you access to this. Usually this is the secretary/general manager, clerk or someone designated by the organization. So it's best to check with them if you don't know who your local administrator is. More information about user management.
Signing up is done through the familiar user management Flanders.
All of our applications have a blue button with "Sign Up" on their landing page. Click on this button to continue. View all web applications of the Domestic Administration Agency.
A pop-up will then appear, presenting you with some secure options to sign in with.
If you have access to administrative units, the pop-up will give you the option to choose one.
Make sure your browser settings are correct.
Firefox Visit this link https://support.mozilla.org/en-US/kb/pop-blocker-settings-exceptions-troubleshooting#w_pop-up-blocker-settings and choose Pop-up blocker settings.
Chrome Visit this link https://support.google.com/chrome/answer/95472?co=GENIE.Platform%3DDesktop&hl=en.
Not getting access to the application? Go to Gebruikersbeheer Vlaanderen for more information.
After choosing an administrative unit, you are logged in. You will now have access to the modules you are known for in Gebruikersbeheer.
To access most of ABB's applications, you must have been granted the necessary access rights through user and access management.
Access rights are granted by the local administrator who is on each board. Usually this is the secretary/general manager, clerk or someone designated by the organization. So it is best to check with them if you do not know who your local administrator is.
To assign rights to users as a local administrator, visit https://vo-gebruikersbeheer.vlaanderen.be. Learn more at https://overheid.vlaanderen.be/ict/ict-diensten/gebruikersbeheer.
Sign in using your preferred sign-in system:
Next, choose the appropriate target audience, and the board you want to apply to.
Click "snel rechten toekennen" to start.
You will see an overview, where you can search for the right person.
Then you can look for the appropriate entitlements for the selected person. Depending on the application you choose, it will be a different right.
Gelinkt Notuleren: choose Gelinkt Notuleren
Loket Lokaal Bestuur: choose Loket voor Lokale Besturen
Organisatieportaal: choose ABB OrganisatiePortaal Gebruiker
Depending on the application you chose, you can now assign roles or contexts to the person you granted access to.
You can give a user the right to perform or not perform certain actions based on roles. A user can be given rights for multiple roles.
Lezer (reader)
Ondertekenaar (signature authority)
Publiceerder (publisher)
Schrijver (writer)
Beheerder (administrator)
Editeerder (editor)
Lezer (reader)
You can grant or deny a user access to certain parts of the application using contexts.
Once a user has access to a particular context, this user can perform all actions for the associated components. A user can be granted rights to multiple contexts.
Voorbeeld van 7 contexten voor Loket Lokaal Bestuur:
Context Gebruiker Mijn Toezicht: recht op onderdeel toezicht.
Context Gebruiker Berichtencentrum: recht op onderdeel berichtencentrum.
Context Gebruiker BBC DR: recht op onderdeel BBC-DR.
Context Gebruiker Mandatenbeheer: recht op onderdeel mandatenbeheer.
Context Gebruiker Leidinggevendenbeheer: recht op onderdeel leidinggevendenbeheer.
Context Gebruiker Personeelsbeheer: recht op onderdeel personeelsbeheer.
Context Gebruiker Subsidies: recht op onderdeel subsidiebeheer.
Also provide a reason for granting the right.
You will be asked to confirm the assignment of permissions, after which a message will appear if the process was completed successfully.
The person can now sign in with the assigned roles or contexts for the chosen application.
This section gives insight in how the scrum teams at Digiteam ABB use Jira.
Since we use Jira quite extensively now, we have decided to create a manual on how we use Jira at ABB Digiteam. Therefore this section now points to the Jira manual section which can be found in the Tooling Space of the ABB Gitbook (members only). Under this space all relevant tool manuals are being maintained.
You can log off or switch administrative units* by clicking on your administrative unit in the top right corner.
*Switching administrative units is only possible for specific applications, and only if you have access to multiple administrative units.
When clicking "Wissel van bestuurseenheid" you will once more see the pop-up where you first select that you want to apply for a local administration or municipality. Make sure your browser allows this pop-up as well. See how to allow popups.
Now pick the correct Administrative Unit.
Welcome to the general technical overview.
The purpose of this section is to help new collaborators get started more efficiently and while experiencing less stress. It serves as a technical 'start here' guide and it provides links to other, more detailed, documentation. We hope that this guide will allow new hires to start developing applications for ABB quicker. It's very important to understand the contents of the tickets.
These docs are meant for several types of collaborators:
Developers: New developers need to learn the structure they are getting into: technically and organizationally. In this case it's of crucial importance to maintain a correct nomological structure (conceptual landscape) in mind and this guide should help build that.
Analysts and PM's: In order to reason about ABB's applications and services new analysts and PM's need to understand the major organs that animate the bodies of our applications without going too deep into the microbiology of them. These readers will benefit particularly from the introduction section of this guide and are encouraged read the other sections out of personal interest.
These docs do NOT contain information concerning the following topics:
Organigram of ABB (you should know which people to ask)
Procedures for JIRA (ABB's issue tracking system of choice)
Procedures for software release management and testing
SCRUM related information (sprints, epics, growth spurts, issue types, ...)
ABB specific and recurring meetups (central planning day, BRM, Retrospective, standups, ...)
If you're interested in these topics you'll have to look at other sections in GitBook. These guides are meant to be (high level) technical. Please have fun reading them. Make sure not to follow too many links on your first read through because you'll get a terminal case of 'TMI' (Too much information). My recommendation is to read the docs once without following links and then doing another pass. During the second pass you can follow links concerning subjects your are particularly interested in.
If you've got any suggestions or comments please contact Mr. Dries Beheydt. The mu-semtech architecture was developed by Redpencil. The author of these guides is Dennis Van Eecke which can also be contacted using Rocket Chat.
These are the major sections of the guide:
Now let's get to the business of how to make ABB apps shall we?
A list of all relevant links for each product can be found here, to make working cross-product easier.
A list of all relevant links for each product can be found here, to make working cross-product easier.
Each product and service has their own manual, but signing up and user management is the same for most products. There is a separate manual that explains how to sign up and manage users.
You can ask product managers how to access development environments.
Front-end https://github.com/lblod/frontend-gelinkt-notuleren
Gebruikerssessies: https://gebruikerssessie.gelinkt-notuleren.lblod.info/login Development: https://dev.gelinkt-notuleren.lblod.info/login
Citatenplugin (link naar de Vlaamse Codex in notulen) https://github.com/lblod/ember-rdfa-editor-citaten-plugin
Gebruikerssessies: https://publicatie.gebruikerssessie.gelinkt-notuleren.lblod.info/ Development: https://publicatie.dev.gelinkt-notuleren.lblod.info/
De editor die in Gelinkt Notuleren ingeladen wordt https://github.com/lblod/ember-rdfa-editor
Front-end https://github.com/lblod/frontend-loket
Back-end https://github.com/lblod/app-toezicht-abb Front-end https://github.com/lblod/frontend-toezicht-abb
Quality Assurance https://qa.toegankelijk.vlaanderen.be/ Quality Assurance intern: https://qa.toevla.org/ Development: https://dev.toevla.org/
Development: https://dev.organisaties.abb.lblod.info Quality Assurance: https://organisaties.abb.lblod.info
Front-end: https://github.com/lblod/frontend-organization-portal Back-end: https://github.com/lblod/app-organization-portal More information: https://abb-vlaanderen.gitbook.io/doc-organisatieportaal/code
Front-end https://github.com/lblod/frontend-mandatendatabank
Front-end https://github.com/lblod/frontend-leidinggevenden-databank
The glossary above should help you build a correct nomological network in your head. In order to work effectively for ABB (to make apps at least) you should have knowledge of the following topics. I've included some links to existing docs with each one.
If you're a total beginner don't get lost by clicking too many links. They are here as a reference.
TCP/IP, HTTP, internet and web infrastructure is good to know
General development tools (IDE choice is your own):
Git
Github
JIRA
SSH in terminal
Web development: HTML, CSS, Javascript, JSON
Backend/full stack:
Lisp, Ruby and Elixir are also used in some cases. But this is not for beginners
Some basic knowledge concerning NGINX could come in handy as well as understanding of DNS, TLS, cryptography and certificates
Docker and micro services
Images, containers, networks, image repositories
As an analyst, PM or developer you'll need a basic understanding of some specific IT technologies before you can start developing apps. It possible to skip specific sections if you already possess the knowledge in question.
Assuming you are a part of the intended audience of this guide it will be your job to support the development of IT systems for ABB. ABB is an agency of the Flemish government associated with the policy domain of 'Kanselarij, Bestuur, Buitenlandse Zaken en Justitie'. A department led by a minister is associated with this policy domain as well as ABB and other agencies. ABB, like all agencies, must fulfill it's duty to the Flemish people by supporting the execution of policy. In particular ABB must enforce policies associated with the provision of means promoting social cohesion; especially in situations where people are very diverse. This also includes facilitating cohesion between local governments and citizens.
A mayor way to achieve this goal of policy execution is though information technology. And that's were you come in.
Will you do your part to help fulfill ABB's obligation to the Flemish population?
To make sure you have the knowledge to do a good job you need to learn the topics of this guide.
You might want to print this list because you will be returning back to it. Ideally you should study this and be able to explain all of the concepts in it. It will help you significantly with your work.
Vlaamse overheid (abbrev. 'VO', a.k.a. 'Flemish government'): The government of the Flemish region and the flemish community. Belgium has three regions: Brussels, Flanders and Wallonia. It also has three communities: Dutch, French and German. There is a federal government and each region as well as each community has its own government. This yields a total of 7 governments. The institutions of the Flemish region and the Flemish community fused into one: the Flemish government. This means that the Flemish government concerns itself with matters of both the region (w.r.t. territory) and the community (w.r.t. culture and education). It's headed by a prime minister and accountable to the Flemish parliament and the public administration. Because of the merger the total number of governments in Belgium is 6.
Beleid (en. 'Policy'): In a political context, policy refers to the plans, strategies, principles, and actions that a government or political entity employs to address societal issues, achieve goals, and guide decision-making. It encompasses the formulation, implementation, and evaluation of measures or regulations aimed at shaping social, economic, environmental, or other aspects of public life.
Beleidsdomein (en. 'Policy area): A policy area of the Flemish government is associated with a department and one or more agencies. It is associated with a major topic such as education or energy.
Departement (en. 'department'): The department takes care of the preparation of policy proposals and support of the policies. It operates on the direct supervision of a minister.
Agentschap (en. 'agency'): An agency is responsible for policy execution and has more autonomy compared to a department. ABB is an agency.
Gewest (en. 'region'): Belgium consist of three regions: Flanders, Brussels and Wallonia. They have a parlement and a government. It's authority concerns affairs related to territory.
Gemeenschap (en. 'community'): Belgium consists of three communities: Dutch, French and German. They have a parlement and a government. It's authority concerns affairs related to language and culture.
Digiteam: This is the name if the ICT services department within ABB.
Mandaat and mandataris (en. 'Mandate' and 'delegate'): A mandate is an official assignment that a delegate performs in service of Flemish citizens and on behalf of the government.
Overheidsdienst (short. FOD): General term for a service provided by the government. It also refers to an older term called 'ministries'. It's only relevant and unambiguous in the context of the federal government. Not the flemish one.
Bestuurseenheid (en. 'administrative unit'): Specific organization in Flanders which has some relation to government.
District: Cities and provinces may consist of multiple districts. City districts are cities or urban areas that constitute a separate administrative level instead of forming a district together with other municipalities. Smaller towns around such a city or urban area may be part of a city district. Provincial distrits are purely administration related and are relevant in the election of provincial delegates.
Provincie (en. 'province'): Administrative level associated with a part of the territory in Belgium. It has its own local government.
Gemeente (en. 'municipality'): Lowest administrative level in Belgium associated with one or more clustered area's populated by people. It has its own local government.
Stad (en. 'city'): Municipality in Belgium with a large number of inhabitants and which has been granted city status by royal decree.
Loket: Software application, specifically a web app, provided to local administrative units (e.g. municipal governments) so they can fulfill their obligation to the Flemish public. Especially w.r.t. the decree stating that Flemish institutions need to publish information in both human readable and electronic format.
Organisatie portaal (abbrev. 'OP'): Another web app developed by ABB. This particular system is used by collaborators within ABB itself in roder to manage records associated with organizations (administrative units).
IGS (full. 'Intergemeentelijke samenwerking' en. 'cross municipal collaboration') TODO
AGB (full. 'Autonoom gemeente bedrijf' en. 'autonomous municipal company') TODO
APB (full. 'Autonoom provincie bedrijf' en. 'autonomous provincial company') TODO
General knowledge applied to ABB. In my experience many people could do with a refresh of some general concepts before they dive into the docs. If you feel like skipping this section answer me this: Can you really explain how internet works? You kind of need to know this stuff before you start reasoning about and/or building internet applications.
Website: A website consists of HTML documents accessible using the browser. They may contain interactive features facilitated by a programming language called Javascript. Users generally interact with a website by clicking links to other pages. Each time a link is clicked another page is loaded. A web app (cf. 'App') is a little different than a website because in that case the Javascript functionality is used to make the website behave more than a desktop app (i.e. it comes with its own runtime). Meaning that clicking elements often do not cause a reload of the page. The spectrum between websites and apps is somewhat fuzzy. But in general one might say that wikipedia is a website and an online game in the browser is a web app. Some internet services have properties of both. The protocol used is to deliver websites on the request of a browser is TCP/IP. The application layer protocol on top of TCP is called HTTP.
HTTP (full. 'Hyper Text Transfer Protocol'): Application layer protocol based on text on top of TCP/IP. Therefore it has encoding. The default encoding is 'ISO-8859-1' (extended ASCII) but can be changed using a header. It's important to remember that this is a text based protocol so sending binary data over HTTP will require a binary encoding (such as base64). ABB uses JSON as a serialization format (not XML) for sending structured data over HTTP. Triples are sent using turtle, n-triples or n-quads. Naturally web pages are transferred using HTML. HTTP has a request format and a response format; both of which have headers. These headers inform the server (request) and the browser (response).
Server: A computer program which listens to incoming TCP requests and sends answers. A server is not a physical machine.
Web server: Server which implements the HTTP protocol
Server computer: A computer specialized for running server programs. It has to run continuously and therefore must be highly reliable. In many cases a single server computer may run multiple web servers at the same time. In other cases a physical computer may run a hypervisor as an OS and run multiple virtual machines which in turn run multiple processes. A special case is docker (cf. 'docker').
OS (full. Operating system): Computer software which manages compute resources such as memory and CPU time. Because of an OS multiple processes can run concurrently and reliably. In ABB's case the (virtual) machines which host the web services always use Linux as an OS. The versions of Linux do not come with a GUI but are controlled using a command terminal instead. You'll have to connect to these machines using SSH and be knowledgeable of the necessary commands which install software, start processes and many other things. Without basic knowledge of the linux operating system you will not be able to manage server computers effectively and/or deploy (new) ABB apps.
Virtual machine (short. VM): A compute resource that uses software instead of a physical computer to run programs and deploy apps. One or more virtual “guest” machines run on a physical “host” machine. Each virtual machine runs its own operating system and functions separately from the other VMs, even when they are all running on the same host. This means that, for example, a virtual MacOS virtual machine can run on a physical host PC with linux. As a user you may not even know if the machine you connect with is physical or virtual because you'll only interact with the OS (Linux in our case).
Docker: This is a set of products that provide 'OS level virtualization'. The 'docker engine' is a process that manages software packaged in containers. Each container behaves like a virtual machine in some way but it shares the kernel of the host machine running docker engine and is therefore more lightweight. Containers are useful because they package an OS, the process(es) you are interested in as well as any dependencies you might need. Thanks to docker you can run ubuntu linux hosting a node server in one container and alpine linux running an Elixir application at the same time. Docker allows ABB to package (parts of) apps more efficiently because the developers don't have to worry about installing any dependencies (specifically software libraries) on the host machine. Each ABB app uses docker to run a multitude of containers on a server computer.
Docker container: A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another. A container is associated with a docker image which provides everything the container needs to run. On a web server computer managed by ABB you will find many docker containers running at the same time. Try docker ps
in the terminal.
Docker compose: This is another product provided by docker which lets you manage a collection of containers. Thanks to docker compose you can start, stop and configure many containers all at the same time. The most important file which configures docker compose is called the docker compose file. This file gets interpreted and its instructions are followed in order to configure and start containers in the intended way. Any ABB app can be associated with a (substantial) docker compose file defining many different types of containers. All of these containers are associated with a single project name (for management) and a virtual network (so they can communicate with each other using IP).
Micro service: This is a term used for a process, often packaged in a docker container, that has a limited functionality and responsibility and is therefore considered 'small'. The term micro service is always used when multiple micro services operating together make up a higher order more complex system. The latter is said to have a microservice architecture. ABB's apps are microservice based systems and consists of many micro services packaged in containers which communicate with each other. The system of microservices has one 'endpoint' to connect with and acts as one single complex web server. The communication between microservices are hidden from the outside world.
Host: A network host is a computer or other device connected to a computer network. A host may work as a server offering information resources, services, and applications to users or other hosts on the network. Hosts are assigned at least one network address. In ABB hosts are always 'IP hosts' with an IP address. A 'host name' is assigned using DHCP and is especially relevant for CORS (Cross-origin resource sharing). The browser will set an origin header on the request and the server will send a 'Access-Control-Allow-Origin' header back. Based on the latter the browser can decide to process the response or not. 'Host' and 'hostname' tend to get confused with each other. Sometimes people mean 'hostname' when they say/write 'host'.
TLS, SSL and HTTPS: TLS means 'transport layer security' and can be regarded as an extra layer in the protocol stack providing encryption. SSL 'secure socket layer' is the name of an older and deprecated version of TLS. When adding TLS to HTTP the resulting protocol stack is called 'HTTPS' (HTTP secure). TLS will work for any protocol based on TCP/IP, not only text based protocols. TLS includes a handshake phase in the communication in which asymmetric encryption is used (public and private keys) to establish a shared secret (shared key). The handshake phase requires that the server provide a digital certificate (proving its authenticity) as well as its public key. ABB apps use a proxy server packaged in a microservice to handle HTTPS. This server uses letsencrypt to get certificates. The proxy server forwards the request without encryption to the ABB microservice based app. You'll find that ABB servers have a least two docker compose networks: one for the ABB app and one for letsencrypt. These networks need to be linked together so the proxy can forward to the ABB endpoint.
Programming language: General term for human readable language defining computer instructions. Programming languages can be either imperative (text defines HOW the computer should operate to get a result) or declarative (text defines WHAT computer should output). Functional programming languages are declarative and they allow the user to write programs using pure functions without describing the process flow. Elixir is a functional language for example and Javascript is multi-paradigm allowing for both imperative and 'functional' code.
Compiler: Program that converts programming language into instructions for a processor. This processor may be the actual processor (e.g. an Intel Xeon server processor) or a virtual one. The Java virtual machine or BEAM (Erlang virtual machine) are examples of virtual machines (not to be confused with an OS level VM). ABB uses Elixir in some microservices and this needs to be compiled to bytecode for the BEAM engine. A docker container and docker file takes care of all this for us. One of the most famous compiled languages are C and C++ but ABB does not use these languages.
Interpreter: Program that reads programming language as a text string and executes instructions directly on the processor. Interpreted programs tend to run slower because of this but are more flexible. Famous interpreted languages are Python and Ruby. Javascript is also an interpreted language but that one's a little bit special. Some ABB services use Ruby in which case the ruby interpreter is provided by the container image.
Javascript (short. 'JS'): This programming language is one of the core technologies of the web and shipped in text using HTTP alongside HTML. The browser executes Javascript code using a 'javascript engine' which is an interpreter and a JIT (just in time) compiler. Because of the JIT technology some sets of Javascript instructions can be run almost as fast as 'native' processor instructions. The most famous JS engines are Google's V8 and Firefox's Spidermonkey. NodeJS is a program that packages a javascript engine (V8) as well as the NodeJS runtime and OS interface. Thanks to NodeJS Javascript can run on a server and interact with the OS (e.g. writing files). ABB's front end web apps ship with lots of Javascript which get executed in the browser. On the back-end javascript is used for many microservices and runs in containers including NodeJS.
Runtime: (Simplified) The part of a program responsible for execution. Most programming languages have a specific runtime. ABB's front end framework, Ember, can be said to have a higher order runtime which uses Javascript.
REST API: The term 'REST API' (REST means 'representational state transfer') is used for a web API that does not require the server to keep the 'state' of the connection in memory. All the data the server needs to process any request should be in the request itself. Basisregisters is a REST API but most of the ABB API's associated with an ABB app are not because they require the 'server' (microservice system) to maintain a 'session'. This does not mean that REST API's can never require a login. It just means that the client will have to store the login credentials associated with the connection and send it along with each request.
Cookie:
Session: Data structure describing the state and relevant properties of of an interaction between server and client. Sessions are stored in the server. In ABB apps a data structure describing the session is stored in the database and is identified by an ID string. After a successful login the ABB backend sends back a session ID. In subsequent requests the session ID is attached to the requests as a HTTP header (the infamous MU-SESSION-ID
). Because of this the server knows which user has made the request so it can managed access control (it will not send data to users who are not allowed to see it). In some communication systems the session is used to store the progression (state) of the information exchanged. For ABB this is less relevant as the session is mostly used to store which user is logged in.
Database and linked data related knowledge:
Semantic web: An extension of the WWW through standards. The goal of this extension is to make (part of) the internet machine readable (linked data) as opposed to only human readable (HTML).
RDF (full. 'Resource Description Framework'): RDF is a data structure describing graphs consisting of nodes and edges/links. RDF models graphs as a series of triples (cf. triple below) which refer to sets of two or three symbols referenced by an unique string or URI. RDF is expressed in many formats; most of which are text based. Examples of ways to express RDF in a file (serialized) or over the network is the turtle format, n-triples, n-quads JSON-LD or RDF/XML. Using RDF hypothetically all human knowledge can be expressed and many other knowledge systems are built on top of RDF such as RDFS and OWL. Virtuoso is capable of reading files in all common serialization formats and inserting them in the database. The semantic web consists of servers serving knowledge graphs expressed in RDF. RDF graphs may contain links to other graphs and in this case the data can be considered 'linked'.
URI (full. 'Universal Resource Identifier'): Not to be confused with URL. URL's point to web pages and are ambiguous (two URL's can point to the same page). URI's only point to one and only one unique concept. An URI is always encoded in ASCII. IRI is a set of specifications to allow writing of URI's with unicode characters. Be cause this also applies to URL this can be confusing. But again. An URI is NOT an URL and does not have the same structure. URI's can be any string as long as they are guaranteed to be unique. Because internet domain names are registered and guaranteed to be unique an URL like structure if often used in URI's; hence the confusion. Dog
is a valid URI but it's not very likely to be unique. http://my-unique-domain-that-i-paid-for.com/ontology#Dog
is. It's also common, but not mandatory to make URI's valid URL's so they can be put in the address bar of the browser to get more human readable information concerning the specific concept.
Triple: Smallest and atomic part of a graph structure expressed as linked data. A triple is expressed in RDF and can be regarded as a sentence consisting of subject, predicate and object. These are three parts; hence the name. In common serialization formats triples are expressed as <subject-uri> <predicate-uri> <literal|object-uri>.
(Note the point). Subjects and predicates are always symbols referenced by a URI. The object can either be a symbol or a literal data value.
Triple store: A database or other storage system capable of storing or serving triples. Virtuoso, the database ABB apps use, is a graph database and a triple store.
Graph: This concept can be confusing because it can mean different things depending on the context. A graph is a mathematical construct consisting of nodes and edges. It's also, in this context, a collection of triples which form a graph like structure. Tables with records can be used to store data which models things in the real world and graphs as well. But graphs have a much higher capacity to model more complex things. Triple stores, like virtuoso, can store many graphs as a high level data structure not too dissimilar to a table in a relational database. In ABB apps we've got many different graphs and most queries specify in which graph triples should be searched for and selected. When no graph is mentioned in a query the database engine assumes you are lookin in the 'default graph'. Each graph is also identified by an URI.
SQL (full. 'structured query language'): Declarative language which can be used to express commands to retrieve, store, modify or delete data from a relational database. It can also be used to manage the database itself; i.e. create tables etc.
SPARQL (full. 'SPARQL Protocol and RDF Query Language'): Declarative language which can be used to express commands to retrieve, store, modify or delete data from an RDF based graph database. It can also be used to manage the database itself; i.e. create graphs etc.
N-triples and N-quads: N-triples is a text based file serialization format that can be used to store triples as tekst in a file. Each new line in an n-triples file contains a triple expressed as <subject-uri> <predicate-uri> <literal|object-uri>.
A common file extension for these files is .nt
. N-quads (file extension .nq
) is exactly the same except there are 4 elements in each new line: the first being the URI of the graph the triple belongs to and the last three making up the triple itself. Because of this an n-triple file can only be ingested by virtuoso if you specify which graph the triples should be put in. If you don't virtuoso will insert them into the default graph. N-quads file contain graph information so virtuosos can process these without graph related parameterization. Both n-triples and n-quads can serve as a format to be put on the wire and sent using HTTP as it's a text based standard. It's important to point out that this format is highly verbose and inefficient and can benefit very, very greatly from compression ('zipping').
In 2018 the Flemish government issued a specifying that local governments have to share their information with the public. Without going into detail: local governments need to share information about local decisions, regulations and many other things electronically in the format of linked data. This is why ABB develops applications to help local governments adhere to this decree. ABB also does many other things but making these applications is the principal task for development teams of which you are a part.
ABB (full. 'Agentschap Binnenlands bestuur'): ABB is an agency of the Flemish government. It's associated policy area is 'Kanselarij, Bestuur, Buitenlandse Zaken en Justitie'. The department is called 'Department kanselarij en buitenlandse zaken'. It responsibilities are related to the provision of means which promote social cohesion; especially in situations where people are very diverse. This also includes facilitating cohesion between local governments and citizens. .
LBLOD (full. 'Lokale Besluiten als geLinkte Open Data'): This is an ecosystem of open (as in 'open source') standards and systems related to information provision and sharing. This information, or 'data' is expressed as linked data. The software systems ABB provides for local governments and for the general public to fulfill its mission are a part of this ecosystem.
App: A general term for a computer program with a user facing component. Because ABB publishes apps using the internet 'app' really means 'web app'. A web app consists of a user facing part using web technology and associated systems running on a (web) server. Because the front-end part looks and feels like a desktop application the name 'app' is more suitable as opposed to a website. This is an example of an app ABB has recently released: .
Docker image: This is a definition of all the necessary software and files, including the OS, that makes up a container. You can download docker images from repositories such as . ABB publishes many different types of images on docker hub. From these images containers can be started.
API (full. 'Application programming interface'): A catalog of functions to call and execute. API's exist on many levels. Some API's consist of the functions exposed by a software library (e.g. Nvidia CUDA is an API which allows programs to interact with an Nvidia GPU) and others consist of HTTP endpoints (a 'web API' in this case). In most cases technical writers mean 'web API' when they use the term 'API'. Of some of ABB's microservices it can be said they expose a 'web API' and many utilize web API's from other (public) services such as the provided by the Flemish government.
URL (full 'Universal Resource Locator'): A text string encoded in ASCII pointing to a resource on the web (something to connect with using HTTP). Because ASCII is a small symbol set a higher order encoding is used called 'percent encoding' so one can encode control characters and non-ASCII characters (e.g. Japanese). An 'IRI' (international resource identifier) is a set of specifications that allow for URL's with unicode characters. It also applies to URI's which can be confusing. IRI often confused with URL. Common URL's consist of these parts: <protocol>://<hostname><path>?<query>#<fragment>
. ( are possible). This means that the 'hostname' does not end with a slash and may be a registered name or an IP address. The path begins with a slash. For example: https://lokaalbeslist.vlaanderen.be/agendapunten
has lokaalbeslist.vlaanderen.be
as the hostname and /agendapunten
as the path. Don't forget the slash and don't confuse the URL paths with a file path in your OS. They are different things entirely.
Database: Specialized computer program to store and retrieve data using the computer's memory and persistent storage. Relational databases store data in table and can be queried using SQL. Graph databases store data in graphs containing nodes and links. Linked data databases are graph databases which operate using linked data and can be queried using SPARQL. ABB uses as its database of choice. It is deployed with ABB apps (which use the mu-semtech framework) in container form.
Linked data: According to : The term Linked Data refers to a set of best practices for publishing structured data on the Web. The principles are: Use URI's to name things, provide useful data when someone request information concerning a specific URI and include links to other URI's.
The model below provides a bird eye view on the Semantic Architectural Runway at Digiteam ABB. The components below will be further elaborated on in the subchapters of this section.
A presentation of this mental model was recorded on November 6 2023 and is embedded below.
Presentation:
Recording:
Building Applications with Linked Data & Microservices
An application framework to build web applications that run on linked data, aware of micro services.
User facing microservices
Deploy with Docker
Single page apps with Ember.js
Standard requirements: HTTP, JSON, SPARQL
The project
Bootstrap a mu.semte.ch microservices environment in three easy steps.
No video available, but you can discover more in the full presentation below.
Mu-semtech minimal setup and data pipeline overview
Ember data preview and concepts (adapter and serializer, ORM, JSON:API)
Dispatcher
Resource
Authorization a.k.a. 'database'
Virtuoso, public and organization graphs
Frontend general concepts. Web app versus website
Ember overview
Ember data overview
More on data binding and reactivity
Appuniversum
Ember versions and build chain
Deployment of front-ends
Read about Linked Open Data for Local Authorities to understand why we are using this technology!
Session general considerations (i.e. Users, groups, accounts, role)
Mu-semtech login service and mock login
ACM/IDM and general considerations of identity providers
ACM/IDM high level technical operation
More on authorization and delta mechanism (i.e. delta-notifier)
Job controller, background job initiator
Synchronization general description
Production mechanism for other apps
Consuming data from other apps
(Perhaps more specific information for PM's?)
We are required to follow the branding of the Flemish Government. They have extensive and transparent guidelines (colours, logo, fonts, ...)
Guidelines provided in Dutch. Get in touch if you would like to have more information in English.
We do use a different set of icons, because of 2 reasons:
We build applications. The size is different, which influences the legibility of the current icon set.
We have created custom icons for some applications like Toegankelijk Vlaanderen.
There are also specific guidelines for digital house style, which differ slightly from the general guidelines. In Dutch. Get in touch for more information in English.
All the applications and websites we publish must be accessible, according to the WCAG 2.1 guidelines.
Guide proviced in Dutch. Get in touch if you would like more information in English.
We currently do not use the global header & footer; for tracking and speed reasons.
Header: To integrate smoothly with our codebase and increase speed, we recreated the header in Ember. It appears anytime, anywhere.
Footer: The footer has also been recreated. We only use it on log-in pages, because our application patterns are different.
We are currently using a mix of clickable prototypes in Figma, and real prototypes in HTML and CSS. We are also working with other departments to build a solid component library here, both in vectors (Figma) and HTML and CSS.
We use Figma, but we do not have a license yet. This is a discussion in progress.
In the meantime, we can base ourselves on the Figma library Mono Company created for creating apps for the Flemish Government.
The Flemish Government has built a web component library. We are not currently using it:
In its current form, the 3.0 version, this library is available when we use their Web platform. Within our application architecture, we do not use that Web platform, and therefore cannot use the Web component library.
The 3.0 version is not open source. We create open source applications, and thus need open source solution. Our applications are based on their Web components, an older version, when they were still published open source.
To build our applications with, we created an open source component library.
The library is based on the old web components of the Flemish Government, version 2.0. This is where we built our applications with in the beginning, when they were still published open source. To make sure we could fix bugs, extend the library for specific application components and publish our applications open source, we created Appuniversum. Anyone who wishes to use this library, more specifically in the context of projects for the Flemish Government, may do so.
This component library currently consists of two parts: Appuniversum & Ember-Appuniversum.
Deze handleiding zal uitleggen hoe analisten/developers/product managers/... feedback kunnen geven op mockups via comments op Figma.
Met een muis: Om te navigeren tussen de verschillen schermen moet je spatie en rechter muisknop tegelijk ingedrukt houden en je muis bewegen.
Met een trackpad: Als je een trackpad hebt, kan je heel makkelijk door de schermen in Figma navigeren, door met je vingers te slepen.
Om in te zoomen naar een scherm, kan je + of - op je toetsenbord gebruiken (dit kan verschillen per toetsenbord). Je kan ook rechts boven zoom opties vinden met verschillende toetsenbord sneltoetsen terug vinden.
Als je een trackpad hebt, kan je ook makkelijk in- en uitzoomen door je twee vingers van of naar elkaar te slepen.
Feedback geven via Figma doe je door comments te laten op schermen.
Een designer bezorgt een Figma link naar mockups. Om comments te kunnen schrijven, moet je eerst een account aanmaken.
Eens je een Figma account hebt aangemaakt, kan je comments laten op specifieke plekken op de schermen.
Om in comment modus te gaan, moet je op het tekst ballonetje linke boven klikken. Je muis zal dan in een pin veranderen. Deze kan je eender waar in het document plaatsen. Wanneer je dit doet, maak je een comment aan. Dan mag je daar relevante feedback schrijven.
Als je per ongeluk op de verkeerde plaats een pin zet, kan je op Cancel drukken, of ergens anders op de scherm klikken met je muis. Dit zorgt ervoor dat de pin verdwijnt.
Eens je je feedback geschreven hebt, mag je op "post" drukken. Dit maakt je comment zichtbaar voor iedereen die toegang heeft tot de Figma link. Je kan een lijst van alle comments zien op de rechter kant van je scherm, wanneer je in "comment modus" bent. Je kan ook reageren op comments en discussies starten.
Our apps use Ember.js as their Javascript framework.
A good guide would be https://guides.emberjs.com/release/ – but if you're more of a book person, we would recommend https://balinterdi.com/rock-and-roll-with-emberjs/.
We use octane with glimmer components.
Most components have been migrated to octane and glimmer, but sometimes you can find some old syntax here and there. You can definitely update this.
Compare here what the old and the new syntax look like.
You can test your components here:
Link to feature passports page as well
Designers at ABB work on different fields and overlap with people in other disciplines as well (front-end, analysis, ...). It's up to you which fields you would like to contribute to. Some examples of what we do:
Conceptualisation
Analysis
User interviews
Wireframing & sketches
High fidelity mockups
HTML & CSS
User testing
Branding
Presentations