Case: TotalEnergies’ TERA

As one of the world’s major oil companies, TotalEnergies is responsible for distributing a large portion of the world’s energy supplies. Its oil refineries play a key role to achieve this. TERA, the Antwerp-based TotalEnergies refinery, wants to replace their internal system that manages the oil movements on their site. Agile Architects helped TERA to turn their business-minded requirements into a technically feasible application architecture, so they could send out a request for proposal. 


In the past forty years, TERA developed a homemade system to manage the movements of oil and its derivatives on their site. While the old system served them well, TERA wanted to refactor it into a new application to avoid future compatibility issues and simplify the onboarding of new employees. Following TotalEnergies’ IT roadmap, around 80% of this system had to be bought at software vendors and integrated further. Our team helped TERA to reformulate, restructure and update the previously written functional requirements for the new system. 

Testing day 

Agile Architects and TERA started their collaboration by organising a test day, where we delivered documentation for a limited use case with a to-be architecture and a list of functional and non-functional requirements. We delivered the output ahead of time while exceeding their expectations. This test day also helped us to understand what TERA was looking for specifically 

Project approach and preparation 

After the successful completion of the test day, we submitted a proposal that was quickly accepted.  While determining the scope, we estimated the length of the rest of the project using the Agile approach. We envisioned four succeeding sprints to work on the product, and one concluding sprint to wrap everything up. We planned the project to take twelve weeks, but TERA challenged us to do it in nine weeks instead, which we accomplished. 

Besides the sprint structure, we also outlined the functional areas of our final document, so we could structure the project accordingly. The generic functional split at the application level made it easier for software package vendors to map their solutions in their eventual proposals. 

Writing a living document 

Once the initial sprint had finished, we expanded the team so we could start acting. Together, we started by analysing the wealth of documentation and other information provided to us by TERA. We continued the analysis throughout the project’s sprints based on the functional areas we had outlined. These served as the backbone of our final document. 

We turned those documents into user stories and aligned the stories with TERA’s key users when something was not completely clear. While writing the documentation, we realised that some technicalities could get lost in translation. We therefore decided to create a glossary of terms, as well as an exhaustive list of role descriptions. That way, we could be sure that there was no confusion, both for us during the project and for the software vendors in TERA’s request for proposal afterward. 


Besides analysing documentation, we organised workshops throughout the four main sprints. The first workshops of each sprint revolved around discovering what we didn’t know yet, while the subsequent workshops dealt with solving our remaining questions. We debated both functional requirements (like business processes, use cases, and data info) and non-functional requirements (for example, the needed languages, response times, and number of transactions and users). 

At the end of each sprint, we delivered additions to our documentation as a work in progress. That way, the stakeholders at TERA could start reviewing right away. We used the live commenting function of Word, which meant that multiple people could work in and even review the document at the same time. This Agile way of working ensured that we could continuously improve the documentation together. 


At the end of the project, we delivered a final set of documentation to TERA. The documentation contained all the functional and non-functional requirements, a to-be architecture, a potential data model, and a list of use cases and user stories to be implemented in the new system. 

We turned TERA’s capability model, which was a list of activities, into an overarching structure that provided information about the intended system’s users, processes, and needed data. Thanks to this document, TERA could send out a detailed request for information.  

Next steps

Thanks to our efforts, the Antwerp refinery of Total Energies quickly gained approval from its headquarters to send out the request for proposal. At the time of writing, TERA has already received several answers from software vendors to provide components for the new system. 

Do you have a large project in the works that could use a guiding hand for its architecture? Need a technical partner to clear up your requirements during analysis, implement a governance model, and come up with a clear project planning? Agile Architects is here to help!

As experts in the Open Agile Architecture™ framework, we’re at the forefront of architectural innovation.

Please don’t hesitate to contact us, to discuss the possibilities together!