This is a stress that constantly moves solutions toward a commodity approach, but there will always remain some systems and components that resist this treatment, and there will always be novel approaches that make current standards obsolete.

The 90% solution for the vast majority of businesses is packaged solutions such as SAP, Oracle Financials and Great Plains. The cost of customization is so high, many business will adapt and standardize their business processes to these solutions, particularly when the processes provide no strategic business advantage. Business will eliminate diversity that isn’t cost effective.

The n-tier architectural pattern is an evolutionary development that has driven standards for the implementation of interfaces between the tiers and typical patterns for the functions of those tiers.

This would not be possible if the way business systems were constructed 20 years ago had persisted. The concept of a “DBMS” didn’t even exist and products that provided their functions “out of the box” didn’t exist.

The concept of a standards-based application server (J2EE, .NET) evolved over the last 5 or so years. It’s now rare to find applications that employ highly custom non-functional application tier components and services. How many ways does a developer need to connect to a database? Are JDBC and ODBC sufficient for most applications? How many custom connection pooling mechanisms are needed? How many custom authentication mechanisms does the world need?

The argument extends to the way we put these components together for businesses to do the required functional customization. How many LAMP implementations do we need? Aren’t there a small number of web server, application server and database server combinations that suffice for most customers? Who really wants to maintain every permutation of these components? Even for a standard small set of components, their is wide configuration diversity possible. There is a mind-boggling array of configurations possible for a simple Oracle Listener component. There are a number of choices for connecting an Apache Web server to a BEA Web Logic 9.2 application server. In most cases, one configuration is as good as another, and diversity adds no value at all.

Aren’t there a small number of standardized “stacks” that provide the 90%, cost-effective solution for most customers? Right now, there really isn’t much choice but to put these things together yourself if you are a customer, but if there was a choice to purchase pre-configured stacks, which choice would most customers make?

My argument is that the only thing that stands in the way of this is a change in the way these components are licensed and supported. These are business problems not a technical problems, much like the micro-charging and DRM problems Apple solved that make iTunes possible. The contracts and business deals Apple made with the credit card companies and the record labels were far more amazing than the technology. These were the essential and novel details that made iTunes a reality.

The goal of the process when using a dryer is to dry clothes. Some are delicate, some are more sturdy, but the process is generally identical for all garments. Business processes are rarely the same from one business to the next, even in the same industry. It makes sense to custom construct business components and it’s one of the main reasons n-tier architectures are so successful. I don’t think the trouble of custom development of business components outweighs the flexibility and efficiency provided by a good implementation.

This happens to me sometimes when my machine is very, very busy. Maybe you don’t have enough CPU or something else is running that is soaking the box?

What’s a “2000t”?