Although there is evidence that the two styles will converge in the future, enterprise and consumer Web architecture and technology are quite different today. If one talks to an enterprise application architect, he or she will probably say that while consumer Web applications are cute, simple, and sometimes useful, their architectures and technologies are merely a bunch of scripts and hacks put together. If one talks to a consumer Web architect, she or he will probably say that enterprise software is overly complex, often unusable, and based on over-priced and under-performing technologies (i.e., JSF or Portal). (See the previous post about Web Developer Spectrum.)

Having lived in both worlds, I can see some truth in both arguments; however, I think that most of the divergence comes from a different set of requirements that leads to separate technical routes.  

I see six main differences between consumer and enterprise Web Applications:

1) Scale (Users vs Applications)

Scale is probably the first and most important requirement that creates a difference between the two types of applications. Consumer Web is all about scaling the number of users for a single application. Successful consumer applications, such as YouTube, Facebook, and Twitter have seen an almost exponential growth in their user base. Consequently, consumer Web architects tend to favor license-free technology and often build a customized technology to exactly fit the high-scale needs of such applications. A good example is Google File System, for which architects built a distributed file system.

On the other hand, enterprises usually have a relatively fixed number of users (which can unfortunately shrink from time to time), but they have ever growing business application needs. The biggest challenge for enterprise IT is to standardize technological architecture and best practices across their application portfolios to minimize application development and maintenance costs. Therefore, enterprise developers tend to favor standard and well-supported technology, even if it carries significant licensing fees. Maintenance is often favored over architectural elegance and performance, and technologies such as JSF, SOA, and Portal often bring the wanted risk/benefits tradeoff.

2) Experience (Simplicity vs Functionality)

The second big difference between an enterprise and consumer Web application is experience. In the consumer world, applications have to be simple and engaging since nothing but the application attracts users. So simplicity is king, and often the less functionality the better. I actually think that the success of Twitter over FriendFeed is mainly due to its simplicity (see FriendFeed vs Twitter). YouTube, Flickr, and many other successful consumer Web applications are great examples showing that simplicity often overcomes completeness.

In an enterprise environment, however, users are employees who depend on an application to perform a specific job. While enterprise applications need to be intuitive and well designed, functionality is king. Limiting application functionality for esthetic is probably not a good enterprise IT strategy.

Interestingly, both camps often make the mistake of putting too much emphasis on Look and Feel aspects and confusing these attributes with usability. As explained in my previous Flying Pixels post, good looking is not necessarily smarter. Most successful Web applications (i.e., Facebook, YouTube, Craigslist, SalesForce.com) have relatively plain but utilitarian user interfaces.

3) Security (One for One vs One to Many)

While both application types need to be secured, the security requirement in the enterprise context is much higher than in the consumer case. In the consumer Web, users usually set one access rule per artifact. For example, when publishing a video on YouTube, you can set it as private, for your friends, or for everybody.

In the enterprise case, you often have many rules for a given set of records that are dependent on complex access rules based on groups, roles, and time. This is one of the reasons that enterprise applications usually use a relatively complex but complete security framework such as Spring Security.

Nevertheless, one common requirement of both enterprise and consumer Web applications is the single sign-on. In the consumer Web, Open Auth and OpenID seem to have gained some momentum while the enterprise is using a mix of proprietary technology such as Oracle Sign On and open source and standard solutions such as JOSSO and Liberty Alliance.

4) Transaction (Decoupled vs Complete)

In a consumer Web application, the most efficient way to scale is to partition and distribute data and logic across many low-cost servers. The pitfall of using such a distributed architecture is that transactions can become quite costly and even practically impossible to implement on a large scale. It’s one thing to have Oracle RAC or Java JTA on a few servers, but it is another story to have it cut across hundreds or even thousands of servers.

Therefore, most consumer Web applications implement what I call a decoupled-transactional model in which a transaction gets split into smaller independent transactions that are executed separately, leaving an opportunity for the system to include some stale data. For example, when an artifact gets deleted, added, or modified, the item modification transaction is often decoupled from the relationship modification ones. The trick is to design the system so that 99% of the time the user will not notice the stale data and that stale data never results in wrong subsequent transactions (for example, preventing an eBay user from buying a deleted item). Most consumer Web applications have their own custom loose-transactional implementations, which are often a mixture of caching, cron-jobs, and fix-transaction tricks.

In the enterprise Web, the requirement is completely different. There is usually no tolerance for stale data, and the system must guarantee complete transactional integrity. Expensive but reliable technology such as Oracle RAC can make a big difference when the enterprise needs to scale a given application.

5) Integration (Loose vs Strict)

Another area in which consumer and enterprise requirements differ is application integration. In the consumer space, application integration happens very organically. Application providers (e.g., Twitter) or application container providers (i.e., Facebook) define interfaces with which everybody can integrate. The result is that thousands if not hundreds of thousands of applications will potentially integrate with some of these interfaces. Consequently, interfaces tend to be simpler, lighter (e.g., REST), and often even client-centric (e.g., OpenSocial and iGoogle). In other words, consumer application integration is about breadth rather than depth.

In the enterprise space, on the other hand, application integration has to be thoughtfully designed and managed and often has an impact in all layers of the application (i.e., presentation, logic, and data). Heavy and expensive technology, such as ETL, SOA, JMS, and Portal, are often an effective way to establish strong integration between applications.

6) Search (Page vs Data)

The last difference is related to search. In the consumer Web, the main search model (e.g., Google and Yahoo!) is page-based. A page is a uniform way to represent content, presentation, and relationships for a given entity. SEO is a well-defined concept that helps Web content and application providers to structure their information to be easily discoverable. One great benefit of this approach is that search is application independent.

In the enterprise Web, search is record-centric, and users do not search pages but records with all their associated attributes (e.g., Access Control). The benefit of this approach is that search is more targeted and secure. However, the biggest caveat about using this approach is that search becomes inherently application-specific, making cross-application search a relatively expensive solution to implement.

So we have looked at the key architectural differences between consumer and enterprise Web applications. The good news is that I think the “software as a service” (SaaS) growth will drive convergence. SalesForce.com is a great example of how a consumer-inspired Web architecture can be tailored to enterprise needs. I also think that Open Source is, and will be, playing a bigger role in the consumer/SaaS Web than it did in the enterprise Web.