Note: For this issue, I have invited one of my students as a special guest contributor, Jason Minton, to be Dr. Minton. Jason is an experienced IT professional with more than 20 years of experience in the field. He has served in various technology architecture roles (enterprise, network, infrastructure, data) and IT leadership roles. He currently serves as an enterprise data architect in state government. He holds a master’s degree in enterprise architecture and in May, will complete his Ph.D. in Computer and Information Sciences with an Emphasis in Information Quality. He also holds multiple professional industry certifications. Jason’s research interests are the intersection of Data Quality and Enterprise Architecture, technology frameworks and models, and streaming telemetry data architecture and integration.
—John R. Talburt
Imagine this scenario. A clinic exists named the Enterprise Architecture Medical Clinic. You wake up with chest pain and visit the Enterprise Architecture Medical Clinic to be seen by a doctor to diagnose the root cause of chest pain. You meet with Dr. Enterprise Architecture (Dr. EA for short) and you have the following conversation with Dr. EA…
You: “Good morning, Dr. EA. I experienced some chest pain when I went to bed last night, and the chest pain is continuing this morning.”
Doctor EA: “Well, based on my extensive knowledge of medical frameworks, it appears you have … [Dr. EA feverishly flips through random pages of a medical book] … either indigestion or an upper respiratory infection. I’m 62% confident.”
You: “Thank you, Dr. EA, but would running some tests be a good idea first?
Doctor EA: “Well, tests are good, but we really shouldn’t waste a bunch of time focusing on tests and the like. We have a lot going on at the Enterprise Architecture Medical Clinic. Besides, we just make holistic assessments. I am going to write you a prescription for some medication that may or may not be the correct medication for whatever you might have.”
You: “OK … and what if the medication is incorrect?”
Doctor EA: “Then we will try a different prescription in a few weeks! That’s what’s awesome about my iterative treatment approach!”
Would you trust Dr. EA with your health? Probably not. My recent study revealed that 62% of organizations do not measure Data Quality in their Enterprise Architecture. That’s akin to trying to take the organization’s temperature, but you’re unsure if the thermometer works. Like our questionable Dr. EA, EA practitioners make critical prescriptions and create treatment plans for organizations without verifying the quality of the underlying data. We are essentially saying, “We think our business has a fever of 104 degrees… possibly… the thermometer was sitting in a drawer for quite a while. We’re not sure when it was last calibrated, and we think the batteries might still be working.”
My study also revealed that only 15% of technology architects rated themselves “Very Familiar” with Data Quality concepts. That’s like 85% of doctors saying, “Blood tests? Yeah, I’ve heard those can be helpful and provide insights … but I prefer to go with my gut.” I realize this is hyperbole and all in good fun, but the disconnect that’s been discovered between Data Quality and Enterprise Architecture may have serious implications for the enterprise such as wasted resources, increased business risk, architectural gaps, flawed enterprise decision-making, and reduced EA value proposition.
The fundamental issue isn’t that our heroes on Data Management teams aren’t running tests (they are always diligently checking vitals across the enterprise), but the enterprise doesn’t see the test results or understand the impact of the results of the tests. The problem is that while Data Quality has an enterprise-wide impact (like the patient’s actual condition), it doesn’t have enterprise-wide views (the Doctor’s comprehensive understanding). Meanwhile, Enterprise Architecture has the perfect diagnostic framework and the magnificent building to house all tools, but isn’t checking if the instruments are calibrated.
A wise person once told me, “The answer is usually somewhere in the middle,” and I believe that’s true for the prescription to alleviate Data Quality blind spots in Enterprise Architecture. Specifically, a Data Quality module should be incorporated directly into the Enterprise Architecture (preferably in the data architecture domain). What would this do? It would be like giving Dr. EA reliable lab results integrated directly into our health chart. Enterprise Architecture already has holistic views across the enterprise and executive sponsorship and serves as the central repository for standards, models, blueprints, and guidelines — the perfect medical chart for organizational health. The picture below shows an example (in theory) of what incorporating a Data Quality module into Enterprise Architecture may look like:
The next time you’re in an exam room at the Enterprise Architecture Medical Clinic, ask yourself: “Would I risk my organization’s health or make an enterprise decision without checking the quality of the data used to assess organizational health or make enterprise-wide decisions?” Let’s face it: Prescribing enterprise solutions with bad data not only increases organizational risks, decreases customer satisfaction, and causes massive inefficiencies, but it’s also organizational malpractice.
Remember: Even the best doctors in the world are only as good as the tests they run. Your Enterprise Architecture should be no different.