Something I have been thinking about a lot lately is something I like to call process meta-usability. I define this as:

Process meta-usability: The degree to which a process is able to be operated and understood by those who design, develop, execute, and troubleshoot it.

Process meta-usability is probably a subset of the field of usability. However, with most data-oriented processes (such as ETL and databases), the proof is in the pudding. That is, the people who are actually consuming the data have no idea what went to making it happen, and the old quote about sausage and politics probably applies.

This brings up some subtleties that we need to consider:

• Most people who design data-oriented processes either don’t know or don’t care about usability. They aren’t normally impacted by it at all.
• Most people who operate data-oriented processes are too busy to care about usability, but are greatly impacted by it.
• Most people who sponsor data-oriented process don’t see the need to improve usability, and are impacted by it unknowingly.

To design for meta-usability, a data-oriented process needs to consider:

1. Automation – CPU cycles, disk sectors and memory chips are cheap and reliable. Humans are not. Consider the cost of Moore’s Law vs. the cost of employee turnover for the life cycle of your process.
2. Human intervention – Trap and deal with every possible situation in the design phase. Also, when a human does have to be involved, make it easy for them to understand what is going on at a glance. This probably means documentation, standards, naming conventions, log files, metadata, the works. This isn’t as hard as it sounds, there are some easy steps that you can take to make things run more smoothly for your friendly neighborhood operator.
3. Understandability – A simple process is always better than a complicated one, readable source is always better than faster code. Again, consider standards, naming conventions, and all that stuff that developers hate to consider.
4. Communication – If everyone knows what is going on, it is a lot easier to make things happen. If a process that is supposed to be automated is actually taking someone 10 hours a week to keep running then it is easier to justify spending 40 hours to fix the issue.
5. Downtime – During the design phase, try to calculate the cost per incident of downtime for your data process. If you don’t have any hard numbers, consider the business opportunity cost plus the cost per hour of having an analyst, developer, DBA, and operator all on a conference call trying to figure out what is going on. Compare this with the cost of developing processes to avoid or mitigate downtime and see what side of the curve you want to be on.
6. Staffing – Consider that for any data-oriented system (like feeding a shadow system, data mart, or data warehouse) the bottleneck is most often keeping the overall system running effectively. If it takes longer to resolve issues with individual processes then fewer of them can be run at the same staffing level. This isn’t because of a technological, but because there literally aren’t enough hours in a day.

This entry was posted on Thursday, July 6th, 2006 at 7:24 pm and is filed under Databases, ETL, Information Architecture, Systems Integration, Information Quality, Automation, People, Metadata. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.