Difference between revisions of "Architecture"

From RFF Wiki
Jump to: navigation, search
(→‎Documents)
(→‎Capabilities)
Line 349: Line 349:
  
 
= Capabilities =
 
= Capabilities =
 +
 +
When talking about capabilities and gaps, we are in the '''World of Solutions'''.
 +
 +
Capabilities are derived from the [[\l|limitations ]]by taking into consideration the vision, governance and principles layed down by the CIOs.
 +
 +
Gaps result when future capabilities cannot be fulfilled with [[\l|existing systems ]]due to [[\l|limitations ]]of the existing systems.
 +
 +
They are the basis for the planning of development initiatives.
 +
 +
== Methodology ==
 +
 +
Based of the priorised groups of limitations the capabilities are elaborated:
 +
 +
# Definition of the capabilitity targets (what do we want)
 +
## out of the limitations
 +
## from platform requirements
 +
## from the vision
 +
# Link the capabilities with the groups of limitations
 +
# Elaborate the gaps between the groups of limitations and the expected capabilities
 +
# Work out solution variants for the gaps, clearly describing
 +
## functionality
 +
## implementation effort (T-Shirt size, XS-S-M-L-XL)
 +
## implementation duration
 +
## affected stakeholders
 +
# Assess the solution variants
 +
# Decide about the final solution variants to be implemented
 +
 +
The result of this work is a backlog of solutions, that can be implemented in the '''World of Implementation'''.
 +
 +
 
 +
 +
The capabilities can be found in the UML Model.
 +
 +
[[File:media/image16.png|429x291px]]
 +
 +
<span id="_Toc56062986" class="anchor"></span>Figure - Capabilities
 +
 +
They are linked with the limitations and non functional requirements.
 +
 +
Details can either be found directly in the Capability object or in the capabilities sheet [[Documents/List_of_Limitations_Capabilities_NFR_SAFE.xlsx|here]].
 +
 +
== Capabilities Overview ==
 +
 +
The following areas were considered when looking for future capabilities. The links refer to the UML model, where you find the details for the capabilities of the corresponding area.
 +
 +
* [https://rff.models.interconnective.ch/model/latest/index.htm?guid=FE95617F-DD32-4c5e-AE8A-3F4C23F65FE1 Location Identification]
 +
* [https://rff.models.interconnective.ch/model/latest/index.htm?guid=FA4A9698-4110-4461-A9FC-13D6B2C8F9A8 Train Identification]
 +
* [https://rff.models.interconnective.ch/model/latest/index.htm?guid=F1FF5686-5643-43f7-BA22-81C200527969 Train Operations]
 +
* [https://rff.models.interconnective.ch/model/latest/index.htm?guid=3CF4BEB8-7513-4c1b-9E35-20484D49B5EB Wagon Status]
 +
* [https://rff.models.interconnective.ch/model/latest/index.htm?guid=B4492CAE-BF01-4567-8BA8-E51357BEE7DB Wagon Damage]
 +
* [https://rff.models.interconnective.ch/model/latest/index.htm?guid=A045F24B-1ABE-43c8-AC01-3846373AAFE7 Wagon Performance]
 +
* [https://rff.models.interconnective.ch/model/latest/index.htm?guid=9C889264-BD33-42fd-8848-E2954B8455A7 Rolling Stock]
 +
* [https://rff.models.interconnective.ch/model/latest/index.htm?guid=E54FD396-21A5-4655-ABC4-C4A97A4E7753 Train Preparation]
 +
* [https://rff.models.interconnective.ch/model/latest/index.htm?guid=9FAB6655-3100-40ae-A035-681AA86471ED Braking Rules]
 +
* [https://rff.models.interconnective.ch/model/latest/index.htm?guid=C7074BD9-0C71-4d99-83F1-5E2913A0E90E Shipment Booking]
 +
* [https://rff.models.interconnective.ch/model/latest/index.htm?guid=A26F6D4A-D3C9-45ff-A886-D2B8B7315C30 Shipment Order]
 +
* [https://rff.models.interconnective.ch/model/latest/index.htm?guid=9137A319-4855-475e-8C9B-752137542249 Train Service Planning]
 +
* [https://rff.models.interconnective.ch/model/latest/index.htm?guid=B2F38FEF-4AEA-4e1d-A1E5-941B5DA960A5 Intermodal Traffic]
 +
 +
== Weighting and Ranking ==
 +
 +
All capabilities found were evaluated and a weighting added to each of the capabilities. The following approach was used to rank the capabilities:
 +
 +
=== Select Capabilities Along Limitation Ranking ===
 +
 +
# All limitations with a priority higher than 8 were selected, which results in 26 limitations
 +
# All capabilities that solve these limitations were selected and the priority of the capability was set to the priority of the limitation with the highest priority
 +
 +
This results in '''22 capabilities'''
 +
 +
=== Independent Evaluation of all Capabilities ===
 +
 +
All capabilities were evaluated independently as follows
 +
 +
<ol style="list-style-type: decimal;">
 +
<li><blockquote><p>estimated the cost of each capability<br />
 +
(3=low/&lt;200k€, 2=medium/200k€-1M€, 1=high/&gt;1M€)</p></blockquote></li>
 +
<li><blockquote><p>estimated the benefit of each capability<br />
 +
(3=high, 2=medium, 1=low)</p></blockquote></li>
 +
<li><blockquote><p>calculated the SAFE-factor for each capability<br />
 +
SAFE = 1/cost/benefit (SAFE varies between 0.11 and 1)</p></blockquote></li>
 +
<li><blockquote><p>excluded the capabilities already ranked along limitation ranking</p></blockquote></li>
 +
<li><blockquote><p>sorted remaining capabilities according to ascending SAFE</p></blockquote></li>
 +
<li><blockquote><p>selected capabilities with a SAFE-factor = 0.11</p></blockquote></li></ol>
 +
 +
This results in '''14 capabilites'''
 +
 +
=== Additional Capabilities ===
 +
 +
 At the end additional capabilities were selected that have a link to one of the above selected capabilities, since these capabilities have to realized together with the already selected capabilities in order to achieve the expected result.
 +
 +
This results in '''18 additional capabilities'''.
 +
 +
The 54 selected capabilities (of 105, 51%) solve at least 75 limitations (of 201, 37%)
 +
 +
== Conclusion ==
 +
 +
The 54 capabilities found cover almost all clusters
 +
 +
[[File:media/image17.png|604x357px]]
 +
 +
<span id="_Toc56062987" class="anchor"></span>Figure 14 - Capabilities by Clusters
 +
 +
Within these 54 capabilites, only capabilites for Braking Rules do not appear. Their ranking is too low to appear in the list of ranked capabilities.
 +
 +
When clustering the 36 main capabilities (without the related ones), the following situation shows up
 +
 +
[[File:media/image18.png|604x306px]]
 +
 +
<span id="_Toc56062988" class="anchor"></span>Figure 15 - Capabilities Overview
 +
 +
In the overview document of all capabilities (here), an even more detailed view of the capabilities and the covered limitations can be found.
 +
 +
[[File:media/image19.png|604x154px|Ein Bild, das Tisch enthält. Automatisch generierte Beschreibung]]
 +
 +
<span id="_Toc56062989" class="anchor"></span>Figure 16 - Extract of Capability Ranking
 +
 +
The list of capabilities can be found here: [[Documents/List_of_Limitations_Capabilities_NFR_SAFE.xlsx|List of Capabilities ]](as part of the List of Limitations). Each limitation described in this document has a link into the UML model.
 +
 +
Capabilities can also be found in the UML Model directly: here
 +
 +
<span id="_Data_Objects" class="anchor"></span>
  
 
= Smart Services =
 
= Smart Services =

Revision as of 09:53, 15 February 2021

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:

UML model

The topology can be found here: UML Model - Topology

The following picture shows the platform coverage

Platform coverage.png

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

Business obejcts.png


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

Workflows.png

Each workflow is described with a swimlane diagram in details

Swimlane.png

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.

Perspectives.png

Steps

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

  1. Describe the processes and platforms (done in the current architecture)
  2. Remove platform borders keeping processes and objects
  3. Analysis of the services based on vision, governance and principles
  4. Aggregation of the found limitations
  5. Description of gaps (based on found limitations)
  6. 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.

Perspective process object.png

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.

Nfr.png

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

  1. Limitations are identified in workshops based on the perspectives
  2. Limitations found are documented in a spreadsheet and in the UML model
  3. in order to cluster the limitations
    1. duplicates are eliminated (in the spreadsheet)
    2. dependencies between limitations are documented in the UML model
  4. then the limitations are grouped into limitation groups in the UML model
  5. for each of the groups the benefits and impacts are defined
  6. 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

Ranked Limitations

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

Cluster coverage.png
Prinicple coverage.png

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]

An overview of all limitations can also be found in the [| UML Model]

Additionally you find the dependencies of limitations in the [| UML Model]

Capabilities

When talking about capabilities and gaps, we are in the World of Solutions.

Capabilities are derived from the limitations by taking into consideration the vision, governance and principles layed down by the CIOs.

Gaps result when future capabilities cannot be fulfilled with existing systems due to limitations of the existing systems.

They are the basis for the planning of development initiatives.

Methodology

Based of the priorised groups of limitations the capabilities are elaborated:

  1. Definition of the capabilitity targets (what do we want)
    1. out of the limitations
    2. from platform requirements
    3. from the vision
  2. Link the capabilities with the groups of limitations
  3. Elaborate the gaps between the groups of limitations and the expected capabilities
  4. Work out solution variants for the gaps, clearly describing
    1. functionality
    2. implementation effort (T-Shirt size, XS-S-M-L-XL)
    3. implementation duration
    4. affected stakeholders
  5. Assess the solution variants
  6. Decide about the final solution variants to be implemented

The result of this work is a backlog of solutions, that can be implemented in the World of Implementation.

 

The capabilities can be found in the UML Model.

429x291px

Figure - Capabilities

They are linked with the limitations and non functional requirements.

Details can either be found directly in the Capability object or in the capabilities sheet here.

Capabilities Overview

The following areas were considered when looking for future capabilities. The links refer to the UML model, where you find the details for the capabilities of the corresponding area.

Weighting and Ranking

All capabilities found were evaluated and a weighting added to each of the capabilities. The following approach was used to rank the capabilities:

Select Capabilities Along Limitation Ranking

  1. All limitations with a priority higher than 8 were selected, which results in 26 limitations
  2. All capabilities that solve these limitations were selected and the priority of the capability was set to the priority of the limitation with the highest priority

This results in 22 capabilities

Independent Evaluation of all Capabilities

All capabilities were evaluated independently as follows

  1. estimated the cost of each capability
    (3=low/<200k€, 2=medium/200k€-1M€, 1=high/>1M€)

  2. estimated the benefit of each capability
    (3=high, 2=medium, 1=low)

  3. calculated the SAFE-factor for each capability
    SAFE = 1/cost/benefit (SAFE varies between 0.11 and 1)

  4. excluded the capabilities already ranked along limitation ranking

  5. sorted remaining capabilities according to ascending SAFE

  6. selected capabilities with a SAFE-factor = 0.11

This results in 14 capabilites

Additional Capabilities

 At the end additional capabilities were selected that have a link to one of the above selected capabilities, since these capabilities have to realized together with the already selected capabilities in order to achieve the expected result.

This results in 18 additional capabilities.

The 54 selected capabilities (of 105, 51%) solve at least 75 limitations (of 201, 37%)

Conclusion

The 54 capabilities found cover almost all clusters

604x357px

Figure 14 - Capabilities by Clusters

Within these 54 capabilites, only capabilites for Braking Rules do not appear. Their ranking is too low to appear in the list of ranked capabilities.

When clustering the 36 main capabilities (without the related ones), the following situation shows up

604x306px

Figure 15 - Capabilities Overview

In the overview document of all capabilities (here), an even more detailed view of the capabilities and the covered limitations can be found.

Ein Bild, das Tisch enthält. Automatisch generierte Beschreibung

Figure 16 - Extract of Capability Ranking

The list of capabilities can be found here: List of Capabilities (as part of the List of Limitations). Each limitation described in this document has a link into the UML model.

Capabilities can also be found in the UML Model directly: here

Smart Services

Target Architecture

Migration Path

Retrieved from "https://rff.wiki.interconnective.ch/index.php?title=Architecture&oldid=853"