AI as a catalyst for software architecture: example from public transport

Contents

Artificial intelligence (AI) brings with it new requirements, paradigms and interactions that expand or challenge traditional approaches to software architecture in many areas. For software architects, this means that they must further develop their role, their methods and their ways of thinking in order to do justice to the complex framework conditions of data-driven systems.

Mahbouba Gharbi

Mahbouba ist Geschäftsführerin, Softwarearchitektin und Trainerin bei der ITech Progress GmbH, einem Beratungsunternehmen und akkreditierten Schulungsanbieter des iSAQB mit über zwanzig Jahren Erfahrung. Als Kuratorin des iSAQB-Advanced-Level-Moduls SWARC4AI vermittelt sie methodische und technische Konzepte für den Entwurf und die Entwicklung skalierbarer KI-Systeme. Dabei legt sie besonderen Wert auf praxisnahe, nachhaltige und anwendungsorientierte Lösungen.

Dimitri Blatner

Dimitri ist Softwarearchitekt und Trainer bei der ITech Progress GmbH. Als zertifizierter Trainer für das iSAQB-Advanced-Level-Modul SWARC4AI vermittelt er praxisnahes Wissen zum Entwurf und zur Entwicklung skalierbarer KI-Systeme. Seine Schwerpunkte liegen in den Bereichen Cloud-Technologien, DevSecOps, hybride Architekturen und KI-basierte Lösungen. Dimitri unterstützt Unternehmen dabei, innovative und zugleich sichere Systeme erfolgreich zu realisieren.

This article sheds light on how the architecture development process is changing through the use of AI – and what this means in concrete terms for the practice of software architecture. To illustrate this, we show examples of a project from the public transport sector in which we were involved as software architects.

Two roles of AI: tool and component

In the context of architecture, artificial intelligence takes on two different roles: as support in the development process and as an active system component. This distinction is essential for the classification of technical, methodological and organizational requirements. In its role as a tool, AI supports architects throughout various process phases. In early phases, AI tools can help with the consolidation and analysis of requirements. Natural language processing (NLP), for example, enables functional and non-functional requirements to be extracted from text sources or interview transcripts.

Later in the process, graph-based models can be used to generate architecture variants that the AI evaluates in terms of predefined quality characteristics. In review phases, the AI provides support in the analysis of existing systems, for example by recognizing architectural erosion or cyclical dependencies.

This distinction between the two roles of AI also applies to public transport, and it entails different quality requirements, operational risks and responsibilities in each case. While AI works as an analysis tool in the background and supports process-oriented improvements, as a component of productive systems, it directly influences the behavior, resilience and further development of digital passenger services and operational management.

AI-supported software architecture in municipal public transport

The transport company with over 10 million passengers per month has systematically integrated artificial intelligence into its software architecture with the aim of improving quality, maintainability and service orientation – both in operational IT and in digital products for passengers. A generative AI analysis module based on a large language model (LLM) is used as early as the architecture process: it automatically evaluates architecture documentation, extracts central design decisions, for example on the connection of passenger information systems or the data storage of real-time timetables – and compares these with the implemented services and interfaces. This enables the architects to identify and document inconsistencies and technical debts at an early stage.

Another data-driven assistance system uses unsupervised learning to identify failure patterns in historical vehicle data. These findings flow directly into requirements for sensor technology and data latency – and thus strengthen architectural decisions.

During operation, a predictive machine learning model (ML model) continuously analyzes diagnostic data from the bus fleet. It recognizes early signs of technical defects (predictive maintenance) and enables targeted maintenance measures. At the same time, it automatically generates appropriate passenger information as soon as deviations from the timetable occur – in line with the forecast quality. The system architecture not only maps the ML model itself, but also the necessary data pipelines, MLOps infrastructure and processes for validation, monitoring and continuous training. The model pipeline thus becomes a critical, maintainable and transparent component of the overall architecture.

Architecture becomes data- and model-centric

Traditional software architecture is primarily function-oriented: it focuses on technical components, clear interfaces and well-defined processes. In AI-based systems, the focus shifts considerably. Here, data flows, machine learning models and training processes characterize the structure of the system. As a result, data sources, their quality and their availability gain crucial importance. The selection and preparation of the data have a direct influence on the performance and correctness of the models used later.

In addition, architects have to deal with concepts such as model versioning, continuous model improvement (continuous learning) and suitable monitoring mechanisms. Traditional expectations of system stability are giving way to new requirements for flexibility and adaptability, as models change through retraining or replacement with improved variants. This makes architecture work more dynamic and data-driven.

Quality takes on new dimensions

AI adds new dimensions to the quality criteria for software systems. In addition to established requirements such as performance, maintainability or security, aspects such as explainability, fairness and trustworthiness are emerging. Decisions made using ML models must be comprehensible for technical and non-technical stakeholders –, especially if they have an impact on people or social processes.

In addition, the importance of robustness against changing data situations and of mechanisms to safeguard against incorrect model predictions is increasing. Architects are required to deal with uncertainties explicitly: through confidence scores, gradations in decision reliability or fallback-based system paths. This makes it clear that architecture in the age of AI must go beyond purely technical criteria and consider systemic resilience and ethical responsibility.

The architecture process is becoming more iterative

In contrast to traditional projects, where the architecture is largely defined at the beginning, the architecture process in AI projects consists of an iterative approach right from the start (Figure 1). Key findings about data distribution, model behavior or use cases often only emerge during exploratory experiments. Accordingly, the architecture must be flexible enough to be adaptable or even fundamentally overhauled at a later date and enable a high degree of automation.

This requires not only technical modularity, but also a different approach: Architecture work becomes a continuous learning process. Decisions under uncertainty, the introduction of temporary solutions (safeguards) and the willingness to discard existing ideas in the light of new findings are part of everyday life. The architecture process thus develops into an evolutionary dialog with the reality of the data and the application area.

New roles and responsibility interfaces

With the introduction of AI technologies, the composition of teams is also changing. Roles such as data scientist, ML engineer or MLOps specialist bring in new perspectives and working methods that differ fundamentally from traditional developer or quality assurance profiles (Figure 2). For architects, this means adapting not only technically, but also communicatively and methodically. They need to understand the concepts, working methods and expectations of these new roles and act as bridge builders: between specialist departments, data managers and technical implementation teams. Architecture decisions increasingly affect not only code and components, but also data structures, models, training units and operating processes. This leads to more complex responsibility interfaces that require clear agreements and transparent processes.

Interdisciplinarity and stakeholder involvement

Successful architecture in the AI environment requires a profound understanding of the respective application domain. Whether in healthcare, public transport or the financial sector, – data and models must be enriched with specialist context and adapted to the needs of the stakeholders. Architects therefore actively seek an exchange with experts from the domain, understand their language and integrate their perspectives into architectural considerations.

Methodologically, processes such as domain storytelling, event storming or design thinking help here. These approaches make it possible to identify complex requirements at an early stage, avoid blind spots in modeling and increase the acceptance of AI-based systems. It is particularly important to involve not only decision-makers but also future users in the architecture work, for example through co-creation workshops or scenario development.