Difference between revisions of "Architecture"

From RFF Wiki
Jump to: navigation, search
(→‎Non-functional Requirements)
(→‎Limitations)
Line 165: Line 165:
  
 
= Limitations =
 
= Limitations =
 +
 +
When talking about limitations, we are in the '''World of Problems'''.
 +
 +
Based on the description of the current systems with its [[Architecture#Business Objects|business objects]] and [[Architecture#Workflows|workflows]] the limitations of todays systems can be analysed by making use of the [[Architecture#Perspectives|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
 +
## duplicates are eliminated (in the spreadsheet)
 +
## 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 ===
 +
 +
<blockquote>Problem Area (PA)
 +
</blockquote>
 +
{|
 +
! '''If the limitation belongs to problem area'''
 +
! '''then the score is'''
 +
|-
 +
| Data Quality
 +
| 3
 +
|-
 +
| Coverage (Governance)
 +
| 2
 +
|-
 +
| Functionality / Business Processes
 +
| 1
 +
|}
 +
 +
<blockquote>Level (L)
 +
</blockquote>
 +
{|
 +
! '''If the limitation belongs to level'''
 +
! '''then the score is'''
 +
|-
 +
| L1
 +
| 3
 +
|-
 +
| L2
 +
| 2
 +
|-
 +
| L3
 +
| 1
 +
|}
 +
 +
<blockquote>Dependencies (D)
 +
</blockquote>
 +
{|
 +
! '''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
 +
|}
 +
 +
<blockquote>Value Added (V)
 +
</blockquote>
 +
{|
 +
! '''If impact of the limitation is'''
 +
! '''then the score is'''
 +
|-
 +
| big
 +
| 3
 +
|-
 +
| medium
 +
| 2
 +
|-
 +
| small
 +
| 1
 +
|}
 +
 +
<blockquote>Effort (E)
 +
</blockquote>
 +
{|
 +
! '''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) +<br />
 +
(Score D * Weight D) + (Score V * Weight V) +<br />
 +
(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
 +
 +
[[File:media/image13.png|604x283px|Ein Bild, das Tisch enthält. Automatisch generierte Beschreibung]]
 +
 +
When looking at the coverage of the various clusters, the following picture shows up:
 +
 +
[[File:media/image14.png|604x284px]]
 +
 +
<span id="_Toc56062984" class="anchor"></span>Figure - Coverage by Cluster
 +
 +
[[File:media/image15.png|325x207px]]
 +
 +
<span id="_Toc56062985" class="anchor"></span>Figure 12 - Coverage by Basic Principles
 +
 +
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: [[Documents/Evaluation_Criteria_Limitations.pptx|Criteria for Limitations]]
 +
 +
The list of limitations can be found in the following spreadsheet: [[Documents/List_of_Limitations_Capabilities_NFR_SAFE.xlsx|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
 +
 +
<span id="_Capabilities" class="anchor"></span>
  
 
= Capabilities =
 
= Capabilities =

Revision as of 10:31, 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

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

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

604x284px

Figure - Coverage by Cluster

325x207px

Figure 12 - Coverage by Basic Principles

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

Smart Services

Target Architecture

Migration Path

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