ARCHITECTURAL PATTERNS FOR SOFTWARE DESIGN OF INTELLIGENT SYSTEMS
TL;DR
Results indicate that separating concerns across the proposed four layers reduces the coupling between data-science experimentation and production software engineering, improves deployment reproducibility, and provides an explicit, empirically bounded mechanism for continuous training that keeps deployed models aligned with the current data distribution.
Abstract
The design of software for intelligent systems increasingly extends beyond model training to encompass the full lifecycle of a machine learning (ML) component within a production software system: data ingestion, feature preparation, model serving, monitoring, and retraining. Conventional software architecture patterns, developed for deterministic systems, do not directly address the specific engineering challenges posed by ML components, namely non-determinism in outputs, dependence on data distributions that change over time, and coupling between code artifacts and data or model artifacts. This study addresses the problem of formulating a coherent architectural methodology for designing software for intelligent systems that treats the ML model as a first-class, versioned software component rather than as an external black box invoked by conventional application code. Recent research on MLOps, continuous training (CT) pipelines, microservice decomposition of inference services, and data-drift monitoring was analyzed, and the previously insufficiently addressed problem of integrating these separate practices into a single, reproducible architectural pattern was identified. A layered reference architecture for intelligent systems that separates the data layer, the model-training and versioning layer, the inference/serving layer, and the observability layer was proposed and justified. The supporting continuous integration, continuous delivery, and continuous training (CI/CD/CT) pipeline that binds these layers together was described. The main research material presents the architecture in detail and validates it with three reproducible Python experiments: a regression case study that predicts the volume electrical resistivity of carbon-filled polyethylene composites from experimental data used as a concrete intelligent-system component situated in the training and versioning layer; a discrete simulation of the observability layer's Kolmogorov-Smirnov drift monitor, which detected an injected gradual distribution shift with a measured delay of 100 requests; a discrete-event simulation of the serving layer comparing a synchronous and an asynchronous, task-queue-based design under identical offered load, showing a 136-fold reduction in 95th-percentile latency for the asynchronous design. The results indicate that separating concerns across the proposed four layers reduces the coupling between data-science experimentation and production software engineering, improves deployment reproducibility, and provides an explicit, empirically bounded mechanism for continuous training that keeps deployed models aligned with the current data distribution. These advantages, together with the architecture's current limitations, point to prospects for further research, including the extension of the architecture to support multi-model orchestration and automated rollback strategies driven by online quality metrics.