Linked.Archi ML-Enabled Systems Extension
Extension ontology for modeling ML-enabled system architectures. Provides element types, relationship types, stakeholders, concerns, and viewpoints for describing the ML aspects of software systems — training pipelines, model serving, feature engineering, data lineage, and the integration boundary between ML and non-ML components. Motivated by the gap identified in Moin et al. (2023): existing architecture frameworks lack stakeholders, viewpoints, and model kinds for data scientists, data engineers, and ML engineers. This extension addresses that gap within the Linked.Archi ecosystem.
Ontology for modeling ML-enabled system architectures within the Linked.Archi ecosystem.
Linked.Archi
Data Scientist
Responsible for analytics modeling — selecting algorithms, engineering features, training ML models, and evaluating model performance using metrics such as accuracy, precision, recall, and F1 score. Data scientists work primarily with mathematical formalisms, statistical models, and computational graphs.
Identified by Moin et al. (2023) as a missing stakeholder in existing architecture frameworks. Their concerns include ML model accuracy, feature quality, algorithm selection, and model interpretability.
Data Engineer
Responsible for analytics operations — building and maintaining data pipelines, ensuring scalable data processing, deploying trained models into production, and managing the infrastructure for model serving and monitoring.
Identified by Moin et al. (2023) as a missing stakeholder. Their concerns include data pipeline reliability, model deployment automation, serving latency, and infrastructure scalability.
ML Engineer
Bridges data science and software engineering — productionizing ML models, managing model serving infrastructure, implementing monitoring and retraining pipelines, and ensuring ML components integrate correctly with non-ML system components.
Recognized by Muccini & Vaidhyanathan (2021) and Lewis et al. (2021) as a distinct role in ML-enabled system development.
Ethics Committee / Officer
Responsible for evaluating the ethical, legal, and social implications (ELSI) of ML-enabled systems — including fairness, bias, explainability, privacy, and trustworthiness of ML components.
Identified by Moin et al. (2023) as a stakeholder whose concerns are not addressed by existing architecture frameworks.
ML Model Performance
ML-specific performance metrics — accuracy, precision, recall, F1 score, AUC-ROC, mean squared error, and other evaluation metrics that measure how well an ML model performs its inference task on unseen data.
Distinct from system performance (latency, throughput). A model may have excellent ML performance but introduce unacceptable latency, or vice versa.
Data Quality
Completeness, correctness, timeliness, representativeness, and consistency of data used for training, validation, and inference. Poor data quality directly degrades model performance and can introduce bias.
Model Drift
Degradation of model performance over time due to changes in the underlying data distribution (data drift) or changes in the relationship between features and targets (concept drift). Requires monitoring and retraining strategies.
Explainability
The ability to understand, interpret, and communicate why an ML model produces specific predictions. Critical for regulatory compliance (e.g., GDPR right to explanation), stakeholder trust, and debugging.
Fairness & Bias
Ensuring ML models do not systematically discriminate against individuals or groups based on protected attributes (race, gender, age, etc.). Includes detection and mitigation of bias in training data and model outputs.
Adversarial Robustness
Resilience of ML models against adversarial attacks — deliberate manipulation of inputs or training data to cause incorrect predictions. Includes evasion attacks, data poisoning, and model extraction.
Moin et al. (2023) note that software engineers often underestimate the vulnerability of ML-enabled systems through adversarial attacks.
ML Artifact Versioning
Tracking versions of ML artifacts — trained models, model parameters and hyperparameters, training datasets, feature definitions, and pipeline configurations. Essential for reproducibility and auditability.
ML Monitorability
Runtime monitoring of ML components — prediction distributions, feature distributions, serving latency, model staleness, and data pipeline health. Enables detection of drift, degradation, and anomalies.
Lewis et al. (2021) identify monitorability as a new quality attribute concern specific to ML-enabled systems.
ML Privacy
Privacy challenges specific to ML — training data memorization, model inversion attacks, membership inference, and compliance with data protection regulations (GDPR, CCPA) in the context of ML pipelines.
ML–SE Collaboration
The challenge of coordinating work between data science and software engineering teams — different vocabularies, tools, workflows, and quality metrics. The "ML Mismatch" problem identified by Lewis et al. (2021).
ML Component
An abstract base class for all ML-specific architectural elements. ML components are software artifacts with special characteristics: their behavior is inferred from data rather than specified at design time, they require retraining, and they have distinct lifecycle and versioning needs.
Moin et al. (2023) argue that ML artifacts deserve separate identity, distinguished from software source code and raw data.
ML Model
A trained machine learning model — the core artifact produced by the data science workflow. Includes the model architecture (e.g., neural network topology, decision tree structure), trained parameters, and associated metadata (training date, dataset version, performance metrics).
Not to be confused with arch:Model (an architecture description) or data models (database schemas). An MLModel is a computational artifact that performs inference on data.
Training Pipeline
The end-to-end automated process for training an ML model — from data ingestion and preprocessing through feature engineering, model training, evaluation, and model registration. Typically orchestrated by tools like Kubeflow, MLflow, or Airflow.
Serving Infrastructure
Infrastructure for serving ML model predictions at runtime — model servers (TensorFlow Serving, Triton, Seldon), API endpoints, batch prediction jobs, and edge deployment runtimes.
Feature Store
A centralized repository for storing, managing, and serving ML features. Provides consistent feature definitions across training and serving, feature versioning, and point-in-time correctness for training data.
Dataset
A versioned collection of data used for training, validation, or evaluation of ML models. Carries metadata about provenance, schema, quality metrics, and applicable data governance policies.
Distinct from database entities (data models). A Dataset is a curated, versioned snapshot used in the ML lifecycle.
ML Monitoring Component
A component responsible for monitoring ML model behavior in production — tracking prediction distributions, detecting data drift and concept drift, alerting on performance degradation, and triggering retraining workflows.
Experiment Tracker
A component for tracking ML experiments — recording hyperparameters, metrics, artifacts, and code versions for each training run. Enables reproducibility and comparison across experiments.
Model Registry
A versioned catalog of trained ML models with their metadata, lineage, performance metrics, and deployment status. The single source of truth for which models are approved for production.
Data Pipeline
An automated workflow for ingesting, transforming, validating, and delivering data to downstream consumers (training pipelines, feature stores, analytics systems). Distinct from TrainingPipeline in that it handles raw data processing rather than model training.
trained on
Links an ML model to the dataset it was trained on.
produces model
Links a training pipeline to the ML model it produces.
serves
Links serving infrastructure to the ML model it serves for inference.
monitors
Links a monitoring component to the ML component it monitors.
feeds features
Links a feature store to the training pipeline or serving infrastructure it provides features to.
registered in
Links an ML model to the model registry where it is cataloged.
consumes data
Links a data pipeline to the data source it ingests from.
produces dataset
Links a data pipeline to the dataset it produces.
integrates with
Links an ML component to a non-ML component it integrates with. This is the critical boundary identified by Moin et al. — the interface between ML and traditional software components.
triggers retraining
Links a monitoring component to the training pipeline it triggers when drift is detected.
Trained On
A qualified training relationship — carries metadata about training run, date, hyperparameters.
Produces Model
A qualified model production relationship — carries pipeline run metadata.
Integrates With
A qualified integration relationship between ML and non-ML components. Carries metadata about the integration contract: API format, latency SLA, data schema, and responsible team.
Analytics Modeling
Frames the concerns of data scientists — model architecture, training pipelines, feature engineering, evaluation metrics, and algorithm selection. Views governed by this viewpoint show the ML model landscape: which models exist, what data they consume, how they are trained, and how they perform.
Analytics Operations
Frames the concerns of data engineers and ML engineers — model deployment, serving infrastructure, monitoring, retraining pipelines, and operational health. Views governed by this viewpoint show the MLOps landscape: how models move from training to production and how they are maintained.
ML System Integration
Shows how ML components integrate with non-ML components — the boundary that Moin et al. identify as the key collaboration challenge. Views governed by this viewpoint show integration contracts, data flows, latency budgets, and team responsibilities at the ML/SE boundary.
ML Ethics & Compliance
Frames fairness, explainability, privacy, and regulatory compliance concerns for ML-enabled systems. Views governed by this viewpoint show which models handle sensitive data, what bias mitigation measures are in place, and compliance status with applicable regulations.
ML Model Catalog
Inventory of all ML models with key attributes — owner, status, performance metrics, dataset lineage, deployment target, and monitoring status. The ML equivalent of a component catalog.
has model version
The version identifier of a trained ML model.
has performance metric
A key performance metric value for an ML model (e.g., accuracy=0.94).
has model architecture
Description of the ML model architecture — e.g., 'ResNet-50', '3-layer LSTM', 'XGBoost with 500 trees'. This is the structural specification that data scientists use to communicate model design.
has framework
The ML framework used to build the model (e.g., TensorFlow, PyTorch, scikit-learn).
has retraining schedule
The schedule or trigger for retraining the model (e.g., 'weekly', 'on drift detection').
has serving latency SLA
The maximum acceptable latency for model inference (e.g., 'p99 < 100ms').
has data lineage
Links a dataset to its upstream data sources for provenance tracking.
has monitoring plan
Links an ML model to the monitoring component responsible for tracking its production behavior.