Difference between revisions of "Architecture Roadmap"
Line 2: | Line 2: | ||
Today, each participant in the railway business has to connect itself to a variety of tools and platforms in order to exchange information with other participants. | Today, each participant in the railway business has to connect itself to a variety of tools and platforms in order to exchange information with other participants. | ||
− | [[File:Platform_today.png|border]] | + | [[File:Platform_today.png|border|600px]] |
= Pilot = | = Pilot = | ||
Instead of decomposing and rebuilding todays available and proven platforms and tools a hub could be built up that hides todays platforms and tools and provides unique access in one place. The functionality of the hub can be reduced for small RUs and can provide various interaction possibilities for large RUs. | Instead of decomposing and rebuilding todays available and proven platforms and tools a hub could be built up that hides todays platforms and tools and provides unique access in one place. The functionality of the hub can be reduced for small RUs and can provide various interaction possibilities for large RUs. | ||
− | [[File:Platform_pilot.png|border]] | + | [[File:Platform_pilot.png|border|600px]] |
The advantages of this pilot are: | The advantages of this pilot are: | ||
Line 25: | Line 25: | ||
Once the basic facility services are established, the underlying platforms and tools can be decomposed into lean services and new smart services can be added. | Once the basic facility services are established, the underlying platforms and tools can be decomposed into lean services and new smart services can be added. | ||
− | [[File:Platform_evolution.png|border]] | + | [[File:Platform_evolution.png|border|600px]] |
In order to take the preferable out of the existing platforms, tools and systems, the best of all of todays applications can be selected and new smart services be built around this best breed. | In order to take the preferable out of the existing platforms, tools and systems, the best of all of todays applications can be selected and new smart services be built around this best breed. |
Revision as of 09:27, 30 June 2021
Status Quo
Today, each participant in the railway business has to connect itself to a variety of tools and platforms in order to exchange information with other participants.
Pilot
Instead of decomposing and rebuilding todays available and proven platforms and tools a hub could be built up that hides todays platforms and tools and provides unique access in one place. The functionality of the hub can be reduced for small RUs and can provide various interaction possibilities for large RUs.
The advantages of this pilot are:
- Fast integration of available platforms and tools
- One single "Point of Contact" for RUs to exchange information
- Independence of the participants from changes in the underlying platforms and tools
- Gathering experience with the technical partner competences and services
After the first step
- the MARS pilot service and
- the technical platform POC
are developed.
- MARS Architecture step 1
Platform Marketplace
Once the basic facility services are established, the underlying platforms and tools can be decomposed into lean services and new smart services can be added.
In order to take the preferable out of the existing platforms, tools and systems, the best of all of todays applications can be selected and new smart services be built around this best breed.
The RU RFF community has a bunch of opportunities and unique selling propositions to build up such an integrated platform:
- Best Governance
- CEO Integration
- EU Lobbying
- 450 Members
- Long Term Experience (25 years +)
- All major use cases covered
- agile and flexible approach
- modern IT platform
At the end of step 2 the platform will be ready to serve as marketplace.
- MARS Architecture step 2
Platform Innovation
In the third step the innovation cycle will be added to attract potential smart services.
- MARS Architecture step 3
RU Integration
After the pilot phase the hub becomes the stable RU interface in three flavors for the A, B and C type RUs (-> Glossary) demands. It offers
- one
- reliable,
- stable
interface for the specific demand of each RU type. It forms a Facade for the RU data exchange.