# On the Track to Application Architectures in Public Transport Service Companies
## 3 Compiling an AI Landscape for the Public Service Transportation Business Domain
### AI-Based Software Development Life-Cycle--Organizational Behavior View  
The novel experimental characteristics of AI, of ML models in particular, as well as the vast amount of data, which needs to be taken into the overall picture have a considerable impact on how the components are developed and managed within the organisation.  
The traditional SDLC needs modifications and new roles and responsibilities are created, which influence how the exploratory ML-models evolve from an initial TRL1 proof of concept state to the final TRL9 deployment state. Traditional software development is well established. Wen the problem is recognized and analysed by the business, business analysts conduct a well established requirements engineering sub-process and hand it over to the software engineering team for implementation, testing and deployment to the runtime environment for production, such as it is visualized in Figure 2 as a BPMN diagram. In the case of engineering AI-based components, the process is less straight forward. Developer skills are well established but Data Science skills or entire new teams need to be integrated into the enterprise. Business analysts need to decide, whether the problem is best solved with traditional Requirements Engineering and subsequent traditional Software Development and well established Deployment pipelines, or whether it should be handed over to the new path of Data Analytics and subsequent Hybrid-AI Engineering where ML and KE have to be combined most efficiently. Once the problem is allocated either to the Machine Learning or Knowledge Engineering sub-process, the different TRL levels from proof of concept until TRL8 need to be evolved, until the production ready TRL9 artefact can be deployed into production. The Software Engineering team is challenged to integrate traditional DevOps with MLOps, and manage deployment pipelines with components from traditional Software Engineering, ML and KE processes. The monitoring of the software components (SCs) in production are also getting more challenging, since other than traditional SCs that have static defects which might be fixed with appropriate static patches, ML models may slightly degrade due to dynamic changes in data and KE models need to be dynamically adjusted to changing semantics in the business domain models.  
The Wagon Sharp Occupancy Forecast (WSBP) is a classic ML component placed in Figure 2 in the communication AI-domain to increase customer experience, which is one of the very first productive ML application of SBB. In fact it is a simple recommender system that shows the expected carrier occupancy to the passengers during the ticket purchase. While analysing the problem, it was clear that a simple rule based procedure would not work and that the recommendations need to consider patterns in the data. Thus a proof of concept was made that confirmed the hypothesis and a ML procedure was trained with occupancy data from over a year. This occupancy indication was then integrated into the ticketing application. New occupancy data is continuously added to the data pool and outdated data has to be discarded. In such a way, changes in behaviour, as it was the case with the Covid-19 pandemic, were taken into account and the quality of forecasts could be adjusted within a short period of time.