There comes a time at the start of a new engagement when the data architect must acquaint himself with the system for the first time. When first learning about a new application, the relevant data, and its foundational concepts, many questions are reviewed. Some of the more familiar questions include the following: what is the intent of the application; What are the supported functions; who uses the application; what data points get retained; what progression of states for the objects is maintained by the system; and what events drive the application? Additionally, when investigating the replacement of an existing application, the questions focus on such areas as, what new features or functionality need to be added and what current functionality is never used? However, to truly start diving deep into one's investigation of an application and expose the raw core of truth, questions need to probe further into active usage of the system.
Data modelers must never forget that users are creative. And in being creative, users will find ways that any application can be expanded to serve additional needs. The investigator needs to uncover ways an application may be used that falls outside of documented or even initially intended functionality. Such issues may prove very hard to reveal. The assisting subject matter expert [SME] may not have complete familiarity with every usage variation of the full user community; or worse, some unintended uses may be so ingrained in the general protocol that these work-around functions appear "invisible" to an average user. Sometimes, the clue to such practices occurs in certain followed procedures that may seem out-of-place, arbitrary, or even irrational. Unintended usage of an application creates ambiguity about the application's scope, which will make it awkward to clearly define a "next generation" version. The ambiguity comes from a lack of explicit recognition over which functions really are supported. In a worst case scenario, these hidden uses can become the source of scope-creep as replacement applications are developed.
One approach to ferreting out unintended usage occurs through a procedural evaluation of the data structures. Such an evaluation would include stepping the SME through a table-by-table and column-by-column review, verifying the meaning of each element, perhaps supporting this process by reports that profile the distribution of values across each column. Inconsistencies found at this level often highlight those unintended features which show up as data values that are at odds with an attribute's meaning. If a column always conveys one set of values and is named as such, yet this same column occasionally contains a different set of values that mean something else entirely, one has likely found an "extended use" of an application. It is in such polymorphic uses of data items that a definition of a field can vary based on the content of a secondary field. The data modeler must keep in mind that any data items that require external data item values to drive the meaning of an element usually flag a data design weakness.
Truly learning an application means becoming familiar with both the good and the bad. This deep level of understanding a system's requirements is only reached when both the uses and abuses of the processes are known. Knowing and appreciating why abuses are made is not an acceptance of such misuses, but it signifies recognition of the actual needs of the user community. Data architects and designers that go the extra mile to examine this "underside" of applications' employment will find that they will develop a better working relationship with business. By exploring the users' extended needs, architects will find they can relate better.