My new book, Data Model Storytelling[i], describes how data models can be used to tell the story of an organization’s relationships with its Stakeholders (Customers, Suppliers, Dealers, Regulators, etc.), and how data models can be used to help organizations get from where they currently are to where they would like to be. The book describes, for example, how data models and data flow diagrams can support business process reengineering (BPR) efforts, and how data models can support IT departments in migrating to newer technologies like NoSQL databases, domain-driven development and microservices.
As readers of my books know, I rely a lot on metaphors to get my points across. My books on Agile Data[ii] techniques use home improvement and landscape gardening as metaphors for how data work can be done in the context of Agile software development projects. In Data Model Storytelling, storytelling techniques (and, in particular, Native American storytelling) is the central theme around which the book is organized. I draw heavily from my experiences as a member and officer in Toastmasters, the International public speaking organization.
One chapter of the book in particular has sparked a great deal of interest, and it’s this topic I wish to focus on here: the idea of data professionals as “Data Shamans”. In Native American culture, the Shaman is the “Knowledge Manager” of the tribe. The Shaman is the repository of the tribe’s history, culture and religion, the person the tribe depends on to apply the wisdom and practices of the past to the problems of the present. Shamans are Communicators, Educators, Healers and Prophets. They help the tribe tell its story, provide leadership and insight in times of crisis, and lead the tribe from the present into the future. Far from being mere advisors, they also serve as active facilitators; in some tribes, the Shaman leads the tribe into battles!
The parallel between the role of Shaman in a tribe and the role of Data Management professionals in an organization should be apparent. Like Shamans, Data professionals are the custodians of knowledge about an organization’s data assets; they understand what has been done with data in the past and they can help chart new opportunities for leveraging those data assets in the future. They work with business users and IT to develop new data and BI technologies that increase an organization’s store of knowledge and ability to deliver value to stakeholders. They work to keep an organization’s store of knowledge current, correct, and easy to consume. They help understand and solve data- and knowledge-related problems within an organization. They help guide an organization through challenging times and changing business conditions, and they provide insight as to appropriate and inappropriate ways of using data to achieve business goals. They are not just data modelers and DBAs; they are also Data Architects who can advise on the most effective ways of implementing and using data within an organization. And they are not just advisors; they are also implementers and facilitators.
Most importantly, they tell the story of the importance of data management and the value that good data practices can contribute to an organization. Conversely, they can also tell stories about the consequences of bad data practices. As I said in Building the Agile Database, even our project failures have value because we can always point to them as examples of what not to do next time.
There is one additional parallel between Shamans and Data professionals that I would especially like to emphasize: They are problem-solvers, not just task performers! If I had a dollar for every time I’ve been asked to create a particular table or add a particular column to a table, I’d be sunning on my yacht in the Caribbean. But you wouldn’t ask a Shaman to cast a particular spell or sing a particular chant. Instead, the tribe brings its problems to the Shaman, and the Shaman uses their knowledge of tribal history and culture to solve them. Similarly, we as Data professionals need to be the people our organizations bring problems to, knowing that we have the knowledge of Data best practices that can be applied to solve them.
When I get a request, I try to understand both the context of the data environment pertaining to the request and the real business reason for the request. Does the request fit meaningfully into the context of the data? Does the request help meet a legitimate business need or accomplish a legitimate business goal? Will implementing the request improve the data environment and make it better able to meet the organization’s needs, both now and in the future?
In many instances, I’ve had to push back on some requests as either not necessary, already implemented elsewhere, not appropriate, or needing to be implemented differently. I often have to work with the requestors to understand the real business need behind the request, and perhaps find a more appropriate way of achieving the desired end. Here’s an example: on one project, I was asked to create copies of a central database on individual user laptops, and then implement real-time data replication to each of the remote databases. Digging deeper into the request, I found that real-time data updates weren’t necessary, as the central database was only updated nightly via a batch process. Furthermore, the application on the user’s laptops was read-only; the users weren’t able to update any of the data. I recommended a nightly process to extract the data from the central database into an XML document and send that document to the user’s laptops to be consumed by the application. This approach resulted in a substantial savings of time, money and effort!
Data professionals need more than just data modeling and database skills. They also need facilitation and communication skills, including the ability to manage conversations around data requirements, ask pertinent questions, surface assumptions and push back (as necessary) when requests don’t seem to make sense or could be implemented in a more appropriate way. The need to make sure that everybody is telling (and hearing) the same story, that requests for data model and database changes facilitate the work that everyone agrees needs to be done, and that these requests move the organization’s data, information and knowledge management capabilities forward.
In the same way that members of a tribe wouldn’t ask the Shaman to cast a particular spell or utter a particular prophecy, we need to understand that Data professionals should be regarded as facilitators and problem-solvers, as people whose role is to understand current and future business needs and opportunities in the context of an organization’s current data and information assets. Their job is to help chart and direct the future development of those assets, with an eye toward increasing the delivery of knowledge and value.
In my books, Data Management is all about providing maximum value to organizations. We should not allow Data Management to become defined in terms of specific services provided, platforms or tools supported, or documents produced. Rather, Data Management should be defined in terms of whatever provides the most value for our organizations. As I’ve always said, if the railroads of the last century had thought of themselves as providers of transportation services, rather than as operators of trains, we could all be flying today on Union Pacific Airways! We should never allow Data professionals to be regarded as mere “operators of trains”. This, in my mind, is what “Data Shamanism” is all about!
[i] Burns, Larry. Data Model Storytelling (New Jersey: Technics Publications LLC, 2021). See in particular Chapter 5, “Data Model Shamanism” (pp. 57-63).
[ii] Burns, Larry. Building the Agile Database (Technics Publications, 2011), Growing Business Intelligence (Technics Publications, 2016).
