ProRail’s experiences with M+P as a software development partner

Collaborating with ProRail on a complex job

The Sound Register platform was built and rolled out fully automatically and is based on separate components. In his role as architect, Ard Kuijpers was responsible for the software design. And ProRail’s experience with the design and collaboration have been positive. Nico Mans, ICT Product Manager & Product Owner at ProRail, puts it as follows:

“We enjoyed tackling this complex task together. It was obvious that the M+P employees have knowledge of both programming and sound, and that they understand the purpose of the Sound Register [Geluidregister] in terms of its use. Some calculations take an awful lot of time, but they provide good solutions: in this case scalability. Their IT knowledge ensured the software roll-out went smoothly, even though we had to do a lot of ground-breaking work to get things done. We had to take our old computer system into account in the process. All the connections between the Cloud and the old systems running at ProRail have now been made. And because it worked so well, we were able to add some additional things to the process after delivery. The fact we are able to work well together and communicate with just a few words is thanks to the M+P employees’ understanding of the language we use. If there is a problem, the urgency is understood and felt. And steps are taken quickly. And because they speak our language, they can come up with new ideas and solutions on their own that ProRail really needs. Not necessarily to make extra money, but because they are truly workable solutions. This makes me happy.”

The software playing field has changed

We have seen customer’s software needs evolving significantly over the years. In the past, a person or organisation would need a programme for computationally intensive processes, and someone with software knowledge would build a single application as a whole, which would then be installed on that organisation’s computer. If a single part of the software application failed, the entire programme had to be replaced. If there were large calculation jobs, queues would form. This working method is no longer valid. The software now runs in the Cloud. It must be available to multiple people, 24 hours a day, 7 days a week, 365 days a year. If there are large calculation jobs, computer capacity can be rented to temporarily scale up. If you need less capacity for a while, you can also scale down again. The advantage of this is that you no longer need maximum capacity in-house.

M+P leads the way: our applications are flexible, just like our people 

It is clear that the change in the playing field also applies to the sound world. M+P likes to take the lead in new developments, so we see this as a great challenge for our pioneering spirit. Domain knowledge and programming language knowledge is simply not enough. We also need to be able to roll out our software reliably (always available) with the ability to be scaled up and down as required.

Development and Operations 

Senior consultant Erik van Gils has developed into an Development and Operations expert. This is the term for a new way of working within software development, where development and operations work together as one team. The “Dev” part of DevOps is mainly about designing software for flexibility. The often complex software is split into separate components that each perform a part of the calculation process. These are autonomous building blocks that can be exchanged easily. And it is easy to calculate the amount of computing power required for each process step. If you want to change one building block (the component that calculates the sound transfer between source and receiver for example), it can be taken out, redeveloped, and returned to its previous location between the other building blocks. This way of working enables a rapid response to new developments. 

The "Ops" part is more about execution in the Cloud and continuous accessibility for everyone. When designing a programme, we take account of the scalability and reliability requirements: multiple building blocks can run in parallel next to each other and perform tasks. And if one fails, the whole system just keeps running. For example, if at a certain time we have multiple external measuring systems transmitting data 24/7, the system autonomously ensures the capacity is expanded to process the measurement data. 

CI/CD – Continuous Integration/Continuous Deployment – is the part of DevOps that ensures when a change is made to the software that it is first checked to see whether the change will break something else. Once all the check marks are green and the new component is approved, it is then automatically rolled out into the customer’s running system. This means parts of the software can be updated while the entire system continues to operate, and the customer does not actually notice anything.

Looking for interaction and the real question behind a problem 

We pride ourselves on having everything to complete a project in-house, from start to finish. Both for the software development and the operations parts. Our background as consultants works to our advantage when we look for the real demands behind a client’s project. We seek interaction with both the client and the end users. For example, organising a session during a test phase will ensure we can immediately achieve clarity in terms of what the end users need without words getting lost in translation. This is how we build software that is actually required. Reproducible, flexible, scalable and reliable.