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:
- J2EE Vendor Software Strategy
- Vendor Selection
- Interoperability - Architecture
- Presentation Layer
- Persistence Layer
- Integration Layer - Open Source Strategy
- Management
- Selection - Quality
- Testing practices
- Programming practices - 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.
