Are Insurance Carriers adopting the worst practices of Banks?

We all know what happened to the banking sector and its cataclysmic collapse. Some people think banking collapsed do to its incestuous greed and irresponsibility in making horrific underwriting decisions. While these are contributing factors, I believe that the issue at hand is in putting profits ahead of people...



Its now 2012, the year of the empowered consumer. We can no longer expect consumers to exhibit brand loyalty when it has become apparent that they are no longer respected as individuals. Marketers everyone are attempting to classify, categorize and taxonomize consumers into nice little buckets while ignoring what makes them so valuable.

Empowered customers will figure out that insurers determined sometime ago that it was cheaper to use price and sales to win/retain their business than it was to earn their custom and loyalty through value and service. It is the insurance industry version of the same flawed "high leverage/high growth model" strategy that the banks blew-up!

This inward-looking and self-serving approach focused upon improving margins for the operator at the expense of the customer, rather than on the type of "creative destruction" to improve products/service and has ultimately left the industry reputationally damaged and untrusted.

As we continue down this destructive path, I humbly predict that the rise of technologies ranging from business intelligence to channel transparency will further erode the value proposition of insurance to consumers. With passion, I humbly predict that this will be a year where the increase in loss ratios will outrun the ability to increase prices. Anyone care to argue differently, I welcome their insight...

Did you lose your fancy job title?

During the Christmas holidays, I met up with a few friends who shared with me a story of several individuals I know who recently lost their fancy job titles. There are always multiple right perspectives...



How many architects does it take to change a lightbulb? The answer remains unknowable. What we do know is that many job descriptions suffer from title inflation. There are UI architects, Java architects, enterprise architects and so on. Sadly, many of this people have used the word architect in their job title to indicate seniority vs. ability.

As an Enterprise Architect myself, I am a student of simplification and a champion of rationalization. In short, I believe that too many people have the title of Architect and that we need initiatives to bring about industry-wide title rationalization. Simplification of job titles is one step that should be considered by Enterprise Architecture teams as a way of making IT appear less complex to the business. In doing so, the business has a better chance of understanding whom to approach with game changing ideas vs getting caught up in the quagmire of the plethora of titles.

While it is noble to do the right thing for the business, we also have to consider the impact of titles on the people who hold them. Usually, job grades are embedded in titles, and promotions make the new job grade public through a new title. A person’s job grade is generally considered public information. If employees are fairly placed in their job grades and promoted only when they are clearly performing at a new job grade, then salary differences based on job grade are generally perceived to be fair.

The negatives of title simplification tend to add confusion to the marketplace in that the range within a title now happens to be much broader. More importantly, removing titles from the toolbox of tools now means that the focus will need to shift to alternative rewards. Gone are the days where you could get away with giving an adequate pay raise with a snazzy new title.

For employers that are looking to make things simpler, I hope they will take the prudent course of action and acknowledge that titles are bi-directional entities that provide value for all involved parties.

Liferay Portal: Thoughts on ServiceBuilder

There are a few opportunities for improvement in the functionality of ServiceBuilder. Below are my thoughts...



1. Liferay does a good job in making itself manageable, but could take a further step in leveraging JMX to create additional visibility. Generally speaking, when you create a custom service, you may want to expose metrics such as uptime, number of invocations, etc. It should be relatively straightforward for ServiceBuilder to also create a JMX MBean that provides visibility into service operations.

Whenever a service is started, it could automatically register itself with the MBeanServer. Alternatively, you may want your MBeans to be available as soon as you deploy your application, listen for notifications from the deployment service.

2. Many enterprises want to increase the testability of applications they put into production and will naturally gravitate towards tools such as JUnit. Since Liferay creates services that can be exposed via SOAP and JSON, there is an equal opportunity to automate the creation of unit tests for these invocation methods. The ability to test JSON APIs may be best accomplished by using the JUnit extension known as HTTPUnit.

3. Liferay needs a better way to handle subtypes. A supertype/subtype design requires that some attributes be stored in the supertype, and some be stored in the subtype. The attributes for each thing in the real world are split between two tables/entities. This may be useful in a variety of scenarios where you need to store different typed attributes for a given population.

One example that comes to mind is for storing information about different types of users. Imagine a role-based portal where you have agents, employees and consumers all using the same resource. An agent may have a unique industry-provided identifier such as a professional license. An employee may have an employee ID and so on. A service that understands these relationships would be very powerful...