Skip to content

Welcome to the Sample Initiave Overview Map

On this page, you will find an example implementation of an IOM (Initiative Overview Map). This assumes a FIDA initiative being implemented in an insurance company.

The primary purpose of an IOM is to provide the cornerstones of an end-to-end  initiative. It is established during the preparatory phase and consistently maintained throughout all phases of the project. Typically, large projects are a collaborative effort involving distributed teams and diverse suppliers. Each of these contributors knows only a portion of the requirements. The IOM describes the big picture and encompasses all the facts about an initiative necessary for overall project management.

Please note that this page was developed using WordPress for demonstration purposes only. In real life, a sufficiently large project would require an enterprise architecture tool or a professional content management tool. This would allow, among other things, many people to work on the model simultaneously and better manage the relationships between the solution components.

Why FIDA?

FIDA is a forthcoming regulation from the European Commission, likely to come into effect in 2026 or 2027. The regulation governs the rights of customers of financial products to manage their own data. FIDA will therefore have a profound impact on the IT landscapes of all major financial institutions, including banks, insurance companies, and asset managers.

Explore Business Growth and Technical Improvement Opportunities
HU
Fulfill Requirements of FIDA Regulations
H

Description

The “Vision” section provides the most compact and concise project description. It summarizes the value the project offers to customers and the company.

Vision statements are frequently found on project manifesto posters for good reason. They provide easy-to-understand guidance and ensure that all stakeholders have a consistent understanding of the project content.

Life Cycle

Initial vision statements are developed in the inception phase. They are supplemented in the subsequent scenario assessment phase and agreed upon with all key stakeholders shortly before the project is approved and company funds are spent on implementation.

During implementation, all project decisions are continuously reviewed against the original vision statements, and the results are measured against them. To achieve this, the most important requirements for success are translated into clear and easily trackable KPIs.

Changes to the vision represent a significant realignment of the project that must be agreed upon with stakeholders.

Improved Financial Portfolio Management
Cross Vendor Portfolio Overview
Personalized Offers and Advice
U
Easy Product Comparison
U
Intuitive Product Purchase and Replacement
U
Overview of Personal Data
H
Long-standing customer
New customer
Premium long-standing customer

Description

The domain “Customer Value” answers the question of why this project is being undertaken from the customer’s perspective. This goes hand in hand with the business case, which answers the related question of why the project is being carried out from the company’s perspective.

Life Cycle

Except for purely technical optimization projects, the discussion of the customer value is at the beginning of a project in the inception phase. It is the central motivation for the project and should remain largely constant throughout all project phases.

Typically, personas and customer segments are outlined in the scenario analysis and fully developed during implementation. However, if the business case critically depends on specific customer segments and personas, how they are addressed, or how they react to the project outcomes, these must be fully developed prior to implementation.

Avoid penalty payment
H
Enhance Customer Base
U
Modernize IT landscape
H
FIDA Leader Approach
U
Minimal compliance only implementation
H
Moderate Business-driven Execution
HU

Description

The business case for a project consists of the benefits for the company and the associated costs. A distinction is made between ongoing costs (operating costs) and one-time costs (investments). When deciding on a project, various scenarios with different benefit profiles are typically considered – e.g., high benefits with high investments and lower benefits with lower investments.

Life Cycle

The business case is developed as the result of the scenario assessment phase. It is linked, on the one hand, to the expected values for the company and customers, and, on the other hand, to the project’s outcome—i.e., the deliverables with their associated costs, and schedule.

During the implementation phase, the project delivers its results. If assumptions regarding the costs of a deliverable or the schedule need to be adjusted, the business case must also be adjusted. Therefore, traceability of the key success factors is of utmost importance for project success and is monitored throughout implementation.

What will be delivered?

123

FIDA Core
Customer Dashboard
H
Access Dashboard
H
View Customer Data
H
Permit Customer Data Access
H
Revoke Customer Data Access
H
Monitor Access Rights
H
Delete Customer Data
H
Scheme Administration
HU
Legal Scheme Participation
HU
Technical Scheme Management
HU
Business Continuity Arrangements
HU
Critical Operations Documentation
HU
ICT Continuity Strategy and Plans
HU
ICT Response and Recovery Plans
HU
Review and Effectiveness Process
HU
Pricing
Miscellaneous
HU
Customer Data Exchange
Make Customer Data Available
H
Transfer of Customer Data
H
Notify on Exchanged Data Change
H
Customer Approval for Exchange
H
Delete Exchanged Data
H
FIDA Scheme 1 Requirements
FIDA Scheme 2 (or even more) Requirements
Non-Mandatory Data Holder Requirements
Improve Data Quality
H
Modernize Customer Portal Landscape
H
Modernize API Infrastructure
H
Non-Mandatory Data User Requirements
360° Finance Control
U
Cross Selling
U
Upselling
U
Customer Retention
U
Non-Profitable Contract Termination
HU
Operational Organization
Additional Regulations
Company Policies
HU
European Regulations
PSD3 / PSR (Payment Services Directive 3 and Regulation)
HU
GDPR (General Data Protection Regulation)
HU
eIDAS / EUDI Wallet (EU Digital Identity)
HU
DORA (Digital Operational Resilience Act)
HU
NIS-2 Directive (Cybersecurity Directive)
HU
DA (Data Act)
HU
CRA (Cyber Resilience Act)
HU
CER Directive (Critical Entities Resilience)
HU
National Regulations (Germany)
HU
BaFin-Rundschreiben
Datenschutzrecht (GDPR + BDSG)
IT- und Sicherheitsrecht (BSIG, NIS2UmsuCG, DORA)
Kreditwesengesetz (KWG) und Versicherungsaufsichtsgesetz (VAG)
Verbraucherschutzrecht (BGB, UWG)
Zahlungsdiensteaufsichtsgesetz (ZAG)
National Regulations (Sweden)
HU
Technology
IAM (Identity & Access Management)
HU
API Management
HU
Customer Portals
H
Data Governance Frameworks
HU
Data Transformation
HU
Integration Frameworks
HU
Legal Contract Management
H
Data Sources
H
Political Environment
FIDA Requirements are stable
FIDA schedule is stable

Description

The “Requirements” section describes the most important constraints and requirements for a project as a whole. In particular, it formulates those central requirements whose non-fulfillment would lead to dealbreakers—i.e., the failure of the project. Detailed requirements, e.g., for individual project steps, are processed and recorded separately in the individual teams.

Life Cycle

Requirements are captured throughout the project life cycle as knowledge about the topic grows. However, important requirements that have a significant impact on the structure of the solution must be known before the implementation phase begins.

However, it may happen that project areas cannot be clearly defined until well into the implementation phase. This uncertainty should be explicitly addressed in the solution development process—for example, by using exploratory techniques such as design thinking.

Avoid treating all areas of the project equally out of convenience. Where a high degree of certainty exists, solid planning should be used, while exploratory approaches should be taken in areas of uncertainty.

FIDA core use cases as data holder
Customer configures data access
H
Customer allows data access for individual data user
H
Customer allows data access for insurance contract
H
Customer permits unrestricted data access
Customer prohibits any data access
Customer inspects own data
H
FIDA core use cases as data user
Customer requests portfolio optimization via intermediary
U
Customer successfully requests portfolio optimization
U
Request portfolio opimization but customer answers delayed to an individual consent request before a partial offer was created by intermediary
U
Request portfolio opimization but customer answers delayed to an individual consent request after a partial offer was created by intermediary
U
Request portfolio opimization but customer answers delayed to an individual consent request after a partial offer was created by intermediary and after parts of the partial offer have expired
U
Request portfolio opimization but customer does not answer to one individual consent request
U
Request portfolio opimization but customer does not answer to any individual consent request
U
Request portfolio opimization but customer rejects all individual consents
U
Request portfolio opimization with but customer rejects one individual consent
U
Request portfolio opimization but customer revokes data access rights before answering individual consent requests
U
Request portfolio opimization with insufficient data access rights for all contracts
U
Request portfolio opimization with insufficient data access rights for one contract
U
Value added use cases as data holder
Customer is urged to transfer not profitable contract to competitor
H
Customer receives offer for portfolio gap during data inspection
H
Customer receives offer for portfolio gap as a replacement for a policy of a competitor
H
Customer receives offer for portfolio gap via ordinary sales after request
H
Customer receives offer for portfolio gap in real-time
H
Customer receives up-sell offer for portfolio item while inspecting data
H

Description

In the “Business Solution” section, we describe use cases, processes, business objects, capabilities, and functions. Not all of these abstractions are relevant to all projects. Instead, we consider those that best fit the nature of a project.

A “business solution” can be described in any depth, and this is often necessary—for example, when introducing a completely new process, every single step must be worked out. However, this is not the scope of an overview model; instead, we focus on those facts that are relevant to project management and the solution’s architecture.

Life Cycle

The rough overview of the business solution is developed in the scenario assessment phase in order to derive all solution components and estimates. This can be achieved, for example, by focusing on use cases (or similarly, on business events, or business services). Techniques such as functional decomposition or domain storytelling or event storming can help you create a complete overview of your project. However, details are omitted during this phase.

Implementation is often organized into releases with multiple interim deliveries within each release, for example, in the form of agile sprints. To plan each release, the relevant part of the overview model is further broken down into finer parts to form the basis for development planning.

Description

The “Application” section contains software systems and their sub components such as applications, application components, data objects, and interfaces.

Typically, all of these elements are included in enterprise-wide architecture documentation. If this is the case, only core data and a reference to it are required. Even if a project introduces a new application, the enterprise architects should include it in their documentation.

The elements in the applications section are linked to elements of the business solution, for example, to indicate which new features they should receive or which features are used by a project.

They are linked to the elements of the infrastructure section to indicate how they are physically implemented.

Life Cycle

The list of required applications is developed in the scenario assessment. This is necessary to involve the respective application owners in the cost estimates and verification of the overall solution concept.

Interfaces and data are designed as part of the release planning during the implementation phase.

Description

The Infrastructure section describes the physical runtime for the application layer elements of a project, including compute nodes, storage, and networking.

Life Cycle

Unless infrastructure is the main focus of the project, only a very rough outline and a cost estimate are required in the scenario assessment.

The detailed design takes place during implementation, as only then is sufficient information available for a good design, especially for appropriate sizing.

How the goal will be achieved?

123

Earvin Johnson

Chief Compliance Officer

Example Inc.

Ronnie o‘Sullivan

Chief Customer Data Officer

Example Inc.

Sachin Tendulkar

Head of Sales

Example inc.

Serena Williams

Chief Information Officer

Example Inc.

Wayne Gretzki

Project Lead Customer Satisfaction

Example Inc.

Franz Beckenbauer

Chief Architect

Example inc.

Marta Vieira da Silva

Requirements Lead FIDA

Example Inc.

Nicki Lauda

Project Lead FIDA

Example Inc.

Roger Federer

Solution Lead FIDA

Example Inc.

Tiger Woods

Team Lead Silo "Tiger"

Example Inc.

Tom Brady

Team Lead Silo "Brady"

Example Inc.