under construction

this page is still under construction

Current Architecture

In a first step existing systems and tools are analysed.

The topology shows the various systems and its current owners.

For those systems the business objects were determined and in a second step the workflows between the business objects.

All information is stored in Enterprise Architect in a common UML Model. A HTML copy of the model can be found here: UML Model

Topology

The topology shows currently existing systems and tools that are analysed in details. The following links guide you to the corresponding architecture models

The main systems are:

The topology can be found here: UML Model - Topology

The following picture shows the platform coverage

Business Objects

The business objects describe in an abstract way the basic objects of todays systems.

They are described in the UML Model for the above mentioned systems

The topology can be found here: UML Model - Business Objects

Detailed Business Objects are available for

Workflows

The workflows describe the interaction of the business objects of todays systems

Each workflow is described with a swimlane diagram in details

Workflow diagrams and swimlanes can be found in the UML model for each of todays systems.

Please refer to the detailed diagrams in the subdirectories of the UML Model - Business Workflows.

Messages and Data Objects

An overview of all messages exchanged with the related data objects in the current architecture landscape can be found as a list in the following document in Teams: [Messages and Objects]

Refer to the sheet Messages.

Perspectives

Based on the business objects and workflows of todays systems the services are extracted into abstract layers combining services from various systems.

Steps

The steps (see bullet points) for doing that are:

Describe the processes and platforms (done in the current architecture)
Remove platform borders keeping processes and objects
Analysis of the services based on vision, governance and principles
Aggregation of the found limitations
Description of gaps (based on found limitations)
Align services towards future architecture

Perspectives and links to Processes, Objects, Limitations and Capabilities

Each perspective is assigned to a process and contains the process steps taken out of one of the systems currently covering this perspective. In the UML model the perspectives are described in detail. The following picture shows what can be found for each perspective.

In the upper area of the perspective you find the Processes that are covered with this perspective. Below the Workflows for RUs and Partners as well as additional Digital Platform Workflows are described using swimlanes.

Use cases are described in the form of bubbles, showing involved actors.

Business Objects (blue) and Masterdata (grey) covered by this perspective are described in the lower area of the perspective.

Limitations found in the current perspective are positioned where they occur (activity, business object or below the processes for general limitations) and described with boxes (orange/brown).

Sector Initiatives belonging to this perspective that are not yet covered by a system or not yet described in the UML model are described with arrow-boxes (green).

Limitations are described in detail in a separate document. This document can be found here: [List of Limitations]

Todays Perspectives

The following perspectives were identified. The ones that contain a link are already defined and described in the UML Model.

Further possible Perspectives

Addtionally the following possible perspectives were identified. These perspectives may be analyzed in a later step.

Transport Planning and Preparation
Driver Service Book
Driver Route Knowledge
Locomotive Service Book
Locomotive Master Data

The perspectives can be found in the UML Model

The list of limitations can be found here: [List of Limitations]

Non-Functional Requirements

Non-functional requirements describe additional requirements besides those derived from business objects and workflows

Basic Principles

The following basic principles can help to find non-functional requirements:

Authentication and Security
Small-Player Access to Services
Traceability
API Management
Testing and Integration
Service Behaviour
Security and Redundancy

Non functional requirements were analysed together with the limitations and capabilities were defined, that on the one hand solve existing limitations but on the other hand also cover non-functional requirements.

A detailed description of the basic principles can be found here: [Basic Principles]

The list of non-functional requirements can be found here: [Non-functional Requirements]

Limitations

When talking about limitations, we are in the World of Problems.

Based on the description of the current systems with its business objects and workflows the limitations of todays systems can be analysed by making use of the perspectives.

Methodology

Limitations are identified in workshops based on the perspectives
Limitations found are documented in a spreadsheet and in the UML model
in order to cluster the limitations
1. duplicates are eliminated (in the spreadsheet)
2. dependencies between limitations are documented in the UML model
then the limitations are grouped into limitation groups in the UML model
for each of the groups the benefits and impacts are defined
all the groups are categorized in low, medium and high priorities

Criteria

The criteria to select potential limitations are:

Constitutional Governance
Data Governance
Service Shaping
Accessibility
Integration
Master Data
Identifiers

Priorities

All limitations are analysed and priority for each limitation is set according the following criteria and scores

Priority Criteria

Problem Area (PA)

If the limitation belongs to problem area	then the score is
Data Quality	3
Coverage (Governance)	2
Functionality / Business Processes	1

Level (L)

If the limitation belongs to level	then the score is
L1	3
L2	2
L3	1

Dependencies (D)

If the limitation has the following dependencies	then the score is
other limitations are dependent on this (predecessor)	3
this limitation has no dependencies	2
this limitations depends on other limitations	1

Value Added (V)

If impact of the limitation is	then the score is
big	3
medium	2
small	1

Effort (E)

If the implementation effort of the limitation is	then the score is
small	3
medium	2
huge	1

Weighting

For each of the above mentioned criteria a relative weight is defined

Criteria	Weight
Problem Area (PA)	3
Level (L)	1
Dependencies (D)	2
Value Added (V)	3
Effort (E)	2

Ranking

Based on sum of the scores of each criteria, multiplied with the weighting of the criteria an individual priority of each limitation results

Priority = (Score PA * Weight PA)  + (Score L * Weight L) + (Score D * Weight D) + (Score V * Weight V) + (Score E * Weight E)

The priority of each limitation varies within the range of 1 and 10.

The higher the priority value the higher the ranking of a limitation.

SAFe Ranking

The limitations were ranked additionally according to the SAFe Methodology (Scaled Agile Framework) in order to analyse the limitations in a longer planning horizon and set priorities accordingly.

The lower the SAFe for a limitation, the higher is the priority to act.

SAFe = Score E / Score VA / Score PA

the higher the effort, the higer the SAFe, meaning, the lower is the priority to act.
the higher the value added and/or the problem are, the lower is the SAFe, meaning, the higher is the priority to act.

Conclusion

Based on the above described methodology the following 26 highly ranked limitations were found

When looking at the coverage of the various clusters, the following picture shows up:

The first 19 of the top 26 limitations are related to Data Quality (out of 21 limitations), 4 limitations are related to governance and 1 limitation is related to functionality. Within the first 26 top ranked limitations business related limitations cannot be found.

Documents

A detailed description of the weighting criteria can be found here: [Criteria for Limitations]

The list of limitations can be found in the following spreadsheet: [List of Limitations]

Architecture

Contents