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.

…SF as Software Factory, I mean a full featured development infrastructure. This became obvious to me when I read the post of Ayende on his vision of entreprise platform.

Ayende had the idea to base the system on code versioning system. This is definitely a great idea that I share, but I think this should go beyond: a complete software delivery infrastructure. The customer (software providers in fact) should be able to build, test and deploy applications….services for others users.

The great idea to relly on a source control system will solve the problem as versioning of the applications (for a part of it) and when you have multiple developpers working on an application or service. But this does not fullfil all the requirement for a PaaS, what about tests & validation, deployment (especially for multi-tenancy), delivery, maintenance…etc.

Finally, the requirement is to provide to some users a full featured development and delivery environment. The excellent post on the Lack of good Paas platform is highlighting very well all these requirements: customization and configurability, versioning and multitenancy, security, scallability.

I would add a requirement on robustness: as soon as multiple users can deliver software on top of platform shared by all…there is a high risk to have the system out of control. Ensuring a high level of service is fundamental, so the system should be really robust. The challenge is to let the system open (the sw providers are building software - so very high level of freedom) and “a live”, but this will be the topic of another post.

Here is the fisrt post of a series to talk about my vision on Enterprise Applications.

What is an Entreprise Application?

Oren get a very good definition of what it and what it should not be : an enterprisey application in his post Enterprisey vs Enterprise Software :

Enterprise Software - A common term used to refer to systems that usually run a core part of a business. Often those are mission critical systems, which interact with many other systems in the organization in many interesting ways. Enterprise software is considered hard because it often need to mix technological capabilities with the business logic, and be flexible to handle changing conditions as the business evolves.

Enterprisey - This is a derogatory term, used to refer to a system whose design or implementation is overly complex compared to its supposed function. Often the term refers to the usage of anti patterns such as Everything is configurable, Executable XML, etc. Those systems are consider bad because a simpler design or implementation would have achieve the same purpose, at far lower cost, with greater maintainability overall.

Such software are addressing different markets: CRM, ERP, Fincancial, HR, Payroll…etc.

What are the different Business Models?

The Enterprise Application Platform is in itself very interesting has it is facing real technology challenges (I will leave discussion on them for future posts). Some of these challenges are depending on the bsuiness model of the Enterprise Application (EA). Most of the famous EA are using the very common SaaP (Software as a Product) business model, couple with some Professional Services or strong partership program. A new model is raising : SaaS (Software as a Service), a good example is salesforce.com. In between you have a continum of hybrid business models (that are not better or worst). More over I’m sure I’m missing someother well know business models.

What kind of depedency?

Extensibility is key for EA, as these applications are at the core of the enterprise,. All companies are working in different area, have a different size, in different country with different law…etc. The customer have to introduce into the system there own process to be efficient, and they will taylor the system.

Tayloring raise the problem of upgrade. If you are in a SaaP model, you will have to deals with upgrades and/or migration. In a SaaS model, you will do continuous integration and deals more with evolution than upgrade.

The RDBMS independancy is of high interest for a SaaP model, and almost irrelevant (at least for the customers) in a SaaS model.

What is the right business model?

None…or all. They are all valid, just different. SaaS has a good trend now but ASP failed some years ago. We will see if this trends is confirmed in the coming years, and if it is adopt by Fortune500.

Anyway, the important point is that the architeture of the platform clearly depends on the business model.

I’m working (for 11 years now) in the development team which develop an Entreprise Software. I started as developper, i’m now architect and I’ve lead the team for 7 years.

In the 90s, there was absolutely no platform, neither framework to buid Entreprise sofware. This is no more the case. Microsoft deliver CRM, Sharepoint and incudes now in .Net framework capabilities required by Entreprise framework as workflows, MVC…etc. The SaaS plateform as salesforce.com also provide such capabilities.

Oren have written a very interesting post on his vision of entreprise platform. His points on extensibility and deployment are simply brilliant. So I decided to start a series of post on this topic to bring my humble contribution. I do not know yet how I will split the different post as there is lot of thing to write about this topic.