Far too often, business users seem consumed by the systems they handle. This makes them unable to define the necessary business processes or needs of the organization. All these users can do is describe what their off-the-shelf packages provide for them. In fact, most users take great pride in their “understanding” of the current system.
These users often have cheat sheets that list the exact steps they must follow for one situation or another. The same users may not be able to explain why such steps are of business value; but similar to a good sorcerer’s apprentice, they understand that no variances are allowed, otherwise bad things may happen.
Does this mean these purchased packages are perfect in every way, and meet every conceived need? No, because these acquired solutions tend to fall short. But these same users are blind to the obvious shortcomings that are evidenced by the work-arounds that become standardized within the practices and then end up leaving mangled and misused data elements all over the place in service of doing the tasks the users need to do.
Sadly, until aspects of these packages become quite unbearable, or work-arounds start failing, users won’t even acknowledge there is any problem at all. The users have gone too far in accepting what they have as it is. And in so doing, how the system exists is considered the standard and therefore inevitable.
Accepting the off-the-shelf package’s physical implementation as a valid description of the logical business is an easy decision for many users to make. Largely, the easiness of this acceptance consists of being able to step back, not think, and not get overly involved. It is an approach that does not rock boats, or stick necks out. And many organizations keep people burdened under enough assignments that there is no time allowed for self-reflection, so how could they possibly have time to question why?
However, these choices may leave business needs unacknowledged and unfulfilled.
And if, as with many off-the-shelf packages, a solution offers customizable components, in their desire to avoid involvement, the users’ efforts will only help give rise to chaotic and contradictory customized aspects of the organization’s shiny new packaged software.
Implementation of custom items relates to external results as opposed to any internal meanings and logical necessities. Reverse-engineering the results of such customizations can lead investigators to feel as if they have fallen down Alice’s rabbit hole.
Under these user-blind circumstances, attempting to detect any canonical or business data models becomes problematic. These kinds of users unknowingly work against such goals. At best, these users try to explain what the developers of the solution did, as opposed to identifying exactly what is the corporate necessity. Modelers and architects must search for the few users who may see beyond the superficial workings of the existing applications. Ideally, each organization has at least one individual, a user or perhaps an executive, who rises above a given solution and can articulate the business need being solved. And, preferably these visionaries can express the future needs that are on the horizon.
A data architect must search far and wide across a great many other businesspeople to find the right individuals to help. If these useful folks are not readily available, modelers may try and work with likely candidates from the existing user pool to help them see beyond the current system. Such endeavors may seem time-consuming in the short-run, but in the long-run, they can make the difference between failure and success. These visionaries are rare gems in the corporate landscape, and they must be identified. For without the special insights from these individuals, efforts for enterprise or canonical data models are doomed to be insufficient as well.