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.

why "wooden jeep"

The phrase "wooden jeep" comes from an analogy I like to use when dealing with, what I like to call "non-intelligent", suppliers that are giving the users I am working with just what they have asked for rather than what they need. In my analogy a new user, one that has never seen a jeep before, (this a new system they have not had before), has asked the supplier for a wooden jeep (why they asked for this in the first place is a whole other analogy for another posting later on), and the supplier has said “OK, I can do that”. Then they deliver wooden jeep to ther users, only to have it break or not perform as soon as the user trys or starts to use it. Now having this happen makes the user feel disgruntled, so he goes to the supplier and says “that jeep you made me doesn’t work, the first rock it came to it broke?”. To which the supplier replies, “but those were your requirements, I just gave you want you asked for.”

But did they?

The user had never seen a jeep before, didn’t know what it should do or not do nor how it should be made; and therein lies the rub, so to speak. “how it should be made”. The users requirements were actually that they "wanted a jeep", not that they wanted a wooden one. The “non-intelligent” supplier had taken a requirement mixed up with a design; and designing is the supplier’s job not the user's. The supplier should have separated the requirements and left behind the rest that’s not (kind of like the candyman with tomorrow & sorrow - I do tend to relate a lot of things back to song lyrics); as well as going back to the user and telling him that design is the supplier’s job, not the user’s. After all that isn’t that why the user had hired/engaged the supplier in the first place.

The supplier, who after all knows jeeps, should have told the user, a wooden jeep may sound nice and pretty and ergonomic, but it isn’t practical; what you need is a strong jeep made from steel with rubber tires, and leather seats and a Bose stereo; pointing out that, those last bits might be extra cost options and that the steal one might actually cost a bit more than the wooden one, but that it would be worth it in the end. Then when the user got his metal jeep and took it for a spin, he would be happy, and very glad that he had an intelligent supplier. And would probably buy all sorts of other options to go with his new jeep, maybe even taking off road driving lessons from the supplier. Instead of burning his wooden jeep and never going back to the suppler again.

And isn’t that what everyone really wants, happy and content users and satisfied and proud suppliers?

Be intelligent…
Users: listen to your “intelligent” supplier, ask for requirements, not design, separate the two, don't let your emotion dictate your system.
Suppliers: be intelligent! only get requirements from your users and then do your own intelligent design, it will pay off in the long run. What you have to do is "add a little love and make the world taste good" for your users; and then just as Sammy Davis jr did, they will keep coming back to their candyman for more.

What do you want?

In the world of IT Suppliers & Users, users quite often think that they know what they want, after all they are the users, the ones that the systems are built for, are they not. But do they? One thing humans, in general, dislike is change; so when a user is asked, by a supplier, “what do you want?” in their new IT system, they will quite often say, "well just what I have now, really". Which is OK if they already have a great IT system, but if they are being asked that question then 99 times out of a 100 they won't have one. So what they think they want, quite often status-quo, is the last thing that they should be delivered. Or why else build a system. The new system should initiate new way of doing things and new processes. Better ways of doing things, ones that make use of the power of the computer or database that their system is being built on, one that makes them use their time better and one that makes sense. So how do they journey from getting what they want to getting what they need?

This is what this Blog is about… the going from getting what you need, rather than getting what you want (or think you want).

It is about developing the “intelligent user” and/or the “intelligent supplier” in us all.

Wooden Jeep...

You can't always get what you want
But if you try sometimes you might find
You get what you need...

or at least that is how it should be.