![[2025-01-08_Self-service Analytics-1.png]] *This is the first of a four part series on self-service analytics. For the future parts, please check out [my substack](https://substack.com/@ryanlynchlog).* # Why Do Self-Service Analytics? Self-service analytics is an enterprise-level data approach that prioritizes enabling business (or non-technical) users to directly access data. A self-service data analytics architecture has two primary characteristics, each offering significant benefits: 1. **Creates a single repository of enterprise data** that is strategically designed, curated, and accessible to business and technical roles, as well as enterprise applications: - Prevents data silos by enabling all business units to work with a holistic[^1], federated version of the data - Promotes centralized data governance, entitlements, and security, while enhancing collaboration, cost-effective storage, and scalability 2. **Makes data accessible to interested parties** in a way that matches their needs and skills: - Reduces lead times in leveraging data for decision-making, as business users no longer have to rely on IT or technical counterparts for answers - Improves efficiency and productivity, enhances data literacy, reduces IT workload, and fosters innovation ## Oh, I want THAT! Yes, who wouldn’t want that? But many skeptics argue that “true” self-service analytics isn’t possible. If your vision of self-service analytics is a 100% non-technical marketing or business user finding the weakest part of the customer funnel with a blank slate of field names and a low-code tool, then props to the haters—they’re probably right. I prefer to think of self-service analytics as existing on a spectrum (one that doesn’t even include the holy grail[^2] mentioned above). With a tightly scoped target state, I believe a valuable implementation of self-service analytics is achievable and worth pursuing. Where an organization lands on this spectrum comes down to life’s greatest variable—_people_. ![[Self-service Analytics 2025-01-08 10.47.36.excalidraw.svg]] %%[[Self-service Analytics 2025-01-08 10.47.36.excalidraw.md|🖋 Edit in Excalidraw]]%% Most enterprises today manage their data through data models or pipelines in their data layer. The bulk of data-related work falls on the shoulders of technical resources operating in data-intensive environments. The goal of self-service analytics is to shift some of this workload to less technical users by introducing a level of business [[abstraction]]. In the end, you’ll land somewhere along these axes. ### The Bad In the worst scenarios, you venture too far down the spectrum in ways that don’t add value: - **Enterprises with No Analytical Capabilities**: If only non-technical users are working with data they don’t understand, then…well, we’d better figure out what they’re actually "working" on. Essentially, this results in a lack of analytics, as skilled personnel aren’t in place to make sense of the data. - **[[Shaw's Principle]]**: George Bernard Shaw once said, “_Build a system that even a fool can use, and only a fool will want to use it._” If your self-service analytics system is overly simplified and rigid, it becomes unlikely to provide significant value, regardless of the user. ### The Ugly If you don’t approach self-service analytics with a "people-first" mindset, you end up here. You may have a beautifully crafted solution, but it’s simply not being used. - **Skill Gap**: While the data is accessible to business users, they lack the skills to manipulate it for analytics. Depending on the level of business abstraction, users may need technical knowledge ranging from data model fundamentals to low-code tools to advanced SQL skills. Without these skills, your “self-service analytics” solution becomes a multi-million-dollar “export to Excel” tool as users seek to put data into a format that works for their skillset. - **Personnel Issues / Costly Training**: To address the skill gap, you decide to invest in upskilling your business users. Great! But this comes with significant financial costs that may erode the benefits of self-service analytics. And, in the end, you might get a two-week notice from your business team saying: “There’s a reason I didn’t major in data analytics!” ### The Good Ah, the sweet spot! Here, you’ve considered your people, defined a set of capabilities tailored to their needs, and designed a system abstracted to their preferences. Your solution may not look like the mythical city of El Datarado, but it adds significant value to your business and supports the growth of your employees. At the end of the day, your business can serve itself. That's the point, isn't it? It’s nice to envision this self-service sweet spot, but how do you make it a reality? As an enterprise and data team, you must answer key questions that help determine your practical position on the self-service spectrum. To make sure you ask the right questions, I recommend thinking about it from a People, Process, & Technology mindset. We'll discuss this more in part 2 of my self-service analytics series: [[Self-Service Analytics - The Quintessential Problem for a People, Process, and Technology Mindset]]. # Footnotes [^1]: Boy, I do not like these terms. But, they're staples in the world of 'self-service analytics', so I'll use them this once and track them in my always expanding list of [[obtuse language for marketecture]]. [^2]: I do think a "holy grail" implementation of self-service analytics is possible in small-mid size startup type environments, where the workforce may be more flexible. In general, self-service analytics is pursued by enterprises, though, so I will focus on them as my audience. #blog-post #technical-deep-dive