![]() JCK - A Veteran-Owned Small Business |
EXCELLENCE IN DATA ARCHITECTURE since 1989 ![]() |
4348 Pine Grove Ave Fort Gratiot MI USA 48059-3732 V: 810 982-8639 |
| Training | Consulting | Experience & Colleagues | Articles & White Papers | About Us |
|---|
|
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? |
|
Since 1989, JCK has been devoted to teaching and implementing the principles of User-Focused Data Architecture. UFDA is based on the principle that the users are the data experts in any organization. Sound data architecture should focus on extracting the user's knowledge, clarifying ambiguous defintions, and building understandable data structures. These definitions and structures serve as the basis for system development. The first and most well known UFDA technique is Extended Relational Analysis ™ (ERA), which has been proven for decades. More recent techniques include Business Event Analysis & Modeling ™ (BEAM), which is useful for both Transactional Systems (BEAM TSS) and Decision Support Systems (BEAM DSS). |