H&R Block Sr. Systems Architect, Dan Cahoon, shares how H&R Block delivered SOA-connected Ajax portlets to its more than 12,000 branch offices to deliver composite workspaces streamlining the staffing operations for the nation’s largest seasonal employer. Dan shares his learning from the project and discusses the successful pattern they are reusing to get more solutions to market quickly.

JSR-168 portlets are really an obsolete and unnecessary technology these days — something that’s only pushed by the big-vendor/consultant miltary industrial complex.

If you’ve got money and time to burn, then JSR168 is perfect for you.

Our organization wasted a huge amount of time and money going down the JSR168 route — pushed on us by consultants, and embraced by one PHB (pointy-haired boss).

The amount of unneccesary, artificial complexity was amazing. And the complexity just snowballed as we found that the portal code infrastructure just got in the way of developers and designers, and we had to craft workarounds for some really simple problems.

We finally abandoned the project, but not after an immense waste of time and money. A simple, lightweight non-enterprise Java solution would have brought us to market in less than half the time, and with a lot more flexibility.

Meanwhile competitors did many times better than that, using ultra-lightweight LAMP-based platforms to deliver offerings much more quickly, with richer functionality — and that were way more polished.

Actually, it was the extremely bad experience with this portal project that finally pushed me to try Ruby on Rails. In that sense, maybe JSR168 was the best thing that ever happened to me. I was able to implement a version of the app in less than a month. And I was able to have fun doing it too.

So thank you JSR168, for finally making it clear to me just how stupid and wasteful enterprisey technologies are. It’s been a career and life-changing experence for the better.

Comment by Anthony — March 10, 2007

Don’t mix all in one: JSR-168, portal and enterprisey technologies. I agree about JSR-168, it’s out of date now and introduce complexity without reason (well, there are some reason behind the scene). Anyway portal technology is different. I am in portal/portlet development about 6 years for now and guess … we never used JSR-168. Portal engine is very complex framework that suppose to solve very complex problems, don’t even try to implement something like this by your team. So Portal is good solution for complex enterprise geterogenous environment. But using JSR-168 over there MAY be waste of time (say, in 95% projects).