In healthcare there’s a well-known goal of enabling everyone to work at the top of their license. We want surgeons to perform surgery and not manage anesthesia. We want nurse anesthetists to manage anesthesia and not perform blood draws. We want phlebotomists to perform blood draws and not transport patients. You get the idea. We want our clinicians to be able to focus as much time as possible on tasks that best utilize their skillset and are most appropriate to their licensure, and hand off the rest.
On the data side of the healthcare world, we may not have regulations and licensing bodies that restrict what tasks we can and cannot perform, but the concept of everyone working to the top of their “license” still applies. Data architects* are really good at getting data from source systems and integrating that data in a platform that makes it consistent, trusted, and easy-to-use. Data analysts excel at asking questions of data and then interpreting and communicating their findings to decision makers. Visualization developers can make data accessible so that end users can retrieve and conceptualize the information they need, right when they need it, to do their job well.
Do data architects create visualizations of the data they work with if needed? Do data analysts often have to pull together data from multiple sources, mapping and scrubbing the data so they can use it? Do visualization developers sometimes have to dig into the data to explain why it looks the way it does? Yes to all of those questions. Especially in small organizations with fewer resources dedicated to data and analytics, data practitioners wear multiple hats by necessity. But these scenarios aren’t the most efficient and effective way to get the job done. When a data and analytics team is large enough to have people in discrete roles, it makes sense to have them focus on what they are best at, and hand off the rest.
But what about the fact that the data architects are often the biggest bottleneck in the process? The reason so much data integration, mapping, and scrubbing happens by other members of the team is because they don’t have time to wait for the data architect team to create the pristine final product for them to use. They have demanding customers like everyone else and need to produce the requested report or analysis yesterday.
The problem is we have allocated too much of the scope of the data request fulfillment lifecycle to data architects. We have put too many of the necessary tasks to build data and analytics structures and reports on the plate of the data architect. This has happened primarily due to the fact that the tools of the data architect’s trade that automate data movement, mapping, and scrubbing require specialized training, and those tools aren’t flexible enough to allow other members of the team to participate. But the expertise necessary to contextualize, map, scrub, and integrate data is not something only data architects have.
Data analysts and visualization developers are able to understand and work with data as well as data architects, and often have stronger subject matter expertise in the data content by virtue of their more customer-facing roles. So what we need to do is reevaluate the overall data request fulfillment lifecycle and allocate the right tasks and responsibilities to the right roles, then require that our tools support that reallocation. We can attest from experience that this is possible without training everyone in ETL tool development, for example.
If you’re interested in learning more about how to optimize your data and analytics team and get everybody working to the top of their license, read more here and reach out to us to talk with our team!
*Editor’s note: Some split out data engineering and data modeling into two distinct roles, but we tend to combine the two functions under one title called “Data Architect”.
