Systems: Financials / ERP

In the world of Insurance, the use of Financials / ERP systems is often very limited. When you think about it, this is fairly commonsense. In most other industries, the organisation produces a physical product. ERP systems are designed to manage the purchase and sale of products, and all of the bits and pieces that go into that (e.g. Production Planning, Bill of Materials, Asset Management, etc). However in financial services, we deal with complex, intangible products, that are heavy on calculations and business rules. The sales channels are equally complex.

Organisations will always have a General Ledger system, into which the Policy Administration, Claims, and Agency / Commission systems will directly feed GL journals. Other modules may be used if the organisation is sufficiently large - Accounts Payable, Asset Management, and of course Human Resources modules. But the core linkage with the other systems will normally be the GL.

Key limitations of Seam's IdentityManager and IdentityStore implementation

There are a couple of key limitations imposed by the implementation of the Seam IdentityManager and IdentityStore classes. The IdentityManager is supposed to be the main component for managing all Users and Roles. To create a User, you should call IdentityManager.createUser(). To enable/disable a User, or add/remove Roles, again call the appropriate IdentityManager functions.

The IdentityManager then uses an IdentityStore to manage the interface to a database or external data source (e.g. LDAP). The JpaIdentityStore class assumes storage in a series of database tables in the application's DataSource. To make this work there are a series of annotations that identify the User and Role entities, and specific fields on them (e.g. user login, password, etc).

And in case there are other attributes on the User entity (secret question, date of birth, etc), there is a PrePersistUser event raised by JpaIdentityStore, which you can hook into and set these other fields.

But therein lies the problem. The IdentityManager doesn't provide any means to Update a user after it's been created. So there is no clear way to save changes to a User through the IdentityManager.

So far, I've ended up side-stepping the IdentityManager completely. Instead, a customised UserManager component which started life as an EntityHome. Then a custom Authenticator to use the User entity to validate user name and password.

While this does tie you into a custom User and Group/Role implementation (which means switching to LDAP, etc is more difficult), it bypasses the limitations of the current IdentityManager and IdentityStore interfaces. Until the IdentityStore interface is expanded to include additional User attributes, it really doesn't look like it will cut it in an enterprise-level environment. Of course in an enterprise environment you're probably more likely to be dealing with custom integration to the organisation's existing security framework, so this is probably not a big deal.

Managing IT Geeks

A very insightful article on Computerworld about managing IT professionals. How many of us have heard of managing IT staff being compared to herding cats? This article makes a number of salient points about the motivation of IT staff, and how this impacts on management of these professionals.