Watch now | Recording of AURA - Juha Korpela & Shane Gibson - 28 August 2026

Welcome to another AURA session. Good to see you again.

Hey, Shane, good to be here.

Hey, and yeah, what's top of mind over the last month?

Oh dear, data things of all sorts of kinds. Yeah, yeah. And I mean, lots of things again still going on with context and knowledge graphs and, you know, all of that stuff. It's just, you know, my brain's buzzing all the time.

Yeah, I've been kind of working less on the context stuff at the moment and more on the last mile kind of build. So we've got some delivery stuff, um, so deep in the, in the harness and building out design systems and watching Claude behave really, really well for a while and for some unknown reason completely go off the rails and act like a 2-year-old. So, uh, apparently we're getting, I think, uh, Opus 5.1 is coming out this week or very soon, the rumor is, and hopefully that'll fix it because I'm back to Opus 4.8 because, uh, it actually does what's on the box. Yeah, so all right, let's kick off with context then. Well, do you want to see— we— that one we kind of chatted about LinkedIn and all the other ones is this idea of, uh, big and small in terms of, uh, work and focus. So which way do you want to go, big and small first or context?

Let's, let's do the big and small thing because I think it also relates to this whole context discussion. So, uh, Yeah, let's start with that. So shall I basically explain what my sort of thesis is? Yeah, do it. I think these were maybe some of the first articles that I wrote on my Substack last year, and I called them kind of the small problem and the big problem. And this is a pattern, as you are a fan of patterns, right? So I've come to notice something that kind of keeps repeating itself in various areas, you know, be it data architecture, delivery discussions, or, you know, context and knowledge management, and so on and so forth, that we must operate on 2 different levels. And the levels are basically defined by the problem that we are trying to solve. And I think the vast majority of data organisations are focused on solving what I like to call the small problem. Not because it's a small thing in terms of importance or anything, but because the scope of that solution that we are creating for the problem is very small. And the small problem is that individual project, individual initiative, whatever that might be, wants to deliver something valuable as fast and efficiently as possible. So this is the obvious problem that everyone's trying to figure out. all the time, right? But then in any organization larger than, I don't know, 20 people, you will have multiple people, multiple groups of people solving their own small problems kind of in parallel across the organization, right? So then as the scale goes up, we have the big problem, which is again big because of its scope, which is how do we create circumstances in the organization across the whole organization, where all of those teams can consistently and safely and efficiently keep delivering valuable results. And the distinction is very, very kind of minute. It's just about, at the small level, it's the individual solution, the individual team doing its individual thing. And then at the kind of big problem level, we're thinking, all right, Well, now there's 100 teams or, you know, 20 people or whatever. How do we make sure that all of them can consistently keep delivering? And the tasks and the questions, the tasks that we must do, the questions we must ask are actually completely different than these. And I keep running into this problem where I see teams doing local optimization at the kind of small problem area, And then there's no one doing kind of global optimization of the big problem area. And traditionally, we've been talking, of course, about enterprise architecture and whatnot, but I think that there the issue has been that many people haven't really focused on the feedback loops between these things. That we need to be able to, you know, first of all, from the people solving the small problems, we have to be able to take learnings out of there and make them reusable and, you know, update our patterns and templates and components and whatnot. But on the other hand, anything that we do on the kind of big problem level, if it doesn't practically help those individuals and teams working at the small problems, then it's useless. So there kind of has to be a continuous feedback loop going between those 2 levels of people solving different problems. And I'm just not seeing enough people solving the big problems. I'm seeing a lot of vendors, a lot of consultants, lots of advisors, a lot of data leaders just focusing on individual small problems one at a time. So that's the thesis.

Oh, so that, that, yeah, we're not going to get the context in, are we? So, so there's a shit ton in there. Let's, uh, let's unpack that a little bit. So, um, so one of the, one of the ones was on LinkedIn. Um, there was, uh, one of the guys that's in the data mesh, data product community out of Europe. I think he was at Antwerp when we were there. So, he had a question of, if you've got distributed teams, do they even need a modeling pattern? And so, we won't go into the whole, you model whether you think you do or not. The question is not whether you model, it's whether you consciously or unconsciously do it. But it comes back to this idea of, if we have truly distributed and decentralized teams, And they're responsible end to end, then actually we probably don't want any big solutions. We want silos, right? We want them to be completely independent. And what that means, though, is we get no reuse across teams.

Yes.

And we have to be really clear that we're going to be on this completely distributed, because what I see, like you, is we're going to be completely distributed, but they have to use the same platform. Oh, we're going to be completely distributed, but they have to talk to each other. And so Spotify, when they first came out with the Spotify model, uh, it was completely decentralized teams, right? Distributed, do what, uh, whatever you want. And then what they found was over time, humans naturally, uh, align themselves to reuse. So new squad would stand up, new people come in, they had to manage some kind of ticket system, and they go ask every other team, what are you using? In their case, it was Jira. But they naturally would go, oh yeah, that would work, or they wouldn't, right? They'd go, I would go put something completely different in. And then the other thing they found is, over time, teams became product teams for those big solutions. So when 20 squads were using Jira, those squads were like, I don't want to maintain this shit, right? I got other things more important. So they became a squad which maintain that platform, that product, right? But I think what happens first of all is organizations say, yeah, we're gonna be decentralized, distributed, and then wanna behave in the— we still gotta reuse, we still gotta control, we still gotta manage. Second problem is, if we're not completely distributed, the other alternative is big upfront, enterprise architecture.

Yes, yes.

Ontologies, data model, enterprise data models, build a platform, data platform for 2 years as the only piece of value so that it's ready. And we know that in the current world, that time to market, that speed, um, is no longer acceptable for most organizations. So we get stuck in this messy middle, right? And then the question is, what stance do you take for that messy middle? And more and more— so I used to do, when I worked with some teams a while ago, we tried— we— the problem we had was fast versus slow development. So we're trying to say, well, can we have a concierge in the middle? And if we get a request from a stakeholder and it looks like it's a nice small one or a BAU change— this is 10 years ago, which is why I'm using the word BAU— um, it goes through the fast path, right? Uh, and then, uh, if it's a bigger piece of work, it's almost like a product, you know, we've got to do some collections of design, some build, then it goes through the product or the slow path. And then what we found is people cheated, right? They go, oh, well, the slow path, 6 months. So no, this is a small problem. We had to say to a team, oh, you're on the BAU team forever, you know, doing drossy maintenance work, which meant when the people doing the product builds were building, they were handing over shit that never worked because they didn't have to maintain it. So we're like, no, no, you have to maintain it. And then people going, well, I don't want to be on the BAU team for the rest of my life. I want to do cool shit. So then we started moving teams around, squads around, right, you know, you this week and all that. And, and what we were really doing was kind of trying to patch over the problems. And where I've got to, and I've been interested in your view now, is, is I think more about pioneers and town builders. If we want to do something that has a higher area of uncertainty or a need to go really fast, then we just pioneer it. And that's a set of very siloed behaviors. There are minimal principles, right? Minimal policies, just do whatever you need to get it done. And then we want to figure out how we pick up that pioneering capability and move it back into town planning, which means we may rebuild it, right? Or we may port it, or we may go, shit, that was really good, let's make that a product, right? And that's the last point I wanted to pick up because you kind of mentioned it. When we're— if we're building big things, we have to build them for somebody else to use, not ourselves. Yeah, so we're effectively building a product to go, this is going to make other people faster, right? Their small solutions will actually just reuse the big one because it's so easy. Why wouldn't they? Yeah, that's kind of my thought, right? But it's that balance, right? And I struggle with ontologies right now because I go, I mean, I just got hit with it this week, right? Where I was like, yep. I made the mistake again and it's killing me. But it's this idea of big upfront, you know, big platform design, big enterprise architecture, big data modeling. They're all really, really valuable, but in the new world, they take too long. So your thoughts?

Yeah, no, no, no, I agree on the sentiment. Big upfront is not the right solution here. But think of team topologies. You've read the book, right?

Yeah.

So we have, what are they called, stream-aligned teams, which are basically what we are now talking about, the individual teams working on individual small problems, right? And then we have all the other teams, basically platform team now being the kind of key here, that the idea in Team Topologies is that from a technology perspective, the big problem of figuring out that everyone has the capability to be build efficiently and, you know, reuse things and use shared components and whatnot. There's a separate team that takes care of that completely, as you said, in your Spotify examples, and so on and so forth. So eventually, someone will take— start taking care of development tools or whatnot. This is basically organically moving towards kind of platform team versus streamlined teams structure, right? And I think it's not just technology that needs that. I mean, it already, if you do that kind of actual division between kind of product teams and platform teams, that's already a huge improvement for many kind of traditional IT organisations where everyone is basically just doing solutions all the time. But actual platform services are basically products, as you said, to the other teams. But I think this goes wider than just technology architecture and platforms. And now I'm getting to the ontology point. For a few years now, when I've been in various organisations, doing data modelling and setting up kind of data modelling practices and ways of working and roles, you know, teaching people how to do it, I've used basically the same pattern in terms of data models, that there should be a capability or, you know, enough understanding and knowledge that individual teams can model their own things as they see fit, you know, in their own schedule, you know, whatever that might be. But at the same time, there must be someone looking at the overall picture of models in the organization who is able to, if necessary, tell other teams that, okay, you're actually doing something here that we have checked this earlier, that this is not so, you must go in this direction, this is the right direction for you. I.e., kind of taking information from the top, the enterprise level, back down to individual teams. But at the same time, we must build a system which allows a process which allows these individual teams to basically keep expanding the enterprise scope. It's not so that there's separate enterprise modeling that models the whole enterprise and then separate project modeling that models individual projects. It's a feedback loop again in both directions. Projects must increase the amount of knowledge in the enterprise level. Now, I think that with, you know, forget about data models part in particular for a moment, and this whole thing applies also to ontologies and all this knowledge management work. If a project discovers a piece of information, you know, semantics about whatever, how do we make that piece of information available to everyone else? How do we pull it from the project level up to the enterprise level so that the next project can again reuse it? And I think that kind of process is what we really need.

Decision tracing, right? Context plane. So, but human nature, right? So by default, most humans are relatively lazy in a good way.

True.

Yeah. Yeah. So it's like, well, if I don't have to do the work, then I'm not gonna do the work, right? I'll just use something that's fit for purpose. But data people and technologists are builders by default. and tend to not reuse something else if they can build it themselves. Yeah.

Right?

So we kind of got this, this problem of 2 behaviors. And then if we treat the, the big piece of work, right, as a review cycle, it's too late, right? It's like, well, I'm going to go review your work and tell you, you kind of got it wrong. But actually, you're almost near the end. Your stakeholder is not going to give you permission to spend another 2 weeks to refactor it.

Right.

And so that's one of the problems we have to solve. And so my view is with the GenAI toolings now, we start to get technology that can help us solve that socio problem because everybody's using LLMs. Well, not everybody, sorry. Lots of people are using LLMs and GenAI in their work now, and they're using it in an ask AI pattern. I ask a question, I get a response. Can you check this for me? Hey, I'm going to chat to you and just get some feedback. If those tools are actually bound to our context plane, right, to the knowledge and content that we have in our organization, then it's going to help the person doing the work go, oh, you do realize that actually over there it's already been done, right? Why don't you reuse that? Versus Claude going, yeah, I'll write that for you. Um, it's going to hopefully say, well, you're just defining marketing active customer, but actually it's over there, it's been reused. Um, so it's over there, it's been used, it's been validated. Why don't you use that? And then potentially policies that audit it. Okay, you know, hey, you have— Shane got told that marketing active customer was over there, and then he went and created his own one with the same term. But the problem with that is we're building these little pieces and then we're having to fix things. And I got a classic example, right? And this is the one that nailed me last week, and I knew it. And that's the worst part, right? Where you go, I knew it. So doing some work around payments. So I went through, grabbed a glossary, right? Like payment arrangement, payment installment, that kind of thing. And Because of the iterative way we work, it's kind of like get an early cut of it, test it with the stakeholder subject matter experts, looks good, get the data, test it with that, give them something back to actually see, and then, you know, go, you know, that state change where we said we went from there to there is not quite true, right? Like, um, and so one of the ones is, is I use the term broken arrangement.

Right.

And I use the term payment. And then I went, actually, there is no— payment's an overarching term. There is no term payment. There's a payment arrangement, there's a payment arrangement installment, there's a payment attempt, there's a declined payment, there's a whole bunch of payment states. But payment is never a term I should have used. And broken arrangement is never a term I should have used because it's all around a payment arrangement. The problem was I'd already built some stuff.

Yeah.

And I'm like, what do I do? Right? And you go, yeah, I've got a delivery. I've got to get something back, right? We want another iteration. Claude naturally says to me, I will just change it in the front thing they see, right? We'll go broken arrangement becomes broken payment arrangement. And I'm sitting there going, well, no, because I know that if the field in the table is not called broken payment arrangement, at some stage you, an MCP, something, an agent is going to go look at that and it's going to get confused, right? Uh, so I ended up paying that tax, right? I ended up spending time and tokens going and rebuilding it. But the reason is because we're a 2-person company and I know my incentive is I can't have that effort and work turn up in a month's time. Yeah, I can't spend a cycle where it gets it wrong and I don't know why. So I'm incented to go back and do my rework. If we've got separate teams, is the, you know, is the platform team really incented? Is the building team, the pioneering? Yeah. So again, I think that's part of the problem. What's your thoughts?

Yeah, yeah. I was using actually an example because I use Google Workspace for all sorts of running my entire business, basically. And Google Workspace has the Google Contacts thing that, you know, runs your email addresses and everything. And I religiously use that. So I have all my contacts in there. All my, you know, all my phone contacts are synchronized and emails and whatnot. And every time I send a new email, basically it goes directly as a new contact. Google Contacts has this merge and fix functionality that when I open the contacts kind of UI, which actually I rarely need to open, the first thing I face there is a suggestion that, okay, you could merge and fix the following contacts. And it basically goes through my contact list and says, okay, you know, here's the same name with different, 2 different emails, 2 different contacts you have. It's just the, you know, the domain in the email is different, and this guy has a phone number that doesn't are these the same person? Would we just, you know, merge them? I say, yeah, let's merge them. That's the kind of work that happens, I think, at the sort of— or should happen at the enterprise level, basically. That we have— we need to have people who are able to do sort of janitorial management work, consolidating things at enterprise level. But I agree with you that it can't be a process where you need to kind of wait for review. I mean, the review can't be a showstopper for the project. That's impossible. We all know that those EA gates or whatever, they will never work. And also, it can't be the only method of kind of injecting information from the enterprise level into a project. But if this merge and fix operation, that's kind of continuous work that happens at the enterprise level. And as you said, maybe if we are then able to feed that information to you know, LLMs and so on and so forth at the project level, then, you know, when you initiate a new project, you say, oh, I'm going to be working now on, you know, payments agreements, whatever that might be. Then your fancy AI friend helper might come down and say, oh, you know, well, that's cool. Here's the domain model for payments or adjacent items that we've already discovered. You know, here's the documentation that has been created. Here's what we know already. These are the patterns, these are the dos, these are the don'ts. And that could be kind of a pull from the project rather than push from the above.

I think you're right. I think part of it is before we had technology that could help us with this, it was always humans only. It was always too late. Data quality committee or a data stewards committee where I go and do the work, I define the payment arrangement, payment terms, I then write a document, I then get it on to the next meeting. That meeting's busy because it's been full, so I'm 2 meetings out. They look at it, they have a question. Oh, what about this one? You know, then we have to go back and do some more work. And the feedback loop, the time to go from I need to be able to define and use this to this is good enough to go forward. It's too long, right? And so we just kind of go fast, we do point solutions, because we can't wait for the proper process.

Yeah, but let me just challenge the wait and everything, because what I find weird here is that obviously the argument for rejecting the kind of enterprise-level architecture or knowledge management or anything, is that the individual projects can't wait. But isn't the point— the point is not just to drop out every kind of external influence so that the project goes faster. It is to inject beneficial information into the project so that it goes faster. So the feedback loop coming down from the enterprise level into the project, the point of that is not to slow down the project. It is to avoid the project reinventing the wheel, doing the same things again in many different ways, and having to learn the hard way the lessons that someone else has already learned. So I think, you know, when it comes to data governance, ontologies, knowledge management data models, architecture, whatever, I think we just need to turn the whole question around. How can the enterprise-level information that we've gathered help the projects go faster? Not just how do we minimize enterprise-level involvement in individual projects?

And so for me, as soon as we say enterprise, we do exactly what you did, right? We go enterprise up here and people down, you know, projects down here. I see it more as principles, policies, and patterns. Yeah, because they are what an enterprise is made up of, if you kind of take it back to its core patterns. And then Juergen Uppero took Team Topologies and he took Spotify and a bunch of those other sort of by model, and he created a thing called Unfix, which was more detailed, and I really liked it. It's kind of gone now, um, because he, he kind of went to the next level of pattern behavior amongst humans, which resonated with me. So one of the things he'd talk about, and maybe it was in Team Topologies, I can't remember, um, is when you effectively parachute an expert into a squad for a period of time to bring their expertise. That's a really valuable pattern, right? They get access to that knowledge, that expertise, that way of working, those sets of patterns. But that person's going in to make that squad more mature and more, you know, increase their expertise in that thing. And then they go and help somebody else. And so for me, and that's the feedback loop, because they're going to be watching what their team are doing and go, oh, actually, that's really, really useful. I should have thought about that. And then they're going to bring it back into the toolkit effectively. And so that feedback loop, right, where we take policies, patterns, and principles from an organization-wide, and then bring those into those point solutions. I think that's really valuable, but there's got to be a feedback loop and it's got to be fast, right? That process should give us agility. It should allow us to make change at a faster pace with less risk. Yeah. Um, so that's what we should be aiming for. So I'm with you. It just— I hardly ever see it, right? I mean, you see it with a 2-person team because you have no choice. you have a 100-person organisation, then we naturally get silos, and we get silos in the organisation. There's the finance team, the marketing team, you know, we don't break up the teams and reform them every 6 months, which would be a really interesting idea.

Yeah, I mean, I did a little exercise at the client some time ago where we were discussing, you know, kind of data product management approach, right? That what if we were to introduce kind of data product approach? Now, without going too deeply into what the data product is, but the idea was that we would kind of figure out what are sensible collections of things that are related to some specific user group doing a specific thing, you know, a bunch of dashboards or, you know, files or whatever. And then we would basically document that using a very, very simple kind of metadata wrapper, which would be the same metadata for every single data product. And then there would be just one thing to document, and it would be very easy, and we could all list them in a catalog somewhere. List— and by catalog, I mean a catalog of these data products, not a catalog of every single component within them, making everything that much easier because the granularity level is much easier to handle. So there was a lot of pushback from the technical side because they said, oh no, you know, we can't possibly document anything in this organization, or, you know, it's very difficult and it slows us down, we just want to code and everything. And when we discussed with the project managers and the kind of business counterparts and team leads in the technical teams, and they were also kind of very sort of not very excited at first, but then they tried it out. We said, okay, you know, here's the 10 little cells in an Excel file that you fill to document your data product, just try it. And they spent like, you know, 30 minutes on each product and they said, you know, actually, well, It was quite easy. And we went through the motions and tried everything, you know, where do we put them, how do we catalog things. And the end result, we then after some time, we asked for feedback. And these newly minted product teams, they said there's simply no other way which would make things any easier. This is like the only way that makes any sense. This is simply so kind of practical. and such an easy way to make things coherent, make our products visible, to understand other people's data products, why would we do anything else? And that was just a sort of little kind of twist in their minds that they had to go through, that it's not that a shared pattern will slow you down, it's something that might actually speed you up.

And that's the idea, right, is reduce waste. So reduce waste and time, reduce waste and waiting, reduce waste and rework, reduce waste and handoff. I mean, it's effectively bringing lean thinking into knowledge work, right?

It is, it is.

And we often don't do that because we can't see the knowledge work. We can watch a factory floor and we can see the machines, we can see the movement of parts and goods, right? We can see the humans, we can see the stoppage time, we can see the waste because that's what lean processing gives us, right? And knowledge working and data working, often we can't. And again, it's not the people doing the work's fault because they're incented to take another Jira ticket and get it out to the stakeholder, right? They're not incented to look at their way of working, to look at their technology and say, actually, I'm just going to reduce one piece of waste this week because it will pay us back. And they're not incented to experiment, right?

Yeah.

They're not to say, try, try a spreadsheet with 10 fields, see if it improves the process or makes it worse. If it improves it, keep it. If it doesn't, uh, throw it away, right? Try something else. But you know it's a wasteful part of the process, so, uh, go fix it.

Yeah, but, but I, I think I'm— I've worked in corporate IT for many, many years, and, you know, as part of it and consulting in there and, you know, all sorts of things, and I have come to the conclusion that the traditional sort of IT service management mindset is really, really bad for data analytics work in particular, probably for other kinds of work as well, but in particular for data analytics work, because it turns data teams into ticket factories. As you said, you just grab the next ticket, you do the thing, you grab the next ticket, and the only thing that the kind of IT service management mindset seems to be trying to optimize there is the speed of individual tickets kind of going through the system. And that might involve, oh, let's switch from Databricks to Snowflake, or, you know, whatever that might be, where you're just trying to get individual tickets going through faster without paying attention to kind of overall data architecture or anything, because that's not part of IT service management. Your service is the service where You offer these data engineers or whatever to your business units so that they can send in tickets, and you are just promising that we'll have lots of engineers and they will respond very quickly to each ticket. Your service actually is not what it should be. What service that should be is, we will maintain a sensible data architecture for this organisation as a whole, meaning the kind of big problem, and not just trying to optimise the inflow of these small problems. all the time. And I'm not sure, it might not be an inherent problem of ITIL or something like that, but I kind of feel like it is, that the organisations who operate in this way are somehow almost fundamentally incapable of kind of thinking about data work as a bigger picture. It's just, you know, individual tickets.

I think one of the most embarrassing parts of that whole process though is, Nobody can tell you how long it takes.

Yeah, true.

Nobody actually checks the ITIL-based ticketing system to see how long it takes from a request landing to being served. And I don't have a problem if it's a true factory, but bring in lean and that kind of thinking, right? Because that's what you're operating. But we don't, right? We don't, we don't manage cycle times. You know, we don't manage downtimes. We don't, track the handoffs, those kind of things. But it kind of reminds me, there was a post, um, on LinkedIn, and I kind of made a comment, I think, or I reposted anyway, um, and it came back to, uh, the Chief Data and Analytics Officer. Well, let's just say Chief Data Officer, right? Where should they sit in an organization? Should they sit under the CIO? Oh, it was ANZ, right? That's right, New Zealand, uh, and it was, yeah, the head of data sat under the CIO, but they had a group head of data and analytics. And it made me think, right, I don't think the data— I think the data and analytics should be at the top table, right? I think actually it's that part of the strategy of an organization is how's data and AI used to achieve the corporate strategy. I think that's a top table conversation right now. But the second one, the more important well, for now is where should they sit, right? Should the head of data sit under the CIO, the CTO? What do you think?

Yeah, I mean, this is an age-old question, isn't it? And this has been probably a question ever since the first person came up with the title of CDO or head of data or anything. I don't think it should be under CIO, but not necessarily for the reason that that other people often use, that, you know, you want the data analyst to have a seat at the top table or something like that. I don't think that's the reason. I want to kind of go back to what I said about ITSM mentality and so on. I think the culture under CIO is wrong for data analytics work. The culture, the processes, the roles, the ways of working are simply wrong for data analytics work. And that is kind of Big enterprises have sort of standardized how everything works under CIO. It's IT service management and that's it. And data analytics, if it is organically kind of— sorry, organizationally put under CIO, means that data analytics will also operate in IT service management manner by default. And then you have your kind of brave heroes who try to break out of that and change things and so on. They will constantly kind of swim against the current. So I think that culturally it's important to have data analytics outside corporate IT. It's not because of importance of titles or anything like that, a pecking order. It's a question of organizational culture. And I don't say this because I would somehow hate corporate IT. As I said, I've been working there for many, many years now in different roles. But I'm just thinking that this is not the way for data analytics because Our job is to figure out together with the business how can they use data to improve whatever the things are in business that they need to improve. And that is contrary to the kind of ticket-taking mentality where you just expect that someone will throw at me a ticket explaining what they will need to have done, and then I'll just implement, and then business value magically appears on the other end. That's not how anything works, and this is why we can't deliver business value in data.

I mean, the interesting thing is CIO stands for Chief Information Officer, right?

Well, I mean, that's, that's a big irony, right?

Not Chief Technology Officer.

The whole IT is information technology. Honestly, it's just T. There's very little I in there.

Yep, true. I'll go back to why I think they should have a top table seat. And for me, it's because they need to be as close to the conversation around the operation of the organization and the strategy of the organization that they can be. So Chief Financial Officer sits here to understand where the organization is going and saying, what's that going to do to our revenue expenses, right? Like, are we going to be financially viable? What's our risk from that? Chief Operating Officer sits there and says, what do I need to change from a process point of view? Yeah. Head of HR, you know, what does this mean to our resources? No, sorry, our people, right?

Yep.

And I think data and analytics now is something that's important enough to sit there and go, okay, these conversations, what does that mean? How can data and analytics reduce waste or support that strategy, right? How can we make it achieve it? And I think reading a strategy document or having it pass through a bunch of whispers isn't the right way to do it anymore. That's why I believe it's It should be part of it. But yeah, I agree with you. I think there's that culture thing. If you're in a team that works in a certain way or part of an organization that works a certain way, it's incredibly difficult to swim against the tide, as you said. You know, the corporate— I always called it the corporate virus, right? It just comes and attacks you so often that you end up leaving or complaining. So yeah, I think that's a good point.

Let me take this discussion back towards kind of context and knowledge, because this is also relevant to this topic that Now that increasingly, I was just having a discussion with one CIO a few days ago about this, and she was asking about library sciences, that she's heard that library scientists are kind of now involved in these things and had lots of knowledge about that topic actually. And I said, yeah, they're basically now the hot potato of this era.

Yeah.

Data scientist was the sexiest job of what, 2000s or something? Anyways, and I started thinking after that discussion that, oh my God, you know, what is going to happen in many organizations is that now that context and knowledge management are big topics, IT organizations will try to start working on that. And what IT organization does when it starts working on knowledge management or something is it buys a technology.

Mm-hmm.

It sets up a technology, And then it says, here is your technology, now you can do knowledge management. And the management of content has never been IT's kind of work or any kind of even interest to lots of IT. One of my old friends, Sade, who also does Helsinki Data Week with me, Sade said, and I will always remember and use this, that IT and data things are like like you have pipes where you have running water in, that IT is interested in the pipes themselves, but they are not interested in the water. And it's very weird that we're kind of framing this whole data analytics and knowledge management issue as sort of water management issue, as it were, but we are actually only focusing on the pipes. And that's because IT is running things. So context management and knowledge management and so on, I don't think that culturally organizationally or kind of competence-wise, IT units will be able to handle the needs for context and knowledge management that we now need due to AI. It's not part of what they've done, part of, you know, the competence that exists. And trying to kind of shoehorn the sort of knowledge management competence into existing corporate IT organizations is going to be super difficult. We'll see a lot of people burnt out and, you know, switching jobs and failed projects and, you know, whatnot.

Yeah, I just want to bounce back to, you know, I'm old enough now that I remember when mainframes were around and PCs turned up. And the dream back then was technology enabled the organization to work in a better way. It wasn't about just owning the plumbing and the infrastructure, right? It was about, hey, we've got the strategy and how does a PC effective, right? Does it make it better? That's where it kind of started. But yeah, I agree now that generalizing it, technology has now been relegated to plumbing and maintaining hardware, cloud hardware. Um, I have worked with CTOs and CIOs that don't behave that way, that are enablers, you know, that sit there and go, you know, what is the strategy? What is it? Yeah, where are we going, right? How can we help do that? But 9 times out of 10, I'll see that type of role be in a— when I used to work in enterprise organizations, digital transformation. And the problem was they treated it as a program, right? A start and an end, not a way of working. And IT got relegated to being, hey, we're going to tell you what hardware or technology we need you to implement late with no notice and expect you to do it really, really quickly. So I think that's where we kind of got to, and I don't think it's right. And I think you're right, it's going to happen with context. I think the other thing is, when we talk about context technology, we're at the beginning of the Hadoop era.

Yes, totally.

We're experimenting, right? Nobody has an answer. There is no proven patterns, I don't think. Everybody's learning really fast, and therefore, if you're going to go buy technology first, you're probably going to buy something that won't survive. Or something that's wrong. Um, and we all know that, you know, standing joke is you buy SAP to implement best practice—

best practice—

and then you tailor it so it becomes the most expensive unusable product in the world that can't be maintained. That's not SAP's fault, right? Their technology says this is best practice, put it in like this and you'll be as good as everybody else like you. It's the organization that decides to break that rule. and do something different. And so, yeah, I, I don't know, um, like, we just— everything's moving so fast right now. You go buy a context technology, uh, I think you'll be lucky if it survives in its form that you buy it, uh, in a year's time.

Yeah, well, the thing— yeah, I think the comparison to Hadoop era is really, really good because, you know, what is left of those, uh, Hadoop-based enterprise data lakes and so on and so forth? Basically nothing.

Yeah, but we got Snowflake and Databricks, right?

Well, yeah, I mean, yeah, that's kind of where I was getting to.

Yeah, the next generation came along and did it.

Yeah, yeah, yeah, yeah. We got the comment on the chat, no real reuse at any level. I mean, yes.

So I'm guessing that's John O'Gorman maybe, and I see Christopher Chen as well. Feel free to give us a question, Christopher. So no real reuse at any level. I think that's a choice. Like I said, I think you go, we are primarily focused on no reuse and we're going to optimize for a no reuse way of working, or we're primarily focused on reuse and then we're going to, you know, we're going to see how we can get agility and speed without having to do big design upfront.

Yeah.

And big design, I mean, 6 months, year, 2 years kind of design. Yeah.

Although I want to point out something that I've often ranted against as well, which is the endless enablement projects. That, you know, if no one is building actually anything valuable and everyone's just building tools for each other to enable them to deliver value, then that's completely pointless. And I think that's one of the big sort of basic instincts of us sort of more holistically minded data people, that we want to create frameworks and tools and methods that are basically enabling someone to do something. But, you know, where's the actual value? It's quite often lost.

You know, there are people out there— putting my hand up— where I have probably spent far too long over the last couple of months working on my harnesses, where, you know, I could question, am I really getting a reuse return on value, uh, for some of those things? So I definitely am, right? So there is— I'm seeing the benefit of reuse now, but rabbit holes I go down, where I go with that. And, and again, one of the interesting things for me is incentive, right? Because I'm on a Claude subscription, because I don't pay per tokens at the moment, uh, when I get to the near the end of my subscription week, I will go down a rabbit hole of what would— what about, right? Because I kind of feel like I have to use it or lose it. I kind of feel like it's free. But the interesting thing is that experimentation time is often where something happens and I go, well, that's interesting. And then I, I don't do anything about it, but then I think about it and, and a week or two later I'll reuse it. So again, this is the other part, is this idea of experimentation. Often experimentation is treated like the toy shop. You know, you got the digital or the experimental, the innovation team. Yeah, that's my favorite one. You know, they're the ones over, back in the days we had buildings, you know, they were on the floor that had the cool green carpet and the park bench. Seriously, you know, and one organization, one government agency had a tree inside the wall in the room, right? Because they were the innovation thing. They didn't last too long because they delivered jack shit. So I'm not talking about that, but I'm talking about giving people time to experiment, learn, and play with things. You know, the— what is it, the Amazon 20% or whatever they talk about?

Yep, yep.

So incentive to pay the tax that you know you're applying because you're going too fast. I still think there's massive value in reuse, to answer John's view. I think reuse is highly important, and that's just part of my persona. But I try and figure out how we can go faster, more point solutions that then become reusable, um, rather than big upfront. Um, and don't get me wrong, you know, when I was in, in the Agile community, um, everybody used to rant about Waterfall. And, you know, one of the things I, I, I, I believed was Waterfall works.

Yeah.

It has a way of working. If you follow that way of working, it's successful. It's not my way of working, but that's okay. I just wouldn't work on a waterfall project. But you can make it— it's like anything, you can make it work. You know, it's like Data Vault, dimensional, activity schema, you can make them work. Like, just pick one, do it. Or, you know, completely distributed, don't. Just whatever that looks like, because I don't know. So yeah. I think it's a conscious decision, and then you should make sure everything else lines up with that conscious decision.

Yeah, yeah, altogether, yeah, again, kind of contradicting my earlier comment on— I like contradicting myself— but on kind of enablement and useless enablement projects and so on and so forth. But honestly, I also agree, and I think that reuse is actually like super, super important keyword because Reusing things reduces waste. We want to reduce waste. I'm sort of lean purist in the sense that I think in everything we do, we should aim to constantly reduce waste, figure out what's the bottleneck, fix the bottleneck, and then just do the next thing. Never fix anything which isn't the bottleneck, and so on and so forth. Okay. But what I like in product thinking and this approach to products, and this is why I keep yelling about data products all the time, But I also think that, like Anna Bercovin has been writing a lot about, kind of data platforms and capabilities of the platform as a product, I also think that it applies there very, very much indeed. That if we just managed to think about not just the valuable things that we produce for end users as products, you know, apply actual product thinking there, but also apply actual product thinking in the harnesses and capabilities and components of the templates and whatnot that we produce to enable others to produce valuable things, then I think that's also a product management discussion. You know, there's demand for certain kinds of products, we have to do some experimentation to find what product actually fits. There's kind of a go-to-market strategy with an internal tool that you build for your own developers. And all of that is product management work. We just don't think of it that way often.

Yeah, I think, you know, we should treat our tooling as if it's a product.

Yeah.

But the problem is, as soon as you go back to team topologies, right, as soon as you have a team that are focused on that platform or that tooling as their product that serves internally, we now have a massive sequencing problem. Because the people doing the rest of the work that need that tooling or that product, right, that reuse, have to actually telegraph that they're going to need it, and they probably don't know yet. They have to tell them when they need it by, and it actually has to meet that timeframe, often doesn't happen. They have to be available for feedback loops, right? Because you don't want to give them the spec and then just wait for it to turn up and not be what you want, right? That's what we do to our stakeholders, right? Don't do it to ourselves. And that sequencing becomes really, really a thing.

But how is that different from what kind of the end-user-facing data teams do with their business counterparts? It's the exact same thing, right? The business could have deadlines for, you know, whatever. And the business could have requests coming in that they're quite not sure what they should actually need, and they don't necessarily even know what they need. And all that discussion is product management in the kind of end-user-facing interface.

Yeah.

But it also should be the exact same discussion, the exact same feedback loops, the exact same connections between the kind of internal capability-building platform team and their consumers, which are then other development teams. I think it's the exact same process in both interfaces, user-facing and kind of developer-facing.

I think it's the same principles, right? And potentially the same patterns, although I think we do need to change the patterns slightly if we've got a platform or tooling versus data versus things that— there's some things we can tweak that make it a little bit less wasteful or more useful for us. But that comes back to the should, right? Like, you know, CIO should be looking after information for the organization and how it enables the strategy. But a lot of the times they become technology plumbing maintainers. We should be able to apply product patterns to the way we do this, but often we get stuck in a stupid 90-day loop, right? Tell me what you want for the next 90 days and we'll go away and build it, and then nothing sequences. So yeah, it's the implementation, the execution of the patterns that we get wrong, not the patterns themselves. But yeah, no, I agree with you. I come back to, I still, and it's because I'm kind of working on and thinking about it at the moment again, which always kind of changes, you know, not changes, kind of colors the way I think about things. And so right now, this idea of pioneers and Towns. I, you know, still product thinking, right? And I'm like, yeah, it kind of makes sense to me. I can see how we can focus on some of those areas of waste and see whether we can apply patterns to solve it or not. So that's why coming back to it on this, on this one. Yeah, the interesting thing is Anna is part of one of the Aura foursome, right? And she's in this really interesting situation where she's gone into a children's hospital effectively, or organization, because they've got multiple hospital buildings depending on your ontological definition of what hospital is. Um, actually, I'll ask her that one when we do the next thing. Um, and they've just replaced their, their, um, core system, right, their electronic health record system. Which again, funny thing is she keeps saying EHR, but with her accent and my accent, I keep hearing HR. And I'm like, why are we talking about HR and you're in a—

in a—

yeah, anyway. Um, And so she's getting to kind of build things from scratch, right? And so we talked about ontologies, and I said, well, wouldn't you know, if I think about ontologies, if I look at health and bioscience, like, it seems to be the place that's had the most work done and had the most standards in the out-of-box. And that was a really interesting conversation. And the other thing she's thinking about is waste. So what she's saying is when they were going through all the workshops to define how the electronic health record system was working, they were capturing a hell of a lot of subject matter expertise. And then the data team had to go and try and recapture it after the fact. And I'm like, oh, Juha and I talked about this when we were talking about the book, and we're like, why don't we just store the transcripts? And she said, Yeah, but the problem is with the tooling they're using, the transcripts only get held for a certain period of time and then they get wiped by the platform vendor. And one of the things she'd mentioned was in those subject matter expert workshops, it was really expensive because you've got specialist medical practitioners in those workshops, right? You've got the, the really, really expensive neurosurgeons. And so the meeting to capture that knowledge is really expensive. And they're really busy people, so they're never coming back in to relitigate definition of a term or how things work. But yet the cost of storing that knowledge, which is incredibly expensive to capture from a technology point of view, was seen as too high. And I'm like, yeah, if we talk about oil, that's the oil, right? Not the data, that's the oil.

Yeah, I mean, exactly. And this is at the very, very core of the kind of feedback loops that I was talking about in the beginning. that, as you said, you know, you have your extremely expensive doctors or whatnot coming down to talk about some individual project perhaps, you know, and they, in that discussion, they bring up all sorts of information that never before has existed kind of in a digital or even on paper or anything form. And we are just using that information to produce that single artifact at the end as delivery of that single project. We're not making that information reusable. That is the feedback loop from the kind of small problem, the individual workflows, up to some sort of enterprise knowledge repository graph of everything, which should actually capture those things. But this is kind of super— I understand it's technologically difficult, but I think this is where we have a lot to kind of improve on, because, you know, we are wasting so much information. We're not taking advantage of the information we get in those situations because we consider it to be kind of siloed in this little solution-specific delivery pipeline, and then we just forget it and start figuring out the next solution delivery.

And we don't treat it as reusable. So one of the things I used to do was, you know, I'd talk to a stakeholder, go through the Information Product Canvas, and I'd summarize the transcript from that conversation because I found it useful. But then I kind of forget about the transcript itself, right? And then now what I've got is a summary of what it thought or I thought happened. What I found is if I now go back to the transcript every time I want to clarify something, I focus on different things. And again, I was running a workshop with a stakeholder, this payment one, and the purpose of the workshop was for something else, and we got onto the subject of payments. And they just started talking, right? And my natural reaction is, no, no, hold on, that's a, that's a different subject, right? We'll come back to that. And I'm like, shit, no, right? Like, just let them talk. I don't actually have to ask them any questions because we don't have time for me to deep dive and understand. But because we've got agreement that I can use the transcripts, that's now going in there, right? Now I can go back and look at it and I can go, ah, so payment arrangement, right? Or broken payment arrangement, not broken arrangement. That's going to be really important. And so That, that's the goal, right? And, and to capture that, spend the time capturing it quickly, store it, uh, is really, really important. And the other thing I found, and I kind of wrote about that in the, in the last article I did, is when I'm working with the GenAI toolings, I'm finding— I was finding that, uh, stakeholder or the person I'm talking to was speaking German effectively, their language. I was converting it into English to my patterns, what I understood, and then I was trying to convert it from that into something I could give Claude or Gemini, which is French, right? And that translation meant it was nowhere near as effective as me just giving their German to that LLM and it translating it into French. And as I wrote in the article, I'm still in the loop, right? It's not fully autonomous, right? I'm a human in the loop, but it's assisting me, right? And I'm getting out of the way for the thing that I'm bad at and letting it use it, and then I'm doing the things I'm good at. So yeah, I'm like, The technology, you know, if I'm in IT, the technologists are almost a data lake, right? And I hate to say that, but actually these knowledge, there's this transcripts, this text actually is the stuff that we should be capturing and storing because we're going to need it, but we still don't know how to use it effectively yet.

Yep, fully agreed, fully agreed. The world of knowledge is so much wider than just the data that we we actually have. It's just insane. Now that I've got my eyes have opened to this thing, it's just insane how much information is out there that is not actually anyway related to whatever tables we have or, you know, Parquet files somewhere.

Well, it's back to the big 3 Vs of big data, isn't it? You know, what was that? Velocity, volume, and veracity? No, variety. Was that it?

Variety, maybe. Yeah.

Yeah, yeah. God, you know, but back to the idea of that audio and video, valuable bits of data or information.

Yeah, I still think that, okay, you know, storing the raw kind of data, raw recordings and so on, yep, there's value in there. But I still do think that there is a way to distill from that kind of facts that are universal to the organization, which is basically what our book with the conceptual models and the Modeling Business Concepts does, right? We are distilling from the story some sort of easily usable parts. And I think that sort of a process is where it's going to be at.

But again, it comes back to, and I suppose it comes back to Jon's point, right, Jon's question. If we think about the process we're writing about, you know, mapping business concepts or modelling business concepts, the concept map is a way of articulating complexity with simplicity through a diagram so people can understand and reuse.

Yep.

Or decide to reuse or not. Um, does an LLM need the map? I don't know. That's a really good question. It probably gives it hints on what we've agreed. If it can't see those agreements, stops it scanning a whole lot of stuff because we've given it the agreement, the answer.

From a token economics point of view, yeah, seems sensible.

Yeah. Um, but yeah, it's, it's that map really is, is, uh, shared language via a diagram, that means somebody can understand it quickly and decide to reuse it because that makes sense. You know, if we had completely distributed teams, going back to that model, would we, would we even do it? Like, I don't know, like, if we're truly distributed, then having that shared map and that reuse of that map would be waste, right? Because we'd slow that team down. But I don't believe any organization is truly decentralized.

Exactly, exactly, exactly. Because why would they be part of the same organization if they have nothing to do with each other?

Good point. Yeah, there's no shared objective, no shared strategy. Yeah, yeah. So yeah, interesting times though, right? Oh yeah, yeah, yeah, yeah. Excellent. All right, well, that was another good hour. It's amazing how fast time flies. Thank you everybody that came on and anybody that's gonna listen to it afterwards. Again, uh, we're still looking to be driven by the community, right, by our audience. So, uh, and I keep forgetting to, to, uh, to do that at the end. So, uh, yep, hop on Substack, ask us questions on any of the ones we've done before or any ones we're going to do, and, um, we will go from there.

Yep. Oh, thank you.

My screen just timed itself out, so that's right. There you go. Excellent. All right, well, We'll see you again in a month.

See you. Thanks.