J2EE Strategy Panel

I'll be at the Enterprise Java Industry Forum in Sydney on Tuesday 31st August. I'll be on a panel addressing the most important elements for a high quality enterprise J2EE strategy.

We'll be talking about the following:

1. J2EE Vendor Software Strategy
   - Vendor Selection
   - Interoperability
2. Architecture
   - Presentation Layer
   - Persistence Layer
   - Integration Layer
3. Open Source Strategy
   - Management
   - Selection
4. Quality
   - Testing practices
   - Programming practices
5. People
   - Training
   - Agile development practices

Vendor Selection - Adopt an lightweight, evolutionary strategy.

What EJB application server should I buy? This is the wrong question.

Firstly, any technology or tool choice is not nearly as important as the quality of your people, your working environment or your software design.

Ask yourself, what am I trying to achieve? Standardisation? Why? Probably you are looking to lower your cost of maintenence.

But standardisation can bite you in the arse. There is a risk to making a descision too early, and if you choose the wrong tool for the job, you are in trouble. But if you choose the wrong tool for the next 5 years, you are toast. Chris Matts explains in these articles about options theory, as used in the financial markets to manage risk. Options have value because they defer a descision. The Lean Software Development guru Mary Poppendick say in this article, you should defer all descisions till the last responsible moment.

We should strive to have defaults, not standards.

Standard have another dark side, if you mandate standards, you will miss out on any cost savings you might discover as you go along. You aslo might also find that really good developers don't like being told how to do their job, infact you might find all your best people leaving if you mandate a standard, lowering the skills in your organisation and increasing turnover.

Having said all that, what EJB container should I use? My answer is Don't use EJB! There is a growing trend in the java community towards lightweight containers because they are open source, simple and help developers write enterprise apps in a decoupled and more maintainable way. Now as Mike Cannon-Brookes from Atlassian says, "The big vendors don't like lightweight containers." and for obvious reasons, only one being that they are free. Don't let this stop you.

If you find you still have the urge to buy something up front, have a look at this collection of awesome cheap ware as these tools can be much more valuable than their large, enterprise scale and expensive equivalents. They are less complicated and quicker to integrate, they add less overhead to the project, they are quicker to learn and can even have better support. Some even include full source code, for example, Confluence.

People
People issues are going make or break your J2EE project. The one rule is, you can't affort to not have really great people. One really experienced developer outweighs any product or process impact.

Want an effective J2EE development team? You need to infect your people with as much experience and knowledge that you can. Using a military metaphor, Jason Yip has said you should use force multiplication to skill up your people. The idea is that you should get a bunch of really talented developers and start succeeding in your organisation with them, as each team becomes effective you slowly split the team in half and spread the experience like a virus.