Month: January 2022

Previse Systems is pleased to announce our new colleague Lorenzo Costantini, who has joined us as Software Developer.

Lorenzo combines two truly unique skillsets: software development in Previse Systems’ technology stack and several years of experience in energy markets and ETRM solutions. Lorenzo will increase our overall development bandwidth with a special focus on software quality assurance.

Lorenzo – welcome to the team, great to have you on board!

What is your impression of the team and work culture at Previse Systems?

The team has always been friendly and available to me since the first day. I was offered an apartment for 6 weeks in the greater Zurich area very close to my developer colleagues to avoid having a full remote onboarding, in a time when the office was not available yet. It was very useful to me to work with them in the same room at the beginning.

Apart from this initial period, Previse Systems gives you the possibility to work remotely and for many people this could be a great help in some situations. The important thing is to deliver your work, no matter where you live or where you work. So we have also some great colleagues from all over the world and I think the most diverse set of nationalities ever seen in a company, which I thought it was very cool and it was one of the reasons which helped me to decide to join this company.

Since the first days it was clear to me that I was working with a group of people who know each other very well from previous work experiences, which have fun together and with a lot of experience in the ETRM sector and in their technical domain.

All the colleagues are passionate and driven in their work and I feel a positive and optimistic mindset to succeed in our everyday challenges and in the biggest mission to help Previse Systems grow.

What can you tell us about Previse Systems’ technology stack from a developer’s perspective?

I work mainly with Microsoft technology: Microsoft Azure and its ecosystem of services (Azure DevOps, Azure Functions, Azure Batch…), C# as language for the back-end, SQL Server as database technology. But our complete stack is vast and we are open to adopt new technologies if there is a need to. Among other technologies we use I can name Vue.js, Docker, Terraform, Power BI, Cosmos DB … I remember during my first days in the company continuouslyvto listening my colleagues mentioning new technologies every day!

I am lucky to work on a modern technology stack and we are continuously working to keep everything on the latest version. For example, at the moment we are on the way to update the whole codebase to .NET 6.

Not only the stack is modern, but we also aim to follow state of the art processes on the DevOps side. We have moved last year to CI/CD as release process and I am getting more and more used to code with the help of feature flags which is a new concept to me.

The codebase is organised via microservices which can be deployed independently, and this helps code modularity, extensibility and readability of the code. During my first time at Previse Systems I had to update some shared internal libraries and to let them be used by all the other single components of the system – it was manageable for me to read and learn one component of the codebase at a time and to gradually update all of them. With a different architecture it would have been more difficult, risky and time consuming.

What are, in your view, the core challenges of ETRM development?

Markets and general requirements are constantly evolving and in order to be able to profit from a new trading opportunity the development and the entire operations team needs to keep up with those changes. That has been the main challenge also considering my previous work experience.

I have experienced that in some cases even having a periodic 2-weeks release cycle, already short compared to other realities, is not enough for traders or other stakeholders. Platform changes may be needed in a shorter time, and that’s why Previse Systems have moved on a CI/CD process. This need for a very short time to market is the reason behind most of the DevOps and processes upgrades we have been doing during the last year.

But microservices and DevOps processes alone cannot be the only answer to this problem, because also the decisions on data models and the assumptions made on the requirements can make or break a project. Having people in the team with a lot of expertise in the commodity trading sector is a great asset to build an extensible product with a sound underlying data model, reducing the risk of having impossible or difficult redesign in the future when requirements will change.

Some clever ideas have been implemented also on a lower level: the trade templates concept, the usage of a consistent CRUD approach in many APIs coupled to high level reusable patterns, or the implementation of a consistent web page styling which makes UI flexible and configurable from database helps a lot to implement in a fast way similar new features.