Generic Business Framework Unobtainable

The idea of an "ultimate generic thing" is often an unobtainable or very difficult goal in business processes.

For example, if you try to build a generic "shopping cart" framework, you will probably run into all kinds of variations as you try to use it in different circumstances. One cannot anticipate all the possible variations different places want. If you keep adding requested features, after a while the interface would become so bulky and cumbersome in order to handle everything that developers would rather roll their own instead of wade through a giant interface that resembles the tax form for IBM.

For example, product classifications can vary widely. Some places only need a single dimension of product classifications. Others have a "variation" factor, such as color or bottle size. Others use a "grid" approach, such as T-shirts of different colors and sizes. And, there are may approaches to codifying products and product variations. Hierarchies are one approach, but not the only and perhaps not the most flexible. One probably cannot change an existing system to match the representation that the shopping cart component wants, and thus a translation layer may need to be built.

And, often there is complex bulk discount or special offers that require a high degree of integration with shopping cart info. Further, other departments such as accounting and marketing might want to view, query, and monitor shopping cart info in various ways. And the presentation approaches probably have a zillion permutations.

A shopping cart probably would have to be linked in with the product information catalog (among other things) of an existing system, and there are a jillion different ways to represent products. A generic interface that can link to ANY product catalog would probably be bigger than the shopping cart interface itself. Thus, we end up using mass abstraction to try to support our existing mass abstraction (generic cart). It may be a form of AbstractionInversion.

Perhaps one can copy an existing framework and re-code the portions they need changing, but to have a black-box framework that can handle every variation and special need without poking around in the internals is probably nearly impossible, or at least too complex to be "marketable". Even ignoring the implementation, designing a generic interface is often a long hard lesson in itself.

A black-box framework that can handle any variation... sounds like a programming language to me :) --AnonymousDonor

Interestingly enough, many software packages to handle "generic" operations like HR and customer service often include scripting languages and GUI building capabilities in order to provide custom functionality. Personally I find such systems are often a mess to extend because their internal schemas or relationship associations don't fit the business using it very well. Often they are either internally unnormalized (have duplication), or use too many many-to-many relationships in order to be generic enough. But, the particular customer may not need many-to-many relationships for their shop. But they are forced to use it anyhow as a tax to the Gods of Generacy.

Many-to-many relationships indeed are a wonderful tool to assist in generacy, but too many of them and you have a big slow mud ball with too many layers of indirection that you don't really use. For example, I saw an upgrade of industry-specific software where the particular company using the package needed only 1 of the 3 schema changes provided by the upgrade. The other 2 sections became more complicated for no use to this company. If this particular company managed its own schemas, it would have fewer tables and simpler relationships. (Related: KitsAsCompromiseToBuyOrBuild)

The application also started suffering from VariationsTendTowardCartesianProduct. The documentation would say stuff like, "If you have feature-A enabled and feature-B enabled, then X will happen. However, if you have feature-A disabled but feature-B enabled, then Y will happen. But if you have feature-A enabled and feature-C enabled then.....". This software had to serve several dozens of large companies and city ulities. If it was not flexible, then existing customers worth millions of dollars in revenue may switch vendors. The product was teetering on the point of variation-overload and feature-overload. If I had the chance to rebuild it, I would use more "meta attributes" tables (see AttributeTable) rather than hard-wire so many attributes into the schemas. However, the horse-power for such probably didn't exist when they started. (There are about 3 vendors that provide similar products.)


[Ha ha. Seriously, though, I've always thought of "framework" as a loose term, but is there a rigorous definition? Foldoc gives a reasonable, if not rigorous, definition:] [Note the "related problems" part. Also, any definition that relies on the word "abstraction" is not "rigorous". MeasuringAbstraction is difficult to agree on.]

[I don't really see why they limit it to OO systems.]

One can view it as an API or set of API's that are meant to simplify (pre-package) a given task or feature. An example may be a shopping cart or e-commerce framework, as used for an example here. Generally it promises to allow you to avoid programming such a feature from scratch.

Even something as (seamingly) simple as a date conversion routine can turn into a sprawling feature packrat if one tries to make it generic. For example, I had a routine to convert from date format A to date format B. In one situation if the date was invalid, it was fine to return blank/null. In another case I had it return a "filler" date (such as 01/01/1900). I didn't want it to raise an error because there were known bad dates and I just wanted this util to convert what it could to valid dates. But in other situations I did want it to return an error and stop processing, while in yet another to return an error as part of a result array or object. Plus there's the issue of how to round or truncate a "time" portion of the date if it had one. I gave up on a sprawling generic date handler utility/class and decided to copy-and-modify from other apps or sub-apps as needed. It also kept the caller code simple because it was a simple function instead of a bunch of structures, object instantiation verbosity, and/or parameters. CopyAndPaste (and modify) has an ugly reputation, but sometimes it's the simplest path. Sharing-based inter-app reuse can be difficult. Intra-app factoring is usually much more fruitful.

So what is a "sprawling feature packrat", exactly? A set of classes with rich functionality? How is that bad? How is CopyAndPaste better than building up a library of tools that undergo ongoing refinement to improve their applicability to ever-wider problems with ever-decreasing modification?

Here are some of the problems:
I would expect that a generic shopping cart generator, with every bell and whistle you can think of, would start becoming a DomainSpecificLanguage. --RobMandeville

Perhaps true. However, people want GUI's or front-ends now. But I can envision something with a mix of a front-end and some kind of internal scripting language, somewhat similar to what AutoCad did with Lisp, or heaven forbid, MS-VBA for MS-Office.
See also:
CategoryExample, CategoryAbstraction, CategoryBusinessDomain, CategoryReuse

View edit of June 18, 2014 or FindPage with title or text search