Data at Rest
Data doesn’t do anything unless you give it instruction. Think of your credit card number. It is yours, it physically resides on a coded plastic card. At some point you instruct your data to wake up and do something (i.e. pay for a product/service). Data at rest is basically a resting stop (i.e. a base of data, a database) and it does nothing while it rests.
You care where you stop to rest, yes? Your data is no different. A database may be too small to scale. Ever worn pants that are too tight? Point well taken. A database may have been built for one purpose and being morphed to serve another (3rd party software is a classic example).
You wouldn't want to stop at a dirty rest stop would you? Since folks tend to believe was is printed, the same holds for reported data. Too often, data quality is based on the the completeness of a record or some measure of reasonableness (see section on data truthiness).
One more itch to scratch here, the most critical data quality metric is missed by most. It's data freshness. Once data rests, it starts decaying. Data decay may take 100 years (e.g. social security number) or decay occurs in a nano-second (e.g. stock price).
Multiple data rest stops collections (databases) exponentially increase the complexity to analyze the information.
Sound architecture to the rescue!
Chose your data architect wisely! Their products are the very foundation of your IT assets and have long lasting effects. Presale due diligence of a 3rd party vendor's data rest stop will save you thousands if not millions over a decade.
Build an independent review into your SLDC process (pre-production) to ensure the following criteria is met: The data rest stop will to serve a multiplicity of purpose and volume. Databases outlive applications so they need to be designed with lots of flexibility and scalability. Off course there are trade-offs but one thing for sure, the more business acumen along with technology advancement incorporated into your database design, the better. No small feat.