Chapter 6 made data a product with an owner, a contract, and lineage. This chapter follows that data into the model and describes the model lifecycle as a pipeline with gates rather than a sequence of projects: experiment tracking, the registry, promotion gates, deployment, rollback, and retirement; the ML Test Score as a readiness measure; what changes when the managed artefact is a prompt, an evaluation set, or an adapter; and how regulated organisations enforce separation of duties inside the pipeline. It extends Architecture as Code (Chapters 5 and 13) to the model (72, Nordqvist, 2025).
Sculley and colleagues gave the field its vocabulary for what goes wrong when models are treated as ordinary software (43, Sculley et al., 2015). Their catalogue of hidden technical debt includes entanglement ("changing anything changes everything"), data dependencies that change without a commit, feedback loops in which a model influences its future training data, pipeline jungles of glue code, and dead experimental code paths. These debts accrue between training runs, so they are lifecycle problems.
Amershi and colleagues, studying machine learning teams at Microsoft, found three ways in which the workflow differs from software engineering: managing data is harder than managing code, model customisation demands skills most software teams lack, and models resist modular design (65, Amershi et al., 2019). Machine Learning Operations (MLOps) is the response. Kreuzberger, Kühl, and Hirschl derive nine principles for it, among them CI/CD automation, reproducibility, versioning of data, model, and code, continuous training and evaluation, metadata tracking, and continuous monitoring (68, Kreuzberger et al., 2023), and Google's practitioner guide describes the same processes supported by a model registry and metadata tracking (81, Google Cloud, 2021). What the literature leaves to the architect is wiring the components into a pipeline that an auditor can read and a platform team can run at scale.
Primary topics explored
- Why the lifecycle needs its own discipline
- The stages of the pipeline
- Reproducibility
- The ML Test Score as a readiness gate
- LLMOps: what changes with foundation models
- Separation of duties in regulated organisations
About AI Platform and Security
AI Platform and Security is Book 3 of The Transformed Architecture. It shows how large European enterprises and public authorities build, secure and operate the platform on which artificial intelligence runs: data, models and DevSecMLOps, retrieval and agents, infrastructure and sovereignty, AI security engineering, evaluation, observability and cost.
The companion volume AI Governance covers risk management, governance, assurance, organisation and leadership; Architecture as Code supplies the underlying discipline.
Platform engineers, security architects, MLOps teams, AI architects and technical decision-makers.
Gunnar Nordqvist
Conceived, directed and published the books of The Transformed Architecture.
Continue with the full chapter
Chapter 7: Model Lifecycle Management: MLOps and LLMOps as Code in AI Platform and Security gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “Data, Models and DevSecMLOps” and is one of 29 drawn from the manuscript.