In a world as interconnected as ours, it’s difficult to overstate the value of secure information exchange. blockchain technology delivers a secure record of transaction, using cryptography to interlink records. It’s the basis for cryptocurrency, but also has applications in virtually every industry, from finance (capital markets) to retail (supply chain management) and health sciences (medical drug development). Small wonder, then, that investment is growing. In 2021, global spending on blockchain amounted to $6.6 billion and will grow to reach nearly $19 billion in 2024.
How are blockchain organizations tackling data management? To learn the answer, we sat down with Karla Kirton, Data Architect at Blockdaemon, a blockchain company, to discuss data strategy, decentralization, and how implementing Alation has supported them. Here’s a recap of our discussion.
Karla Kirton, Data Architect at Blockdaemon: The first question I was asked when I started at Blockdaemon was “how would we approach data?”
We had the obvious choices in front of us: centralized vs. decentralized. So, we started looking at what our use cases were going to be, what we wanted to do with the data, and whether we wanted an offensive or defensive data strategy, or even a mix of both. All of that helped us to decide on a decentralized approach, which was a natural fit for our industry.
Then we looked at the structure of the teams to make sure that we were working in domains and squads, to match that decentralized approach. We looked at how we wanted to use data, how we wanted to make sure it is self-service to people and that it scales, whilst making it understandable and discoverable.
We decided to split the approach into three categories: people, policies, and technology. We started with the policies…. We then moved onto making sure that from a technology perspective our tech stack was what we needed. And, we have now moved on to getting people engaged with those two other aspects – ensuring that they understand the tech and policies, and understanding how they interact with the data – which is where Alation came in.
Karla: Well, they’re twofold. We wanted to introduce a Kappa architecture to serve not only our operational data needs, but our analytical data needs too.
And we wanted to do this through one data architecture where possible, so that we didn’t duplicate processes. We made data available to those that needed it and the experts that are there.
It’s a platform-focused architecture, which means that the data experts and the domain team, who know the data the best, can direct their focus towards optimizing the data platform and making it available to the rest of the business.
So, once you’ve considered that, you are essentially building data as a product. And as soon as you start talking about data as a product, it needs to be discoverable, understandable, accessible, secure.
Karla: Since we decided we wanted to decentralize our data, we inadvertently went down the data mesh route without necessarily picking it from the start. It was just a natural fit with what we were trying to do. We were trying to make data available to those who need it, so we wanted it to be self-serve and make the data discoverable.
It meant that domain teams would own their data and we would build a platform that supports them to do just that, while still allowing the business users to access the data themselves. Essentially, we were producing data as a product.
Secondly, we decided we wanted a more decentralized (or federated) approach to data governance as well, because of the capacity for scalability.
We wanted to make sure that the people who understand the data are also aware of the principles that they are subject to. So, they are contributing to their own data governance, and feel empowered to do so and we’re not just defining it top down.
