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.

The argument isn't well supported. Products and their classification and related attributes vary widely. Does this mean that a generic database can't handle them? Obviously not; one uses a generic RDBMS and a custom schema.
- I'm not understanding you here. We are talking about generic shopping carts, not generic databases. A database is a generic tool, not a domain-specific tool. We are talking about domain-specific frameworks here.
Then typically an individual product is identified by a serial number. The shopping cart might reference just the serial number plus an abbreviated description (to be user friendly) plus a count and a cost per item and a subtotal for that item, etc.
- This does not work well due to the "variation" issue described above. Not every company wants to track every product variation by a single number. I worked on just such an existing system. There can be "sub-parts" such as different shirt color or sizes. I suppose there would be a standard string that could describe the product (such as major number appended to size and color description). But then we cannot isolate the components in the carts without parsing. It has similar complexities to a compound key where sometimes we want to treat the key as a single unit, and sometimes we want to do logic on parts of the key. For example, what if a requirement was to display an ad or coupon for "plus sizes" if a user had large sizes in their cart? Parsing may be "good enough" in this case, but perhaps not in other situations where false positive string matches could gum up the works. Further, some companies have odd product ID schemes with sticky logic based on legacy rules. Shirt size info may be in the first half of the key some times, and the second half at others. Starting with a new business or system can be cleaner, but legacy businesses still need systems and they have the baggage of messy historical rules.
I.e. I've used many shopping carts, and integrated a few, and my experience is that there hasn't been an issue with them being generic. I don't see that you are supporting your assertion that it can't be done. Maybe it can't, but I still don't see why not.
- It is not a matter of can or can't, but the practicality of it. TuringTarpit. Perhaps the title should be changed to "really difficult" or "no net gain" instead of "unobtainable".

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.)

--top

[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:]

"In object-oriented systems, a set of classes that embodies an abstract design for solutions to a number of related problems."

[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:

Takes too long to understand the interface. It starts to be bureaucratic, especially to the non-original coder.
The complexity of the interface creates greater chance of errors due to misunderstanding
The configuration process (selecting the right combo of feature switches) can take longer than building one via copy-paste-modify.
FragileParent? problem: a "fix" to one part may create unexpected side-effects that break other apps using the utility.
Could get slow due to size and complexity.
May take up more source code at the calling end to use it.
Introduces GoldPlating temptations.

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.