Tuesday, January 26, 2010

Configurable VS Cogs Products

To my experience I can classify a Product into two types Configurable and Cogs Product.

Configurable product
A Configurable product is a product that is wired to a particular algorithm or logic. What really changes are the actual parameters that feeds the logic. Usually those parameters are written as XML configuration file or in tables whatsoever.

Configurable products are fast to develop and easier to test. The reason is that you collect certain requirements and develop this product as per these requirements. The challenge is to make your product as generic as possible so it can fit as many of your clients.

Say I have a product that can draw a map of customers usage of electricity in a given year. This product is configured to take as an input Customer Table Name, the table should contain Location field which represents the location of the customer and the a Load field to create the legend. So you might have the Location field named as CustomerLocation or Customer_Location or Customer_Position or Customer_Lat_Lon doesn't matter. As long as you configure the product correctly you don't need to change your Customer Table name or its fields.

However, the product won't work if you have for example the Load field in a table while the customer data is in another table, because this violate the infrastructure of the product.

Cogs Products
Think of Cogs product as a framework application replaceable Cogs (Classes). So the product is a collection of classes that talk to each other via the Interfaces ONLY. And its important the word interface in this context. Oriented approach plays a major rule in the cogs product. Clients can write their own logic that Implements those interfaces and literally replace the built in logic with their own.

Cogs product require a neat UML design and a decent knowledge of Design Patterns.

Lets have an example.

Lets take again our product in the example above and alter it a bit. The product have a class called DrawMap that Takes in its constructor ICustomer interface. ICustomer interface has method called getLoad and getLocation. The beauty of this design is that I can write my own Customer class lets call it MyWeirdCustomer that implements ICustomer and write the methods getLoad/getLocation which reads from a table or file or whatever and return the load and location respectively. Feed that object to DrawMap class and TADA. It works. The reason is that DrawMap doesn't care what your class is or how it is reading the load or how it is calculating the location. Whether you are asking Google Earth to geocode your location or have your location as native X/Ys; What DrawMap only cares about is that you implements ICustomer and that you have the function getLoad/getLocation.

The best approach is to merge the Cogs Product with Configurable one giving your client the ability to customize their code and have a configurable product. Having a hybird like product


  1. Actually I have a great example of product I developed for my bank, it is a credit scoring system. Almost everything in the system is configured through user admin interface and the configuration is stored in the database, actually if you take this application without the configuration template we use you can turn it in to questionnaire system, survey system, form builder application, you name it. Configuration was made up to the field and field validation level, even the scoring criteria is stored in configuration database, Like rule based system, even data sources and interfaces with other systems (SQL, oracle, web services, any oledb or odbc compliance db) is stored in the database. How the form is rendered and the workflow behind these forms is defined in the database. so pretty much a to z in configuration database

  2. Mohd!
    Sounds like a great application you developed, fully configurable, loved the way you interface it to work with different Database engines

    FTW dude

  3. It seems to me that what you describe as a "cog product" is known as a Framework, right? You can extend a framework by implementing the frameworks interfaces and "putting" the components back into the framework. This results in extended, customized functionality of the original product.

  4. Yes exactly the same concept
    Thanks for your comment..

    I'll modify the post to add that hint


Share your thoughts