Mickaël’s Weblog

I should add “versus backend features, especially for an enterprise software”.

Have a look at Ayende work around NHProf. In a recent post he describe a change he will have to implement. I’ve no doubt he already made this significant change quite rapidely, but such change is usually heavy. You can check the number of line of code in the client vs backend there. So, technical requirement/constraints may force you to take a radical approach for the UI which induce significant extra work…especially as (from a performance perspercitve):

UI operations are expensive, while backend operations tends to be cheap.

From a requirement perpective also, UI can be very expensive to develop. Usually, customers (internal or not) are suddenly very creative when the “see” the UI of a feature and add a lot of new requirements…or changes. That’s why products like Balsamiq Mockups are really useful, to avoid useless iterations.

In the context of an enterprise software the ROI of UI becomes terribly low. The first reason is that usually, there is a need for multiple clients that are totally different: business intelligence, RIA, outlook integration, RSS/ATOPM integration, fat client, web client. This makes the development on a single client a very small piece of the entire picture, which reduce the ROI. 

The second reason, is that UI technology and trends are evolving a lot (RIA, Web 2.0…etc). At the opposite, the business logic encompassed into your enterprise software is tighted to the “business” which evolve at a slower rate. In this context, adding a new “business feature” has touthands more value/ROI than a UI feature.

In my opinion:

• UI technology should support rapide development to be able to follow trends and technology evolutions without exploding investments,
• backend technology should be selected with a long term vision,
• do not put any business logic in UI, simply allow projections of backend business logic in the front end.