Trade-offs of using PORTS AND ADAPTERS
to build an MLES for the Maritime Domain
https://renatocf.xyz/icsa26-slides
2026
Renato Cordeiro Ferreira
Institute of Mathematics and Statistics (IME)
University of São Paulo (USP) – Brazil
Jheronimus Academy of Data Science (JADS)
Technical University of Eindhoven (TUe) / Tilburg University (TiU) – The Netherlands
Reusability in MLOps
Paper
Slides
Former Principal ML Engineer at Elo7 (BR)
4 years of industry experience designing, building, and operating ML products with multidisciplinary teams
B.Sc. and M.Sc. at University of São Paulo (BR)
Theoretical and practical experience with Machine Learning and Software Engineering
Scientific Programmer at JADS (NL)
Currently participating in the projects related to the maritime and security domains
Ph.D. candidate at USP + TUe
Research about SE4AI, in particular about MLOps and software architecture of ML-Enabled Systems
Renato Cordeiro Ferreira
https://renatocf.xyz/contacts
My goal is to characterize
how complexity emerges
in the software architecture
of ML-enabled systems
This talk describes
challenges and experiences
on building OCEAN GUARD:
a system for anomaly detection in the
maritime domain
System
Specification
Actors
Investigator
Anomaly
Detection
Engine
Ocean Guard
Metadata
(User retrieves more info if available)
Vessel ID
MMSI
---
Lat / Lon
Heading
COG / SOG
Date + Time Selector
(show clues of which data is available)
| 1 |
|---|
| 2 |
| 3 |
| 4 |
| 5 |
| 6 |
| 7 |
| 8 |
| 9 |
| 10 |
| 11 |
| 12 |
| 1 |
|---|
| 2 |
| 3 |
| 4 |
| 5 |
| 6 |
| 7 |
| 8 |
| 9 |
| 10 |
| 11 |
| 12 |
| 13 |
| 13 |
| 15 |
| 16 |
| 17 |
| 18 |
| .. |
months
days
hours
Vessel
Trajectory
Known
Vessel
Known
Vessel
Known
Vessel
Known
Structure
Piraeus Sea
(35.86, 23.03)
(37.95, 23.76)
Move to another
Area of Interest
AoI Selector
(indicates where the map is zoomed in currently)
Unknown
Vessel
Unknown
Vessel
Known
Vessel
See geolocations of marine objects in a map
Filter geolocations by area of interest, date and time
I2
Discern different types of marine objects (vessels, etc.)
I3
Retrieve geolocations from different data sources.
I4
Check metadata associated with a given marine object
I5
Highlight the trajectory of a marine object
I6
See anomalies identified by the tool in a map
I7
Filter anomalies by area of interest, date and time
I8
Inspect why an anomaly was considered so by the tool
I9
I1
Ocean Guard
Metadata
(User retrieves more info if available)
Vessel ID
MMSI
---
Lat / Lon
Heading
COG / SOG
Date + Time Selector
(show clues of which data is available)
| 1 |
|---|
| 2 |
| 3 |
| 4 |
| 5 |
| 6 |
| 7 |
| 8 |
| 9 |
| 10 |
| 11 |
| 12 |
| 1 |
|---|
| 2 |
| 3 |
| 4 |
| 5 |
| 6 |
| 7 |
| 8 |
| 9 |
| 10 |
| 11 |
| 12 |
| 13 |
| 13 |
| 15 |
| 16 |
| 17 |
| 18 |
| .. |
months
days
hours
Vessel
Trajectory
Known
Vessel
Known
Vessel
Known
Vessel
Known
Structure
Piraeus Sea
(35.86, 23.03)
(37.95, 23.76)
Move to another
Area of Interest
AoI Selector
(indicates where the map is zoomed in currently)
I3
Unknown
Vessel
I3
I7
I1
I6
I3
I3
I2
I8
Unknown
Vessel
I7
Known
Vessel
I4
Detect anomalies related to a marine object
List anomalies by area of interest, date and time
Explain why an anomaly can be
considered so
A2
A3
A1
System
Architecture
Software Architecture in Practice - ICSA 2026
Reusability in MLOps:
Leveraging Ports and Adapters
to Build a Microservices Architecture
for the Maritime Domain
Delta Architecture
Reactive
Machine Learning
Data Product
SummerSOC 2025
MLOps with Microservices:
A Case Study in the
Maritime Domain
Core Dev Team
Scientific Programmers
Research Team
MSc Students
Innovation Team
PDEng Trainees
Core Dev Team
Scientific Programmers
Ui Dev Team
Hired Developers
Core Dev Team
Scientific Programmers
Research Team
MSc Students
Innovation Team
PDEng Trainees
Research
Team
Innovation
Team
Core Dev
Team
UI Dev
Team
Exploration of
state-of-the-art
techniques
Exploration of
state-of-the-practice
techniques
Back-end development
and infrastructure management
Front-end development
and user interface
design
Experimentation and Training Pipelines
Experimentation and Training Pipelines
API, Databases,
Model Repository
WebApp
Master
Students
EngD
Trainees
Scientific
Programmers
Assistant
Programmers
Document the expected formats of data exchange between two services or pipelines, which interact as consumer and producer via a data storage
Document the expected protocol of behavior between two services,
which interact synchronously or asynchronously via the network
Document the expected input and output between a trainer and a server, which interact by storing and loading models in a model registry
Code Contracts
Data Contracts
Model Contracts
Service
Architecture
Software Architecture in Practice - ICSA 2026
Reusability in MLOps:
Leveraging Ports and Adapters
to Build a Microservices Architecture
for the Maritime Domain
Contains Ports & Adapters reusable by all services
Cross-cutting concerns
get reused in every service
Specialized dependencies
are reused by connected services
This talk describes
challenges and experiences
on building OCEAN GUARD:
a system for anomaly detection in the
maritime domain
Trade-offs of using PORTS AND ADAPTERS
to build an MLES for the Maritime Domain
https://renatocf.xyz/icsa26-slides
2026
Renato Cordeiro Ferreira
Institute of Mathematics and Statistics (IME)
University of São Paulo (USP) – Brazil
Jheronimus Academy of Data Science (JADS)
Technical University of Eindhoven (TUe) / Tilburg University (TiU) – The Netherlands
Reusability in MLOps
Paper
Slides
My goal is to characterize
how complexity emerges
in the software architecture
of ML-enabled systems
Complexity Model
Data
Model
Code
Schema
Sampling
Volume
Algorithms
More Training
Experiments
Business Needs
Bug Fixes
Configuration
Axis of Change for ML
Based on "Continuous Delivery for Machine Learning", by Danilo Sato, Arif Wider, and Christoph Windheuser -- https://martinfowler.com/articles/cd4ml.html
Data
Model
Code
Volume
Value
Velocity
Variety
Veracity
Servers
Retraining
Dimension
Flexibility
Change
Processes
Control Density
Storages
Process Ratio
Data Density
Data
Volume
Value
Velocity
Variety
Veracity
the average number of bytes collected by the architecture in a daily run
the average number of bytes collected by the architecture per second
the number of features collected by the architecture
the size of the longest path of data flow connecting a data source and a model
the percentage of features used over features collected by the architecture
Model
the number of model servers included in the architecture
the sum of parameters * input features for all models included in the architecture
the sum of hyperparameters for all models included in the architecture
the highest expected rate of change by a model in the architecture (monthly, yearly, etc.)
the highest expected rate of retraining by a model in the architecture (daily, weekly, etc.)
Servers
Retraining
Dimension
Flexibility
Change
Code
the number of process components (services + pipelines) in the architecture
the number of storage components in the architecture
the percentage of services over processes (services + pipelines) in the architecture
the percentage of existing over possible data flow connections in the architecture
the percentage of existing over possible control flow connections in the architecture
Processes
Control Density
Storages
Process Ratio
Data Density
Case Study
Also available at:
Participate
on our survey!
https://renatocf.xyz/
mlops-metrics-survey
Trade-offs of using PORTS AND ADAPTERS
to build an MLES for the Maritime Domain
https://renatocf.xyz/icsa26-slides
2026
Renato Cordeiro Ferreira
Institute of Mathematics and Statistics (IME)
University of São Paulo (USP) – Brazil
Jheronimus Academy of Data Science (JADS)
Technical University of Eindhoven (TUe) / Tilburg University (TiU) – The Netherlands
Reusability in MLOps
Paper
Slides