PR0014 - 2009-01-12

Redistribution and other use of this material requires written permission from The RCP Company.

Lessons Learned from an Enterprise RCP Application

During the implementation of a major financial application for a large financial institution, we learned a lot about how to use Eclipse RCP as an application platform and especially some of the short-comings of the current platform when used in the enterprise environment.

This long talk goes through some of the lessons we learned and discusses some of the changes that could be made to Eclipse RCP to get a better platform for enterprise applications.

This talk has previously been presented at EclipseCon ’08.

PR0014 - 2009-01-12

2

Agenda

� The Application

� Lesson 1: All end-users are not engineers

� Lesson 2: All windows are not equal

� Lesson 3: Editors are no good

� Lesson 4: Views are only a little better

� Lesson 5: Update must be dynamic

� Lesson 6: Security is King

� Lesson 7: Some frameworks are still missing

PR0014 - 2009-01-12

3

The Application

� Nordea is one of primary financial institutions in the Nordic countries with branches in Denmark, Sweden, Norway and Finland

� The business includes banking, pensions and insurance

� The long-term aim of the project is to replace all the existing banking applications in one common integrated desktop

� Customer management

� Teller

� Product Provisioning (loans, credit cards, pensions, insurances,…)

� End-users are all branch and call center personnel (clerks and managers)

� Organized in a number of levels with different working areas

� First version will cover provisioning of non-collateral loans, credit cards and other types of short-term loans

PR0014 - 2009-01-12

4

The Business Case

� The business cases is based two advantages:

� One client instead of 4-5 clients

� Higher productivity

� 1 minute saved per case equals 30 extra resources

DK SE NO FI

ESB

...

Branches CC

BPM

Clients

internet

Intranet

Stock

CMS

Teller

PSD

A & A

PR0014 - 2009-01-12

5

The Requirements

� Business requirements

� Provide process support

� Show/hold all functionality and information in one place

� Seamlessly integration between the functional areas

� Data re-use

� External peripherals

� High usability

� Follow the OS

� Standard keyboard navigation, icon, help, drag & drop

� High performance

� IT/Project requirements

� Parallel development

� No hard dependencies on the other projects

� Different release dates for the different functional areas (projects)

� Different dependencies to the back-end

� Nordea is a bank, - not a major IT product company

� Mature and well tested framework

� Go out and buy the funtionality

PR0014 - 2009-01-12

6

The Process

� Project started in 2006 with an evaluation

� Several different frameworks were evaluated

� Portal based

� Eclipse RCP

� NetBeans Platform

� Several Eclipse RCP frameworks were evaluated

� Major part of the evaluation was a fully functional prototype

� Access to ”real” data

� Divided into functional areas as a number of independent plug-ins

NowStart (early 2006)

Business req

Evaluation Platform components

Prototyping/testing First project

Decision (late 2007)

PR0014 - 2009-01-12

7

Nordea Banking Desktop (prototype)

PR0014 - 2009-01-12

8

Main Idea behind Application

� One primary window – the ”banking desktop” with access to all primary input sources

� Secure mail received via home banking

� Activities forwarded by other clerks or created by a BPE

� Meetings created by other clerks on your behalf

� Perspectives used for each functional area:

� Mail

� Search

� News

� General information such as account rates, product details

� A secondary window for each ”open” customer

� Perspectives for each type of engagement

� Ordinary accounts, loans, credit cards, etc

� Pensions

� Insurences

� End-users can work on many concurrent tasks – but only one per customer

� End-users are often interrupted by other work or phone calls

PR0014 - 2009-01-12

9

Lesson 1: All End-Users are not Engineers

� Not an obvious lesson!

� The end-users of an entreprise application can be divided into two groups

� The specialists – often a very small group of the organisation

� Very much like engineers in the mindset

� The rest (☺) – normally 95% of the end-users

� Sometimes no formal education – e.g. in tele-marketing

� Our Solution:

� Avoid all workbench configuration

Like the same desktop every time

Like to configure “everything”Need for workbench configuration

Very diciplinedSomewhat anacistic”Mindset”

10-60 minutes1-5 daysTask lengh

ManyFewNumber of end-users

Processes – often based on law

Creativity – often very few formalized processes

Work controlled by

The ”ordinary” usersThe specialists

PR0014 - 2009-01-12

10

Lesson 2: All windows are not equal

� The content of workbench windows can differ a lot

� Our application contained four types of windows:

� “Banking Desktop” window

� “Customer” windows

� “Search” window

� “Development” window

� Different content on different windows

� It is very important that the data for different customers is not mixed on the same window

� Closing the “banking desktop” windows, closes the application

� Our Solution:

� Simple parameterization of workbench advisors

� Re-creation of windows not trivial

PR0014 - 2009-01-12

11

Lesson 3: Editors are no good

� Eclipse uses two different types of workbench parts:

� Editors

� Has state and a built-in life-cycle management

� Menu and toolbar merged with top-level menu and tools

� Is put in a designated ”editor area” that can only contain editors

� Views

� Has no state (only configuration)

� Has private menu and toolbar

� Is put in ”view stacks” that can only contain views

� Editors and views cannot be combined in a single stack in a window!

� Editors cannot be restricted to a specific perspective

� In the banking desktop, it has been impossible to explain how the above can be used in a consistent manner

� Our Solution:

� We decided to not use editors at all!

� Happily, the editor life-cycle management can be emulated in views

PR0014 - 2009-01-12

12

Lesson 4: Views are only a little better

� Views have their own problems though!

� The menu and toolbar of a view is part of the view itself

� All usability tests performed with the prototype (50 persons tested) showed the view-local toolbar and menu has always ignored!

� It is not possible to limit the “Show View…” command to only present a limited set of views based on the current window and perspective

� E.g. a specific view – representing a specific type of pension – should only be presented if relevant for the customer

� Our solution:

� Add all view-local menu and toolbar actions to the main menu and toolbar as well

� We might completely remove the view-local actions in the future if not used

� Disable the “Show View…” command – and create all relevant views when a customer window is shown

PR0014 - 2009-01-12

13

Lesson 5: Update must be dynamic

� When problems are detected in the application, it must be possible to provide fixes to all users – if not immediately, then very fast

� Updates should be pushed

� End-users must be able to choose when to update

� Our Solution:

� Simple use of the update manager

� Looking forward to see if Eclipse Provisioning Project (p2) will help on the performance

PR0014 - 2009-01-12

14

Lesson 6: Security is King

� The banking desktop is a banking application, so security is paramount

� Individual end-users have different – rather fine-grained – roles

� Controls the access to different functional areas and actions

� Can you access to the stock portfolio of a customer?

� Can you request a new credit assessment for a customer?

� Which types of loans and credit cards can you grant to a customer?

� How big a loan can you grant?

� We need to control access to perspectives, views, commands, sections of views, choices in views, and some sizes (e.g. amounts)

� The security department is a separate entity from the development group

� Consequently it is necessary to handle security issues very late in the development cycle

� It is best be to be able to change role definitions without invoking the development group itself

PR0014 - 2009-01-12

15

Lesson 6: Security is King (continued)

� How do you ensure all the bundles used in the application are in fact sanctioned by the security zsars?

� Our Solution:

� We use activities to control access to most UI “things”

� Safe as long as you keep from certain built-in actions such as “Show view” and “Show perspective”

� Declarations put in separate plug-ins

� We use signing and MD5 checksums to protect the application

� The solution isn’t exactly simple, so why isn’t there any framework in place for this?

� Side note: it seems there will be something present in 3.4 on both accounts

PR0014 - 2009-01-12

16

Lesson 7: Some frameworks are still missing

� During the development some frameworks was identified that could have helped on the development:

� A transformation layer between an EMF model and the WSDL of web-services

� We created as a number of custom wizards that helps us write themost boring parts of the mapping

� Support for screen-flows and processes in views

� Solution presented at Eclipse Summit Europe ’08

� See http://code.google.com/p/screen-flows-in-eclipse/ (EPL’ed)

� A simpler version of the databinding framework with more knowledge of the different business data types and the way to handle these

� Solution to be presented at EclipseCon ’09

� Will be EPL’ed

PR0014 - 2009-01-12

17

About Me

� Founder and Owner of The RCP Company

� 20 years of experience in system development in major companies

� Regnecentralen (now ICL)

� Digital (now HP)

� Anritsu (previously NetTest)

� 9 years experience as the Systems Architect of an 20+ MLoC project

� 6 years of experience with Eclipse and Eclipse RCP

� Add-in Provider Member of the Eclipse Foundation

� Chairman of Eclipse.dk