Understanding the Maturity Levels of Analytics as Code (AaC)

Analytics as Code (AaC) is becoming increasingly vital for organizations striving to leverage data effectively. Many vendors now offer various forms of AaC, enabling developers to work seamlessly with their platforms.

With the exponential growth of data, traditional methods of handling analytics—primarily velocity and agility through graphical user interfaces (GUIs) and manual processes—are no longer enough to meet the demands of modern business environments.

Many vendors now offer various forms of AaC, enabling developers to work seamlessly with their platforms. However, the landscape of AaC is diverse and rapidly evolving, making it crucial for organizations to understand the different maturity levels associated with AaC platforms. These levels reflect the sophistication and integration of AaC within a platform, impacting how effectively teams can create, operate, and consume analytics.

At GoodData, we’ve heavily invested in and used the AaC approach for quite some time, and dare I say, we know what works. In this article, I’ll give you a glimpse of how we think about AaC's maturity.

Understanding the maturity levels of an analytical platform’s AaC capabilities is essential for any organization aiming to leverage its data. By assessing these maturity levels, businesses can make informed decisions about which platforms and tools to adopt, ensuring they align with their data strategy and goals.

Assessing AaC Maturity

We assess the maturity of an analytical platform’s AaC capabilities through three primary criteria:

1. Creation: How developers create analytical solutions from data preparation to building analytics.
2. Operation: How developers manage the lifecycle of the entire analytical solution, including version control and environment deployment.
3. Consumption: How developers consume analytical content to build applications or conduct advanced analyses.

These three views help us understand the whole story of analytics and cover the whole data lifecycle. Though it might seem like an oversimplification, as analytics can get very complex, they catch just enough detail to give representative insight into the whole process.

Phases of AaC

With this perspective, we identified six levels of product AaC maturity. As the products are evolving over time and as they try to adapt to different market needs, they are emphasizing different criteria. We defined three primary phases when integrating the Analytics as Code mindset into the Analytics:

Pre-AaC Phase

• As the name suggests, a phase before you even approach AaC.
• Levels -1 and 0.

AaC Phase

• AaC has been implemented in some use cases, but the developer velocity and Developer Experience (DX) of it are lacking
• Levels 1 to 3.

AaC Synergy

• AaC is the bread and butter of your platform, developers enjoy working with it.
• Level 4.

If you are evaluating AaC aspects of a product, always evaluate which phase the product is in currently, if the product (or the vendor) passed the previous stages, and where the product is heading. Regarding the future, the key question is - what criteria does the product emphasize now and what is its ambition.

Let’s explore these more, adding levels to cover the nuance. We’ll start at level -1 (sorry, developers) because some tools don’t fit well with the as-code approach. I’ll list a platform for each level that I think best describes the level. If you have a different perspective, feel free to reach out to me on our Slack channel.

Pre-AaC Phase

This phase is, so to speak, the “stone age” of analytics as code. Essentially no fancy tools that developers use nowadays are at use here.

Level -1: Old Tableau or Excel

Level -1 is the absence of analytics as code. Of course, you can create analytics with vendors at this level, but your solution will be rigid. It will also lack agility or transparency and be hard to maintain overall.

• Creation: Only through vendors’ UI.
• Operation: Managed by the vendor.
• Consumption: Limited to the product’s capabilities.

Vendors at this level offer no API for working with analytics, relying solely on drag-and-drop interfaces. Analytical results are stored in proprietary formats, often inaccessible to users.

Level 0: Power BI Export to JSON

Level 0 is the first step in the right direction (the direction being AaC). If you ask your developers to create something with the APIs provided, they will quickly get frustrated because the APIs will be lacking or nearly non-existent. Moreover, the capabilities are usually very limited at this level.

• Creation: Only through vendors' UI.
• Operation: Basic versioning is possible through complex API payloads.
• Consumption: Limited to vendor UI.

At this level, vendors provide APIs for platform control rather than analytics creation. Users do not need a domain-specific language (DSL) to build analytics, and the API is a side product of other activities.

AaC Phase

In this phase, the GUI-first approach finally starts to break, and we see that APIs are no longer a swear word. Though the API experience might not be perfect, it is usually enough to have most of the analytics journey done as code. In the higher levels, we also see DSL, which makes creating metrics much easier.

Level 1: Good old GoodData Platform

Level 1 could be called “as code by accident.” Usually, the motivation to have analytics as code comes from operational needs. There is no plan or intention to use the as-code approach for creation or consumption.

• Creation: Primarily via vendor UI; limited code options.
• Operation: Enhanced by SDKs and manageable API payloads.
• Consumption: Via vendor UI or custom applications using APIs and SDKs.

Companies at this stage offer an API-first approach, which means that users can build the analytics even outside the platform using a code approach. Usually, there is no Domain Specific Language (DSL), or the DSL is very simple. Most of the time, you work just with the technical serialization of objects, e.g., JSON is used for the API calls. The experience for builders is very limited, and the main interface for creators is still the visual user interface.

Level 2: Looker, Lightdash, Thoughtspot

Level 2 is characterized by the need to have domain-specific language (DSL) for analytics creation. Hand in hand with that goes integration with the git (or similar) versioning system.

• Creation: Via UI and proprietary DSL.
• Operation: Improved with integral versioning and easier editing through DSL.
• Consumption: Similar to Level 1 but enhanced by DSL.

Vendors provide a proprietary DSL and tooling that enable developers to sync analytics in an IDE. However, the experience is often split between the IDE and a visual interface, limiting developer satisfaction.

Here, I have an important note on two vendors, as with some changes, they could easily be at a higher level.

Looker has a very comprehensive AaC approach and is the most successful company for Analytics as Code. However, their DX could be better, as there is no official support outside the Looker environment.

LightDash relies heavily on dbt for data models and metrics, which is a good example of tool integration. However, they don’t have as-code support for dashboards and reports going beyond API JSONS.

Level 3: Malloy, GoodData Cloud, Holistic

Level 3 is the highest currently on the market. Each of the vendors currently on the market has one or two things missing, which makes them a little short of level 4.

• Creation: Seamlessly via UI or code in preferred IDEs.
• Operation: Integrated with other tools via shared repositories.
• Consumption: Additional interfaces like SQL, Pandas, and FlightRPC on top of the semantic layer.

The DSL and IDE integration enables developers to benefit from the IDE capabilities and wide ecosystem of IDE plugins. Next, it is possible to validate the coding results directly from IDE without switching context between different tools.

This is very important, as the developers can focus solely on one thing and don’t have to validate the results in another app, which often breaks their flow and it also makes it harder to validate the results.

With additional interfaces like Pandas and FlightRPC, you can consume the analytics on virtually any platform. This is especially important if you have multiple tenants, or if you have diverse end-users.

AaC Synergy

Finally! This is the cream of the crop, the pinnacle, and the chef’s kiss of analytics. Each of the three steps in this phase is unified into a seamless experience where each department can easily collaborate. For example, the UI can be backed by a git repository, so your analysts don’t sweat.

Level 4: Advanced Integration

Level 4, the holy grail of Analytics as Code. At this level, the vendors use the full potential of the developers and the tools they've honed for decades. Unfortunately, no one has fully achieved this level, so let’s see who wins the race.

• Creation: Unified across multiple tools.
• Operation: Close connection between tools based on shared layers and interfaces.
• Consumption: Seamless across different analytical and data tools.

This level represents a synergy of multiple tools, with tighter integration between analytics DSLs and other data-related tools. Developers can control analytics end-to-end within their IDE, benefiting from a unified workflow. This means that they can easily create tests for every part of the analytics and make it.

Conclusion

Analytics as Code (AaC) is not just a technological advancement; it is a transformative approach that redefines how organizations interact with data. As we move further into the digital age, the ability to integrate analytics into the development lifecycle becomes increasingly more crucial. AaC provides a structured framework for creating, operating, and consuming analytical content, thus enhancing developer productivity and ensuring more reliable and scalable analytics solutions.

Understanding the maturity levels of AaC is essential for any organization looking to use the full potential of their data. By recognizing where your organization stands within these levels, you can identify the necessary steps to advance your capabilities. This progression is not merely about adopting new tools but also about fostering a culture that values data-driven decision-making and continuous improvement.

Key Takeaways

• Pre-AaC Phase: Many organizations start here, relying heavily on traditional GUI-based tools with limited programmatic control. While this phase might seem sufficient for basic needs, it quickly becomes a bottleneck as data complexity and volume grow.
• AaC Phase: Transitioning into this phase marks a significant improvement in how organizations handle analytics. API-first approaches and the introduction of DSLs enhance flexibility and efficiency. However, there are still challenges to overcome, particularly regarding developer experience and integration across different tools.
• AaC Synergy: Achieving synergy is the pinnacle of AaC maturity. At this level, organizations enjoy a seamless and unified workflow, integrating analytics deeply into their development processes. This stage represents the full realization of AaC’s potential, offering unparalleled agility and insight.

Join the Conversation

Whether you are starting with AaC or are well on your way to achieving synergy, there is always more to learn and share. Reach out to us to discuss your experiences, challenges, and successes. Let’s work together to push the boundaries of what’s possible with Analytics as Code.

Are there any vendors or tools we missed? Have you encountered unique challenges or found innovative solutions? Share your thoughts on our Slack channel for deeper discussions. Together, we can drive the next wave of innovation in analytics and ensure that our organizations remain at the forefront of the data revolution.