JCK - A Veteran-Owned Small Business
EXCELLENCE IN DATA ARCHITECTURE

since 1989

America Support You
4348 Pine Grove Ave
Fort Gratiot MI USA
48059-3732
V: 810 982-8639
Business Event Analysis & Modeling (BEAM™)

BEAM™ for Decision Support Systems

Extended Relational Analysis (ERA™)

Structured Query Language (SQL)

Course Offerings

Schedule & Registration



What is User Focused Data Architecture?
Regardless of their technical competence, technicians have a weakness: they love to tech. They’re far more interested in their tools and technical environments than they are in the operational realities they’re called to serve. If you doubt this, just listen to their conversations or read their publications. They’ll talk at length about using the most powerful tools to build the most exciting new technical implementations, but the type of operation (banking, insurance, transport, etc.) being served by this wizardry is secondary – almost irrelevant.

Users have an opposite focus. They want their operations served well by the systems the technicians develop, but the less they have to work with the gritty details, the better. After all, who wants to spend a lot of time in analysis sessions with IT?

So we have technicians interested in things technical, almost to the exclusion of operational considerations. Users care about their operations, but technical details not so much. Metaphorically, the two parties are facing opposite “directions”, their backs to each other, each focused on their own sphere of concern.

It’s between them, behind both backs where they aren’t looking, that the problems sprout.

A clue to the nature of these problems is the “ugly surprises” phenomenon: unexpected and unwelcome changes late in the development process. Ask a technician why there are so many ugly surprises, and you'll probably get told that it’s the users, and how they’re always coming up with aspects of things that never got mentioned before, or new details that seem to come out of the woodwork. Ask a user where the problem lies, and they’ll probably start going on about how the technicians keep neglecting details, or balk when the users remember some data they need tracked that got forgotten, or ask vague questions and document the results in cryptic and abstract forms.

A surprising amount of problems spring from missing or incomplete operational definitions. Poorly structured data – which restricts or dictates how systems can handle information – accounts for more difficulties. Get those problems addressed, and you’ll go a long way toward resolving those ugly surprises.

What if technicians or analysts could learn what questions to ask to elicit the necessary information about the operation from the users, and then learn how to document the results in a way the user could understand and verify?

What if users could learn what the technicians were expecting, how to answer their questions quickly and accurately, and how to understand the resulting document?

 

Back | More