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. 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.

1. PR0006 - 2008-01-28
Redistribution and other use of this material is covered by EPL.
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.
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.

2. 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

3. 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

4. 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

5. 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 decencies to the other projects
 Different release dates for the a functional area (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

6. 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)

7. 7
Nordea Banking Desktop (prototype)

8. 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

9. 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
The specialists The ”ordinary” users
Work controlled by
Creativity – often very few
formalized processes
Processes – often based
on law
Number of end-users Few Many
Task lengh 1-5 days 10-60 minutes
”Mindset” Somewhat anacistic Very diciplined
Need for workbench
configuration
Like to configure
“everything”
Like the same desktop
every time

10. 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

11. 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

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!
 If 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

13. 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

14. 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 able to be able to change role definitions without
invoking the development group itself

15. 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

16. 16
Lesson 7: Some frameworks are still missing
 During the development two frameworks was identified that could have
helped on the development:
 A transformation layer between an EMF model and the WSDL of web-
services
 Support for screen-flows and processes in views

17. 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
 5 years of experience with Eclipse and Eclipse RCP
 Add-in Provider Member of the Eclipse Foundation
 Chairman of Eclipse.dk