Separate your charting and data analysis tools from your enterprise tools

Steve DaumOnline debate rages about whether potatoes and onions should be stored together, with the “no” side saying they both give off gases that accelerate spoilage, and the “yes” followers asserting that it makes no difference. Whether you agree or disagree, you can follow the underlying concept: some things do need to be separated in order to perform at their best. (Hence the practice of assigning twins to separate classrooms, perhaps.)

An important principle in software development is known as separation of concerns. The idea is that different concerns should be handled by different bodies of source code. For example, one body of source code should focus on saving and retrieving data from a database. A different body of code should focus on doing statistical calculations; these two concerns should never be mixed in the same body of source code. When this principle is violated, the source code is sometimes described as having a “code smell” which is not a good thing. Even worse than potatoes that smell like onions.

User requirements for software change all the time. They are dynamic. If you have source code nicely compartmentalized, you will be more nimble at stringing it together to meet some new user requirement.

The idea that compartmentalized capabilities allow for a more nimble response to changing needs, applies in situations beyond software development. Consider these two systems which many quality practitioners have experience with: 1) the plant automation system; and 2) the testing lab/testing results system.

The plant automation system will have the ability to automatically gather and store data generated while the operation is running. This data typically flows into a database such as SQL Server. The lab testing system will allow quality technicians to store the results from various quality tests over time.

Both of these systems usually offer some type of charting, analysis, or reporting. There is nothing wrong with these features. They work. They provide value and many people use them. However, each system will report only on its “own” data.

When we visit customers and hear stories of significant quality or efficiency gains, almost always a team has worked on the problem and attacked it with data from multiple systems. If you rely only on the output from the plant automation system, you may be missing important correlations with or signals from data gathered by the testing lab. For this reason, we suggest that you separate the concern of data analysis from the systems gathering the data.

When the charting or data analysis tool can easily consume data from disparate systems, you will be more nimble at analyzing all related data and finding relationships that help you improve quality.

Consider these two metrics: 1) raw material purity; and 2) daily production yield. To see a chart where both of these are represented together may not be possible using only the lab test data or only the plant automation data. However, if your analysis tool is separate from either system, this becomes much easier – you are more nimble at thinking about this data.

Click to enlarge

When your charting or analysis system can easily combine, and keep fresh, a view of data residing in multiple other systems, you will be more nimble at thinking about and reacting to signals in the data.

And if you want to keep potatoes and onions fresh, you might want to consider the same principle.

One thought on “Separate your charting and data analysis tools from your enterprise tools

  1. Pingback: Carnival of Quality Management Articles and Blogs – June 2013 | The world is too small? or Is it?

Comments are closed.