SAP GUI vs SAP Fiori – A Comprehensive Guide

Initial Question of Preference: SAP Fiori vs SAP GUI

Since both the SAP GUI, which has been available for decades, and SAP Fiori, which began development in the mid-to-late 2000s and was released with SAP S/4HANA, have been central topics in the SAP community, the choice between the two has been a key consideration.

SAP GUI represents the historical and legacy power of SAP, while SAP Fiori introduces the company’s move towards a modern and user-friendly interface.

• SAP GUI is primarily used by power users or IT administrators. It is complex, but more customizable and faster, providing multi-screen transactions, configurations, and in-depth system analysis.
• SAP Fiori is primarily designed for end-users, focusing on simplicity, mobility, and efficiency with minimal training requirements.

SAP’s Shift Toward Modern, User-Centric UIs

SAP GUI has served as the foundational user interface for SAP ERP systems for decades. SAP’s primary focus was on the functional capabilities of backend systems. Its stability, maturity, and reliability have made it a tool of choice for the world’s largest companies.

The traditional SAP GUI, a functional, desktop-based interface, was designed to manage complex and high-volume transactions. It provided detailed screens, layered menus, and transaction codes to support intricate business processes. However, the user experience was not a priority. Expert users have long relied on transaction codes (T-codes) to quickly navigate to the necessary components for efficient data entry.

Despite its robust functionality, SAP GUI lacks support for mobile devices and modern web browsers, rendering it outdated in today’s mobile-first environment. With shifting workforce expectations and technology trends, SAP began to move from a technology-centric approach to a human-centric approach. This transition was driven by growing demand for beautifully designed, intuitive apps, particularly for mobile devices and tablets.

Businesses are no longer limited to work desks. For example,

• Salespeople may need to check stock inventory while on the road,
• Managers often need to approve purchase requests on the go.
• Warehouse workers now use tablets instead of desktops to perform tasks efficiently.

To address these needs, SAP introduced SAP Fiori. This design system offers web-based, role-based, simple, user-centric, and responsive design applications that function seamlessly across mobile devices, tablets, and desktops. While SAP is investing heavily in the Fiori framework as the future of its user experience, SAP GUI is not being phased out entirely. It continues to be actively enhanced and maintained across its Windows, HTML, and Java versions, as many companies still depend on legacy SAP systems with classic Dynpro-based applications.

Importantly, SAP GUI and Fiori continue to co-exist. Fiori serves as a central access point, allowing users to launch both Fiori apps and traditional SAP GUI transactions.

Additionally, the release of S/4HANA, SAP’s next-generation ERP suite, created an opportunity to rethink and rebuild the user interface from the ground up, fully embracing a modern design philosophy.

Why UI Modernization Matters in Enterprise Systems

UI modernization is not just about making components look visually appealing. It has a direct impact on several factors, such as:

• Increased user adoption, such as making the system easy to use, preventing users from creating workarounds, e.g., spreadsheets, leading to inaccurate data.
• Reduced navigation steps and training costs,
• Increased productivity via mobility support,
• Lower error rates,
• Improved employee satisfaction.

Technological Evolution and Foundations

SAP’s user interface has undergone numerous technological developments, from desktop-based clients to web-based, flexible platforms. Let’s dive into this evolution from complex UI design to a mobile and browser-friendly user-centric design.

Origins and Architecture of SAP GUI

SAP GUI has served as the primary user interface for SAP software since the inception of the SAP R/3 system. R/3 introduced a pioneering client-server architecture, comprising three layers: Presentation, Application, and Database.

SAP GUI functions as the front-end or presentation layer, where users interact with the system through ABAP Dynpro-based screens.

This layer communicates with the application server or application layer, the system’s core backend, which handles the execution of business logic and processes user requests. In turn, the application layer interacts with the database layer, which handles data storage and retrieval.

Communication between the presentation and application layers is facilitated via Remote Function Calls (RFC) and DIAG protocol, enabling efficient data exchange and remote procedure execution.

At the time of its production in the 1990s, this architecture was revolutionary, enabling distributed computing and centralized data management. It allowed enterprises to scale their operations while maintaining control over core business processes. However, the need to install SAP software on individual desktop systems presented a limitation, especially as web-based applications and browser-accessible platforms gained popularity.

Web Dynpro (ABAP & Java): SAP’s Early Web UI Attempts

At the height of the internet in the 2000s, during the initial development of the SAP NetWeaver era, SAP recognized the need for a web-based user interface. This led to the development of UI technology, Web Dynpro, as early as 2003, based on HTML standards, which generated the necessary JavaScript, HTML, and CSS to render the UI in the browser.

SAP has released two variants of Web Dynpro: Web Dynpro for Java and Web Dynpro for ABAP. Web Dynpro supports the Model-View-Controller (MVC) architecture, which separates the user interface (View) from the business logic (Model) and the control flow (Controller). This was a crucial step toward a more structured approach to UI development compared to traditional screen-based Dynpro technology. However, while Web Dynpro allowed developers to build web-based applications, it remained a complex model. The user experience felt like a basic web version of SAP GUI rather than a modern UI, lacking mobile responsiveness and feeling outdated very quickly.

Rise of SAPUI5 and Foundation of SAP Fiori

With the increasing demand for modern, responsive, and web-based user interfaces, SAP took a significant step forward in 2013 by introducing SAPUI5 and SAP Fiori, marking a substantial shift from the traditional SAP GUI experience.

SAPUI5: The Technological Foundation

The introduction of SAPUI5 marked a strategic move toward a modern web experience. SAPUI5 (SAP User Interface for HTML5) is a development framework designed to build responsive and enterprise-grade web applications.

At the heart of SAPUI5 is HTML, a web standard that provides rich features for web applications. HTML5-based applications can run on modern web browsers, regardless of the operating system or device type, including desktops, smartphones, and tablets.

SAPUI5’s key characteristics include:

• Client-side framework. Comparable to modern libraries like React or Angular, SAPUI5 runs in the browser and enables rapid UI development.
• Standards-based. Built on HTML5, CSS3, and JavaScript, ensuring compatibility and modern web practices.
• MVC architecture. It utilizestheModel-View-Controller (MVC) pattern to facilitate the development and modification of the user interface, data visualization within the application, and code for business logic processing, thereby improving data readability, maintainability, and extensibility.
• Rich feature set. Offers over 180 UI controls, enabling the development of highly interactive and data-rich user interfaces.
• Communication protocols. Integrates with SAP backend systems using Open Data Protocols (OData), a RESTful, standardized protocol for data exchange.

SAPUI5 is also a core technology underpinning several SAP platforms, including SAP S/4HANA and SAP Business Technology Platform (BTP).

SAP Fiori: The Design Paradigm

SAP Fiori is not a technical framework, but a design language that defines how an SAP application UI should behave and appear. It brings:

• Role-based interfaces. Apps are tailored to specific user roles and workflows, increasing relevance and productivity.
• Consistent design principles. Provides a cohesive look and feel across applications by following well-defined UI/UX guidelines.
• Responsive and intuitive UX. Focuses on simplicity and ease of use.
• Foundation in SAPUI5. All Fiori applications are developed using SAPUI5, ensuring a seamless integration of design and technology.

Together, SAPUI5 and SAP Fiori represent a unified approach to modern SAP application development. SAPUI5 provides the technical layer, and SAP Fiori provides the design and user experience layer. This combination enables the development of applications that are not only technically robust but also user-centric and future-ready.

Summary and Visual Flow of the Evolution

SAP GUI (1990s) ➔ Web Dynpro (2000s) ➔ SAPUI5 (2013) ➔ SAP Fiori + Mobile-First UI

• 1990s – 2000s, key technology as SAP GUI (Dynpro), thick client architecture, transaction-based, expert-focused with dense information design.
• 2000s – 2010s, key technology as Web Dynpro, server-side rendering architecture, web-based design.
• 2010s – Present, key technology as SAPUI5/Fiori, client-side rendering architecture, OData, open standards, role-based, responsive, user-centric, and mobile-first design.

SAP GUI vs Fiori: Design Philosophy and UX Principles

SAP GUI vs Fiori is a fundamental evolution in design philosophy and UX principles, not just a technological change. Let’s explore the points based on both designs.

Differences	SAP GUI	SAP Fiori
Core design principles	The primary goal of SAP’s GUI was to provide every function, such as buttons, menus, and data fields of an object on the screen, often mirroring the database structure and business process logic, with a focus on data entry and transactional efficiency for expert users. The system was built for power users, who spend 8 hours performing repetitive tasks such as order entry, requiring speed via keyboard shortcuts or memorized T-codes. Extensive training was necessary to learn the software. The UI is powerful once fully understood, but it is very complex, non-intuitive, and visually unappealing to end users, making it functional but outdated in appearance.	SAP Fiori’s design goals are user-centric, tailored to specific job roles, simple in nature, and responsive across all devices. Each app is designed to address a single task, making it easily understandable without requiring extensive training. Fiori launchpad displays tasks as tiles, eliminating the need for users to memorize codes and creating a clear visual hierarchy. Information is shown on cards and dashboards, reducing clutter by focusing on a single task per app and removing unnecessary functions or fields. This allows users to concentrate on their task without distraction. SAP Fiori UI designs follow Steve Krug’s principles of “Don’t Make Me Think,” which emphasize that users should easily navigate a web application or website without pausing to think about how elements function, such as transaction codes, navigation, or fields.
Contrast, screen layout, and visual clarity comparisons	The SAP GUI screen layout features a dense arrangement of buttons, input fields, tabs, and other elements stacked on top of each other, forming a rigid grid system that makes the screen appear crowded. Visual clarity is poor due to the large amount of information displayed using the same UI elements. Additionally, the color palette is limited to shades of gray with low contrast. Although the blue crystal theme is also available, companies mostly stick to the default, which can cause a lack of visual hierarchy.	The layout of Fiori screens is based on cards and tiles, featuring modern typography with a range of colors to be selected. Critical data is presented within the cards or in charts. It features a high contrast between the background and text, utilizing color indicators such as green for success and red for alerts or critical information, which enhances readability and visual clarity.
GUI speed and minimal clicks vs. Fiori’s layered navigation	SAP GUI is quick for an expert SAP power user who knows transaction codes such as VA01 for creating a sales order or MM01 for material master record creation and can directly access the required screen instead of navigating through complex menus or memorizing shortcuts for executing specific tabs, which results in minimal clicks to reach a known screen or workflow.	SAP Fiori navigation is built on a tile-based layered approach. The user starts with the Fiori Launchpad, which features dashboard tiles. They click on the required tile, such as Manage Purchase Orders, and then select a specific item to access its object page with details. While this layered navigation is intuitive for most users, it may feel like an additional step for power users familiar with T-code execution.
ALV Lists vs. Object List Reports	The ABAP List Viewer (ALV) in SAP GUI is highly functional, providing data in a dense grid and offering options for filtering, sorting, and exporting. This enables developers and power users to access data with high density, flexibility, customization of layout, and even basic calculations.	Fiori replaces ALV with Fiori List Reports, presenting data in a responsive table with intelligent search and filtering capabilities. Users can select a line item, which directs them to its corresponding object page, where details are presented in a structured and easy-to-read format.
Frustrations: scrolling, slow search, missing T-codes	SAP GUI’s screens are usually long, and users must scroll horizontally and vertically to view all fields and columns, especially on small screens.	Search functionality is available in both the GUI and Fiori, but it can be slow for large datasets, and users often struggle to find a specific record due to the time it takes to process the data. SAP Fiori lacks T-code functionality; users must search for a screen or app, which is a hindrance for power users who are familiar with the extensive features that have been added over the years. As a result, these aspects lead to a time-consuming and frustrating experience.
Subjective ergonomics: keyboard vs. mouse-driven input	SAP GUI is primarily keyboard-driven, especially for accountants and data entry clerks who spend hours entering numbers and text. Utilizing keyboard shortcuts, such as function keys from F1 to F12, tabs, or T-code entry, reduces the need for switching between keyboard and mouse.	SAP Fiori is designed for modern interactions, such as mouse-driven and touch gestures. Tile-based navigation, simplified screens, and clear buttons are more usable on a pointing and touch-based device, such as a manager who needs to check a status or approve a request, allowing them to use mobile or tablet devices or a mouse click.

Consultant and End-User Observations

When discussing SAP GUI or SAP Fiori, those who use the system daily share crucial insights through their practical experiences and observations.

Consultant Preferences: GUI for Speed and Depth

SAP consultants with a long history in the SAP world often prefer the SAP GUI for its speed and their work-related, in-depth exploration of the systems for troubleshooting, complex configurations, and access to a wide range of functionalities.

Extensive knowledge of hundreds of transaction codes enables easy navigation in the system, requiring only a few keystrokes, rather than navigating through complex menus. This approach feels faster than clicking through the Fiori launchpad and layered screens.

End-User Feedback: Fiori Adoption Among Non-GUI Natives.

End-users new to SAP Fiori, those who are not native GUI users, or those interacting with the system less frequently, have a different perspective. They value the intuitive design of Fiori, which provides quick access to relevant apps with minimal training requirements. They no longer need to navigate through complex menus to find a simple function. For example, a sales representative can easily click on a tile to create a sales order rather than memorizing transaction codes or navigating complicated menus. The same salesperson in the field can utilize Fiori’s mobile accessibility to perform tasks such as checking inventory, which is not possible with SAP GUI.

Industry Experience: Onboarding, Training, and Role-Specific Success.

With SAP GUI, the onboarding process in an organization required extensive training on screen layouts, menus, and transaction codes, which is now reduced with SAP Fiori. Training can be simplified and focused more on specific tasks or apps relevant to the user’s role, with a focus on business processes rather than technical navigation. However, power user roles, such as financial accountants who require performing month-end closing or logistics specialists who need to manage hundreds of stock movements per day, may still need SAP GUI for repetitive, keyboard-driven tasks.

Fiori Implementation Challenges

Although SAP Fiori provides a greater user experience, a beautiful Fiori UI is useless if the implementation is not proper. Fiori’s implementation in complex environments presents technical challenges and greatly depend on organizational structure, change management, and governance.

Complexity of Launchpad Setup and Configuration

The SAP Fiori launchpad acts as the central hub for SAP applications, offering high configurability that provides flexibility but can also create complexity.

The core setup revolves around managing catalogs, roles, groups, tiles, and pages.

• Catalogs are a collection of applications, including tiles and their mappings to targets.
• Groups define how tiles are organized on the user’s launchpad, offering a personalized view.
• Roles link users to the appropriate catalogs and groups. In large-scale implementations with hundreds of roles and applications, this relationship can become intricate and challenging to manage.

Fiori typically employs a decoupled architecture, comprising:

• A Front-End Server (FES) that contains UI components.
• A Back-End Server (BES) where business logic and data reside.

Setting up Fiori may require the coordination of developers, the security team, and functional consultants, as well as extensive skills in SAPUI5, ABAP, and Fiori, to configure the Fiori Launchpad.

Finally, each tile must be correctly connected to backend services such as OData, Web Dynpro, or classic SAP GUI transactions.

Slowness with Too Many Roles and Tiles

Poor configurations can lead to Fiori Launchpad performance, create slowness, and frustrate users:

• Every tile on the launchpad needs technical linking with the backend call to fetch data, especially dynamic tiles.
• Launchpad could become cluttered with too many dynamic tiles, which can cause a delay in loading time on a slow network.
• Role proliferation is another frequent problem. Too many roles for authorization management can also cause large numbers of tiles to be loaded in the background, impacting performance. The system can become slow and unresponsive without proper performance monitoring and fine-tuning.

Role Proliferation and App Overload

Fiori’s design is based on simplicity principles, but it can produce chaotic user experiences in large organizations without a strong governance model for the Fiori content.

If a clear strategy for apps, catalogs, and roles is not defined for Fiori Launchpad, it can become a cluttered UI with numerous unnecessary tiles.

An organization may have multiple micro roles for app management per user; these business roles should be mapped to catalogs and groups. Otherwise, it can lead to role proliferation, SoD violations, and overload the app for end users. Users may not have access to the apps they require.

Organizational Readiness and Change Management

This could be the biggest challenge in an organization, not related to technicality, but resistance to change. Users, especially power users who may have spent years learning the SAP GUI T-codes and keyboard shortcuts, may be resistant to change, resulting in low adoption, complaints, or a decline in productivity. Without proper management, they may revert to SAP GUI.

Appropriate training and communication should be provided by management to help users understand the new interface and its benefits in their daily work, such as a mobile-first approach for smartphones and tablets. Training should cover Fiori Launchpad and new Fiori apps. Users should be engaged in the design and testing phases, collecting their feedback, etc.

Read More

Comprehensive List of SAP Fiori T-Codes

Security, Maintenance, and Governance

Security in SAP has traditionally been managed using roles in the backend. Access is granted to specific T-codes and authorization objects. In SAP Fiori, this process involves catalogs and roles.

Security Design and BSR Mapping Challenges in Fiori

Mapping business roles to Fiori apps (BSR Mapping) is a security challenge.

• You cannot just assign a list of apps to someone. Fiori Launchpad and every Fiori app should be configured correctly to connect to backend services. Users may see a tile but get an error upon launch if the authorization mapping is not implemented correctly.
• Business role mapping requires collaboration between process owners, Fiori developers, and the security team. Without coordination, it can lead to broken apps and users’ frustration, and may not respect segregation of duties principles.

GUI’s Centralized Control vs. Fiori’s Distributed App Model

In SAP GUI, security is straightforward:

• It’s controlled centrally via user roles,
• Users are granted access to a limited number of executable transactions.
• Upon user login, the GUI client interacts directly with an application server, where authorization checks are enforced through backend authorization objects.

This centralized model simplifies administration and provides a single point of control for security management.

In contrast, Fiori’s distributed app model introduces a more layered and decentralized security architecture:

• It employs a front-end server (FES) and back-end server (BES)
• Security involves OData services, roles, and Fiori catalogs.
• Each OData service needs its authorization checks, and roles must explicitly grant access to these services.
• Business catalogs must align precisely with the user’s roles to ensure the correct tiles appear on the Launchpad and function properly.

This introduces a three-layer security model (tile -> OData service -> backend authorization), compared to SAP GUI’s two-layer model (GUI transaction -> backend authorization).

Maintenance Overhead: UI Fragmentation, Role Tailoring.

Fiori apps can be simpler for user experience, but can increase maintenance overhead for security teams. Organizations may end up using a mix of different UI technologies, such as classic GUI transactions, Web Dynpro applications, and Fiori applications. This UI fragmentation leads to the support of multiple development frameworks for maintenance teams, resulting in increased complexity and maintenance costs. Role tailoring can lead to role proliferation if not correctly managed; a change in a user’s role can result in updates to corresponding roles, groups, and catalog assignments.

Trade-offs Between Flexibility and Simplicity

SAP’s UI evolution often represents a constant choice negotiation between simplicity and flexibility.

• SAP GUI provides in-depth flexibility. It can handle any business process without considering complexity, but lacks simplicity, and users must eventually adapt to the design.
• SAP Fiori, on the other hand, offers simplicity and usability with a role-based, clean interface, but it comes with some trade-offs. Fiori apps can be subsets of relevant SAP GUI transactions, which promotes simplicity; however, they can cause frustration if a user cannot find a missing field and has to revert to the GUI.
• SAPUI5 and Fiori elements offer extensibility, which can lead to specialized development skills, but also introduce a maintenance burden. Simplicity can be lost if a heavily customized system fails to meet business requirements. Context can be lost due to the layered Fiori navigation approach if the user cannot quickly switch between different objects, which is common in the SAP GUI for power users working with multiple screens open.

SAP GUI vs Fiori – Role-Based Interfaces and Personalization

The shift from SAP GUI to SAP Fiori represents a transition from a system-centric design to a user-centric design, particularly in the handling of user roles and personalization, which impacts usability.

Fiori’s App-based Role Management

Role management is the core part of SAP’s Fiori design philosophy. Fiori Launchpad displays users with a set of tiles and apps relevant to their job functions, rather than the SAP GUI’s generic menus, which show every possible transaction.

Fiori Launchpad can be personalized by end-user transaction tile groups, role-based design, and apps labeled with business-friendly process names, allowing users to find and launch the proper function without needing to know the underlying transaction codes. The fundamental principle of Fiori’s app-based role management approach is that users should only see what they require to perform their jobs.

GUI’s Menu Structure and Personalization Tools

SAP GUI offers personalization features, but they are more technical and less user-friendly than those in SAP Fiori.

• It provides a hierarchical menu tree with multiple folders and transactions, which can be customized but requires extensive knowledge.
• A Favorite folder is available where users can add frequently used T-codes.
• GUI’s layout, such as theme, color, and font size, can also be changed, but cosmetic changes do not change the underlying complexity or structure of screens.
• SAP GUI does not provide a role-based view, even with the backend roles implemented, users still see the full menu tree and must find relevant transactions.

SAP GUI vs Fiori: Developer Experience and Technical Shifts

The developer experience has fundamentally changed with this technical shift from SAP GUI to SAP Fiori, which has also transitioned the development model from being tightly coupled with SAP’s proprietary systems to a more open, component-based, and standardized approach.

Transition from ABAP Workbench to Eclipse and Web IDEs

The ABAP Workbench has been a primary development tool for SAP GUI development. This integrated development environment provides direct access to the backend system for creating programs, screens, and data dictionaries.

Fiori has introduced a new generation of development tools: Eclipse with ABAP Development Tools (ADT). It offers features missing in Workbench, such as advanced code completion and refactoring tools.

SAP Business Application Studio (BAS) and SAP Web IDE are modern, browser-based front-end development tools that enable creating Fiori apps using JavaScript, HTML5, and CSS3, thereby separating front-end development from back-end development.

New Developer Requirements: JavaScript, OData, Annotations

The evolution from traditional SAP GUI and ABAP Dynpro to modern SAP Fiori applications introduces a significant technological shift for developers. Adapting to this change requires mastering new tools, frameworks, and design paradigms that center around web development and service-based architecture.

Front-End Development: JavaScript and SAPUI5

• JavaScript is the primary language used for building Fiori-based user interfaces via the SAPUI5 framework.
• TypeScript , a superset of JavaScript, is increasingly adopted for Fiori development due to its enhanced tooling and type safety.

Developers must now be proficient in client-side technologies and understand the fundamentals of modern web development.

Backend Integration: OData Services

• Fiori applications connect to the SAP backend using OData services , replacing the earlier reliance on RFCs and BAPIs.
• Backend developers must design and expose these OData services to enable communication between the UI and SAP’s business logic and data.

Declarative UI Design: CDS Views and Annotations

Core Data Services (CDS) and annotations simplify the development of Fiori elements applications (e.g., List Report, Object Page).

Using annotations, developers can:

• Define UI layout and behavior.
• Set field labels and presentation logic.
• Minimize the need for custom front-end coding.

Key Mindset Shift for Developers

• Move from procedural ABAP development toward a model-driven and metadata-based approach.
• Embrace service orientation, where data and UI definitions are modular and decoupled.
• Collaborate closely with UX designers, architects, and functional teams to ensure alignment with the Fiori design principles.

Separation of Frontend and Backend Responsibilities

The separation of front-end and back-end duties is the most significant shift with SAP Fiori, where Fiori Launchpad and apps utilize a front-end UI layer that runs on a dedicated Front-End Server (FES) and handles presentation logic and user interaction.

Core business logic and data reside on the Back-End Server (BES), which exposes data using OData services, CDS Views, and RAP model. This separation offers several benefits, including independent lifecycle management. Both ends can be patched separately without affecting each other.

Architecture enables enhanced security, such as a firewall that can be installed between the frontend and backend, allowing both systems to be scaled independently based on their respective loads.

Coordination Challenges Across Development Teams

Although providing many benefits in the form of separation of duties, it can introduce coordination challenges that were not present with ABAP Workbench.

ABAP developers can be both front-end and back-end developers, which is now divided into skilled front-end and back-end developers in separate teams, such as dedicated front-end developers with SAPUI5 expertise and proficient developers in ABAP, OData, and CDS.

Clear communication is essential between both teams to ensure a smoother and more functional process. Any changes to the service, such as the addition of a new field or changes to data types, could break the front-end application if not properly coordinated.

Smart Controls, Templates, and Fiori Elements

SAPUI5’s set of Smart Controls, templates, and Fiori elements represents the most significant leap in developer experience, designed to enhance the UI development process by moving away from SAP GUI’s freestyle UI development to a metadata-driven approach.

Smart Controls: Metadata-driven UIs

SAPUI5 provides a category called Smart Controls, which automatically fetches data from the backend OData service to render UI, known as a metadata-driven UI approach.

Developers bind Smart Controls such as Smart Field, Smart Table, Smart Filter Bar, Smart Form, or Smart Chart to an OData entity instead of manually defining every field, control, or label in their UI code. The control then reads OData metadata, including annotations, and determines the data type, labels, value help, input fields, or read-only status, providing enhanced filtering, sorting, and grouping. This dramatically reduces the amount of time and frontend code for developers, allowing them to focus on business logic rather than on UI improvements.

UI Annotations: Controlling App Behavior without JavaScript

UI annotations are a critical part of the metadata-driven UI concept, a method of adding meaning to the OData service that Smart Controls and the Fiori elements framework can interpret. Annotations are added to CDS views or OData services at the backend.

Developers can utilize Fiori app layout and behavior by leveraging annotations, rather than writing JavaScript UI code.

SAP Fiori Elements: Floorplans, Flexibility, and Reusability

SAP Fiori elements, previously known as Smart Templates, is a framework that takes the metadata-driven approach to the next level. It provides predefined, reusable, and flexible UI templates, called floorplans, such as List Reports, Object Page, Overview Page, Analytical List Page, and Worklist, for everyday business use cases in accordance with Fiori design guidelines.

Fiori elements provide extension points for scenarios that are not fulfilled by the predefined templates, allowing for extensibility. Developers can add custom actions, UI fragments, and custom fields without losing the pre-defined UI.

Accelerating Development with Standardized Templates

The combination of Fiori elements, floorplans, UI annotations, and Smart Controls has a significant impact on development speed. According to SAP, this can reduce development efforts by up to 80% and enables developers to focus on business process logic, exposing data correctly via backend Open Data protocols.

SAP GUI vs Fiori: Integration, Interoperability, and Hybrid Models

A pure GUI or pure Fiori environment is now very rare. The reality is that organizations are employing hybrid models to achieve their complete business objectives, but this hybrid model has its benefits and drawbacks.

Coexistence of SAP GUI and Fiori in S/4HANA

With decades of complex functionality built into SAP GUI transactions, it is impractical to rewrite the whole code into SAP Fiori. Additionally, power users, experts, and consultants possess years of complex SAP GUI and transaction code knowledge, which makes it challenging for them to fully adopt SAP Fiori. That is why SAP ensured that SAP GUI remains relevant and is a core part of the S/4HANA strategy, allowing it to coexist with SAP Fiori.

SAP GUI can be launched from within the Fiori Launchpad as an HTML Web GUI in a browser tab or can run on desktop SAP clients for advanced tasks.

Seamless Switching between Apps and Transactions

The Fiori Launchpad provides switching between both UI technologies. If a user clicks on a tile or wants to open a classic SAP GUI transaction, the system opens the application in a new browser tab. This appears to be seamless switching, but the user is transitioning between different UI technologies. A pure seamless experience is not fully integrated into a single window or screen.

Use of Search vs. Direct Navigation (T-codes, App Finder)

Finding and launching applications in the hybrid model changes how users perform them.

• SAP GUI has direct navigation. Users are used to typing the transaction code to launch a specific program or function.
• Fiori provides search-based navigation. Users search the app in Fiori’s global enterprise search bar. For example, business terms such as “customer,” invoice,” report,” and relevant applications, business data, or objects are displayed for selection. Fiori Launchpad also provides an App Finder, which lists available apps assigned to users.

Standardization vs. Customization: Conflicting Enterprise Goals

Customization and standardization are the core conflicts that arise from implementing Fiori. Fiori promises standardization by providing design principles and templates, such as Fiori elements, in the user interface, making it easier for users to learn a new interface. A core set of apps designed with Fiori adheres to best practices for business processes.

However, the reality of customization in the enterprise is different. Every enterprise may have unique requirements for its business processes, such as specific fields and custom workflows built over decades using SAP GUI, which may not align with the latest Fiori design capabilities. As a result, they may require a more customized app tailored to their specific business use case. For them, adopting standard Fiori apps can be efficient or provide design consistency, but their custom business processes may require complete re-engineering, which may increase development and maintenance costs.

Practical Benefits and Drawbacks of Hybrid Deployments

Benefits

Organizations in hybrid deployments can benefit from adopting a phased roll-out for Fiori apps and keeping complex processes on SAP GUI.

Casual and new users can be trained on Fiori exclusively by reducing the training cost, while power users can still use their familiar SAP GUI. They can leverage the SAP GUI’s depth and complexity for legacy processes while benefiting from the simplicity and usability of SAP Fiori for everyday tasks.

The hybrid approach enables organizations to migrate backend functionality to S/4HANA, thereby maintaining user familiarity with the traditional interface and reducing resistance to change.

Drawbacks

With a hybrid approach, users may experience different interaction models, UI designs, and ergonomic principles, which can lead to a bad user experience. The IT department may become overwhelmed with supporting both the SAP GUI desktop model and the web-based Fiori platform, thereby creating additional complexity and security concerns.

Network latency can affect the performance of the GUI for HTML. A user might start a task in the Fiori app and end up navigating through a complex GUI screen to finish it, disrupting the simple and intuitive flow.

Proactive Interfaces and the Role of KPI Tiles

Moving away from a reactive, transaction-driven SAP GUI UI to a proactive, information-driven SAP Fiori is a profound shift, which makes users no longer search for information. Instead, information is brought to them in the form of their assigned apps, tiles, and cards on the screen.

Fiori’s Shift Toward Information-Driven UIs

• SAP GUI is a transaction-based system. Screens are designed for users to input data and execute programs, such as creating a purchase order or posting a journal entry, which requires them to know the transaction codes for the right program.
• SAP Fiori is designed to be information-driven. The Fiori Launchpad is the primary view for users, a personalized dashboard with key information in the form of tiles and charts. For example, a sales manager does not need to run a report to view sales orders that are pending or completed; the information will be displayed correctly in front of them in a tile or chart when they open their Fiori Launchpad.

Leveraging KPI Tiles for Real-Time Alerts and Monitoring

Key Performance Indicator (KPI) tiles are dynamic tiles on the Fiori Launchpad that display real-time insights and alerts. For example, a KPI tile is linked to a data service that constantly retrieves the latest information from the backend, ensuring the information is always current. KPI tiles can present information in the form of colors and icons with immediate context, such as the number of sales and purchase orders, turning them from green or blue to red or yellow when the number increases, alerting to a critical situation right after they log in to Fiori.

Designing UIs for Exception Handling, not Just Data Entry

Handling exceptions is the core design principle behind Fiori UI design. For example, a user might enter data for invoices for the entire day in SAP GUI and only become aware of an exception or blocked invoice at the end of the day by running a report that highlights the blockage. Fiori provides this information upfront, such as a worklist floorplan that is explicitly designed to show items requiring attention, e.g., blocked invoices, pending approvals, or overdue tasks, with color coding or icons.

Strategic Use of Dashboards for Business Insight

Fiori doesn’t just display KPI tiles for information. It provides complete dashboards via its Overview Page and Analytical Page floorplans, offering business insight. These floorplans combine multiple tiles, charts, or cards to provide insight into a specific business area, offering executives and managers real-time visibility into business operations. Every dashboard card is interactive. Clicking on it enables users to drill down into detailed information, moving from high-level insights to granular transactions with just a few clicks. For example, a dashboard for a supply chain manager can display cards or tiles showing a list of critical suppliers, shipment status, inventory value, or on-time delivery performance.

Success and Failure Patterns in Fiori Rollout

Success Patterns

Fiori implementation reveals clear patterns for failure and success. Organizations considering user-centric design should conduct in-depth analyses of daily workflows, identify user pain points, and address tasks such as approvals, status checks, or mobile scenarios, like warehouse management using tablets. These key patterns lead to successful implementation. A phased rollout, rather than a big-bang approach, e.g., starting with a small group of users for pilot programs, combined with strong change management, such as training and effective communication, also leads to successful implementation.

Failure Patterns

Treating Fiori as a pure technical upgrade is a typical failure pattern, as rolling out Fiori apps without considering whether they will resolve user problems, provide clear communication, and offer adequate training leads to confusion and resistance. Ignoring the preferences and needs of power users, not actively engaging them, may lead to their resistance and a reluctance to switch to the GUI. Single or a few training sessions without gathering feedback from users may also lead them to revert to what they already know.

Strategic Decision-Making: GUI or Fiori?

Choosing between SAP GUI, SAP Fiori, or a hybrid approach is a crucial decision for organizations transitioning to SAP S/4HANA or modernizing their existing SAP environment. This decision involves analyzing costs, migration requirements and limitations, user productivity, training needs, and support requirements.

Cost-Benefit Analysis: Migration, Training, Support

A cost-benefit analysis should be conducted to assess the long-term benefits, including migration costs, such as the technical implementation of Fiori Front-End Server, the establishment of OData services, or Fiori Launchpad configurations.

Custom development of existing GUI transactions can significantly increase costs. Integration between existing GUI transactions and Fiori Apps, as well as training costs, are also factors to consider. While new users may quickly adopt Fiori, existing or power users may require more training due to the nature of their work. Until the complete transition is made, the IT department must support both platforms, which may require more specialized skills and additional human resources.

When to keep GUI, when to go Fiori — a balanced framework

Organizations new to SAP can start fresh with SAP Fiori as they do not have an existing and customized SAP environment. Organizations migrating to SAP S/4HANA must adopt a hybrid approach. Below are some of the key factors that define when to use a GUI and Fiori.

SAP GUI	SAP Fiori
Complex and data-intensive processes, such as mass data entry and complex configurations.	For task-oriented and straightforward processes, such as workflows, confirmations, approvals, or self-service functions.
For power users proficient with T-codes and keyboard shortcuts, direct access and speed are required.	For new or casual users, they may not want to learn a complex GUI.
For backend operations, roles that may not require a modern UI or mobile access.	For mobile scenarios, managers, field workers, or sales workers may need to perform tasks on smartphones and tablets.
For highly customized transactions, rather than rebuilding them via Fiori, it can be cost-effective to stick with the GUI.	For new processes and functionalities built directly into Fiori, the default choice is a modern user experience.
For basis developers and administrators, they need access to the core system for technical tasks.	For dashboards and analytics, real-time insight for managers and executives, such as KPI tiles or the Overview Page.

Future Outlook and SAP’s Direction

SAP’s long-term investment in Fiori and SAP BTP

SAP is investing in Fiori and the SAP Business Technology Platform (BTP) as the core design system for all SAP products, with a focus on the long term. The strategy is to maintain system cleanliness by utilizing custom extensions and integrations into BTP, rather than extensive code development at the backend in SAP S/4HANA. The goal is to build new applications and extend existing ones to BTP. Fiori is the top user experience layer of architecture, adhering to SAP’s design guidelines. SAP is enhancing Fiori with improved performance, new floorplans, and UI elements.

Vision of AI-driven, fully automated enterprise interfaces

SAP’s future vision is not just building better UIs, but making them AI-driven and conversational interfaces, which is why SAP has embedded SAP Business AI into its applications. SAP has introduced Joule as their AI Copilot, a secure, unified AI agent that understands natural languages and executes end-to-end and cross-functional processes. SAP’s goal is to move from UI-driven manual data entry to AI-driven automated tasks, such as approvals automation. Future Fiori applications will incorporate voice interfaces and enhanced chatbots, enabling more human-like dialog with the system for improved accessibility and efficiency.

Potential of low-code/no-code platforms in future SAP development

With the rise of low-code/no-code trends in other enterprise application development practices, SAP is also becoming a key player in reducing extensive coding requirements with the introduction of SAPUI5, Fiori elements frameworks, and platforms like SAP Build Apps, formerly known as AppGyver. These platforms utilize no-code terminology, enabling users to build apps without requiring coding skills, instead relying on domain knowledge, which significantly accelerates the development process.

SAP BTP is an example of low-code applications to extend SAP solutions without core code modifications. The goal is not to replace seasoned developers and IT professionals, but to enable business users to create tailored solutions with drag-and-drop interfaces, requiring minimal collaboration between business and IT.

Anticipated improvements in performance and personalization

SAP is continually working to enhance Fiori UX personalization and performance, including improvements to caching mechanisms, backend performance, and refinement of OData services to reduce load times. Fiori Launchpad already offers deeper personalization, but future enhancements will provide more granular control. Fiori elements will introduce more floorplans to cover out-of-the-box optimized templates. The long-term goal is to reduce the differences between the Fiori app, classic GUI screens, or a custom BTP app, making them seamlessly unique from the user’s perspective, and enabling users to move among different UI technologies seamlessly.

Conclusion: Coexistence and the Path Forward

It is not easy for enterprises to choose solely between SAP GUI and SAP Fiori due to the migration path to S/4HANA; for them, coexistence is the reality.

Recognizing the strengths and weaknesses of each UI

To move forward, organizations must recognize the strengths and weaknesses of each UI. SAP GUI has the strengths of density, speed, and directness, especially for power users who spend their entire day in the system and perform tasks using T-codes and shortcuts. On the other hand, SAP GUI is only desktop-centric and lacks modern design, visual appeal, and mobile accessibility.

SAP Fiori provides simplicity, a more attractive web-based design, and is specifically targeted for casual users, mobile scenarios, and proactive engagement with the system. Its role-based design and visual appeal make it a highly effective tool for end users. Although powerful, it can be less efficient for large data entry scenarios compared to SAP GUI, and it can become more complex when heavily customized to meet complex business requirements.

Embracing hybrid approaches during transition periods.

Many organizations require the coexistence of GUI and Fiori in hybrid deployments during the migration period as a long-term strategy, focusing on modernization with Fiori deployments for tasks such as approvals, logistics, and analytical functions, while using a GUI for highly customized and complex transactions without the cost of rebuilding them.

Focus on user-centricity, performance, and maintainability.

As SAP’s future is based on Fiori-based developments, organizations should focus on user-centricity, conducting research, gathering feedback, and designing apps for user experience. It should be more focused on performance and optimization rather than the look and feel of the UI. Maintainability should be a primary concern when building custom apps or extensions, even if they utilize a low-code/no-code design, as they can become non-maintainable when heavily customized.