When I was in high school, a little German lady would show up as a substitute teacher for almost any subject. Apparently, she had a very broad skill set. As I mentioned this was high school, eventually we students would become disruptive, unruly, loud—generally annoying—and our substitute teacher would give us “the speech,” spending what I recall as far too much time explaining to us that “knowledge is power” and how we would be better served by changing our attitudes. At the time I did not believe her exhortations had any impact on 15-or-so year old me, but over the years it turns out she did. As a fledgling in the IT world, I found that actually reading through the reference manuals on the important tools served me well. As I moved into the data world, doing the necessary investigation to truly understand the business objects and pain points users experienced allowed me to help develop solid solutions across the organizations where I was employed.
Technology has grown and morphed greatly over the last couple of decades. We can build solutions hundreds of times more complex than ever before. We have ERPs containing hundreds of thousands of data structures. We have low-code/no-code tools that help us magically get our work done. The enormity of processing, structures, and data is daunting. In the face of this challenging environment, I see a disturbing trend, in that many people are choosing not to learn their tools, or data. Instead, things are handled more passively, either relying on vendors to solve problems or trying to find out what data structures exist or are used only after a problem is identified. And even in those cases, no effort is made to actually retain such gained knowledge for sharing. Yes, diving into the complexities is very challenging. But still, it is a challenge that needs to be undertaken. Vendors will give you a fish, but shouldn’t you know how to fish on your own? Is it in the best interests of you, or your organization, to be entirely dependent on a vendor for resolving encountered data issues? Have the vendors and their tools lulled you into a sleep of reliance?
Divide and conquer has always been a successful strategy. Certainly, it would be a fool’s errand to attempt to understand a few hundred thousand data structures. But understanding a business area, particularly the one hundred or so most critical data objects within that business area, should be a manageable goal. In starting down a path of this nature, one can consider talking first with business staff to comprehend the data area as those business staff understand it. Perhaps a logical data model might be used to sketch out the important objects and logical relationships between them. Armed with a data model as described, the next step could be trying to uncover the data structures implemented in the solution behind these ideas. Maybe the heart of this process is simple, involving just a fairly small number of the many thousands of possibly used structures. The logical data model could be augmented to cross-reference to the uncovered physical implementation pieces. An effort like this helps gather a useful chunk of business knowledge that can be shared across the organization. At that point, perhaps a second business area may be approached and handled similarly. The individuals who help drive the gathering of this information are often seen as valuable resources within the business. Data is an asset, but so are the people who help an organization understand and leverage its data. Knowledge is still power; nothing has changed in that regard over the years.