Rolling Chassis

In the auto industry there is a thing known as a "Rolling Chassis" (RC), it consists of the chassis (or frame) the front & rear axles, the front and rear suspension and (the things that make it role) the wheels. This is the basic building block for all cars. The C4 frame produced by GM, fits every Corvette made between 1963 and 1982 (and 60% of all of the other North American cars they have made from 1956 until 1986). This is the perfect example of make once and use many, and backwards compatibility (the subject of a future blog). The operational framework is what is analogous in the IT world to the RC. by operational framework I mean the code that underpins everything else.

In the Data Warehouse world this is what I call the Load Process Control, in the Oracle world it would be EWOC (Enterprise Wide Oracle Components). The stuff that makes your data warehouse (DW) run (or not if needed). it is this "stuff" that is generally missed out when designing a DW, sure all of the functional, and sometimes even the non-functional components are thought of, but this area tends to get over looked until it is too late.

EWOC is the thing that controls what loads are to be run, monitors what steps/jobs are running, captures errors, stops duplicate jobs from running, controls restarts of loads, initiates new loads, collects performance metrics, delivers load reports to users, etc... it is a set of Oracle packages, with loads overloaded procedures and functions, all stuff that every system needs; so why write it many times, have it once and use many times. It becomes the Rolling Chassis for your data warehouse (or OLTP system).

This should, no MUST, be the first thing you design. Once you have this you can just drop new functionality right on top; as you would drop a body on top of a frame. as in the car industry it should be stable enough to use for multiple deliveries and be backwardly compatible (so only ad functionality, not take it away). The whole first part of your project should be designing and developing this. Don't put a single bit of functional requirement code down until you have this done, otherwise you will always be playing catch-up.

As a quick soup to nuts intro into this you "Rolling Chassis" should have:
+ Job definition section, consisting of
- Jobs
- Job steps
- Job events (if needed)
- Functional areas that can execute these jobs
+ Load definition section
- Current loads
- Load occurrences (runs)
- Load step occurrences
- Load event occurrences
- Load event statistics (i.e. number of rows affected)
- Load Errors (see below)
+ Error processing
- Error message table
- Causes and Solutions for each message
- Error occurrences
+ Load relationships
- Branches
- Exclusions
- Concurrency
- Weighting
+ Load reporting
- User subscribes to Jobs, steps & events
- reports metrics and errors
+ Users/applications
- Usage
- Subscriptions
- Permissions

if anyone wants a more in depth description of what and how this should work please let me know and I'll do a more detailed blog entry on it.

See my other site http://www.colliertechnologies.co.uk if you would like some more information on what a Rolling Chassis is.