In multi-layered architecture, can I skip the business layer for crud operations?

If there is no business logic to perform, there is no reason to enforce a business layer. The 3-tier architecture is not an arcane protocol, just a best practice that was formed assuming business processing.

In a current application we are often accessing DAOs directly from JSF controllers when there is no business process involved. The idea was given by a java champion who stressed the idea that simplicity is paramount.

If you are worried about future modifications that may require adding business logic. I think of the issue this way: The additional business logic would be added to the business layer anyway, including data access, so there is no difference here.

CRUD code is mostly very simple. So the change in the service would amount to reroute a single call or a couple of calls fron the DAO to an EJB - a simple refactoring. The CRUD code itself would still remain, but will be pushed into the EJB - another simple refactoring.

This is not perfect, but IMO better then the alternative: having an empty indirection layer. This adds complexity that serves no purpose. The business object would do nothing but forward the calls to the DAO.

There are two code smells that I think apply in this case: contrived complexity and feature envy.

I am not saying that DA in the business layer is somehow a code smell. What I mean is that having a business object that does nothing else but proxy the DAO is a smell. It's the same with complexity - an added data structure / architectural layer that serves no own purpose - there seems to be a DAL in your application already.

Another aspect for your consideration would be - how surprising is it for a developer to see a service that uses a DAO directly? Having 5 services where 2 of them access DAO directly is different from having 100 services where only one service accesses the DAOs directly.

In the first case the code simplicity would outweigh the added conceptual complexity (2 concepts for a single thing), in the second case, I would rather stick with the business layer - the surprise (also called the WTF-effect ;) of doing it differently just once would be too big.

In my opinion, having call CRUD services bypassing the business layer will start converting the current service layer into a business layer as you increase the functionality. So your service layer will act as the business layer too, if you are fine with it.

In most cases, you deal with an entity and probably that could involve many data layer crud calls, on one update for example. A business layer is recommended for this purpose. And business layer is the place to execute any business rules, caching or call other business services if required. This will keep the upper layer simple and pass through.