Rambling thoughts about life in and around the data industry
Tuesday, 9 May 2023
Full-time fun - why join an early stage startup
9 days into May, and I feel like I have a bit of an "announcement" to share that has been a few months in the making.
End of last year, I came to the end of a long (10,5 years!) and rewarding journey at Neo4j. I had put my heart and soul into that project, and was at the same time sad and thankful for the goodbyes that I had to say. Lars Nordwall and Emil Eifrem will forever be in my heart, as will be so many other wonderful graphistas that I got to know and love.
At the end of a journey like that, you would think that you want want to take it easy, or take your time, or do nothing for a while. And in some ways I did. But in other ways, I just did not want too much idle time. Having some time to reflect would be good. Having too much time to reflect would have someone like me go pretty crazy, pretty fast.
So when Pascal Desmarets and I had a wonderful lunch sometime in January, I decided pretty quickly that I was not going to let the opportunity pass, and that I would want to do some part time work for Hackolade. It seemed like a great idea - and now, 3+ months later, I feel like it really was. Earlier this month, on May 1st, I joined the Hackolade team as full time member - and I could not be more stoked about that. Let me tell you why I feel that way.
Thursday, 4 May 2023
Size does matter, also in Data Modeling!
In the article, Pascal maps the core principles of one of the great, proven agile software development methodologies (Domain Driven Design) onto the practice of data modeling:
No surprise: these principles are at the core of the Hackolade toolset that we have now spent years developing.
As you will see, Domain Driven Data Modeling has some inherent comments that pertain to the SIZE of a data model. This is one of the core points that Pascal tackles in the early part of his article, and a really interesting one to me.
Tuesday, 11 April 2023
In NOSQL, data modeling doesn't have to be logical!
At Hackolade, I have been really enjoying my journey into the world of data modeling. It really has been a journey: in some ways, I have felt like I had to go back in time a little bit, and re-learn some of the skills that I had known in the old days when relational databases still dominated this blue planet. ER diagrams, documentation requirements, naming conventions... all good things that had seemed completely normal in the old days - and that got a little bit of a bad rep when the hipster NOSQL databases and data formats started to gain popularity. I mean: at Neo4j, we used to say that "your data is your model", and downplay the need for deep modeling thoughts ahead of time. And at the same time, we also realised that every time a project wasn't going great, it was the freakin' data model that was the culprit. Every time.
Monday, 27 February 2023
The 3 concerns in data modeling, and their value
In a previous article, I have already alluded to the fact that I think that the confusion around the three words (model, schema, and metadata) is really important to clarify and get straight for our industry. That confusion has a historical reason: in the past 4 decades, when Relational DBMS’ ruled the earth, there was no real need to be specific around these three different concepts: the model and the schema were basically intertwined. But that has changed with NOSQL, and today we do really have to be more specific because we have more variability – we can have more or less modeling, and more or less schema, as we choose. Tools like Hackolade and its polyglot data modeling have already made that very clear as well.
The main reason why I think being specific around this is important, is because it also allows us to be specific about the underlying concerns that speak to these words.
Friday, 17 February 2023
Data Modeling and the eternal struggle between business & IT
Part of the confusion in the terminology stems from the fact, I believe, that in traditional relational database management systems, your physical model and your schema were tied at the hip. It would be extremely weird to have one without the other. In fact, in relational data modeling, your schema would literally be the output of your physical modeling and would therefore be a different representation of the same thing. The physical model would be human readable, and the schema would be machine readable. That all changed with NOSQL database management systems (document databases like MongoDB or graph databases like Neo4j), where you could have “the data be the model”, and where the enforcement of the model would be completely optional and usually not even considered before one would take the system into production.
Monday, 13 February 2023
Confusing words in Data Modeling
Tuesday, 24 January 2023
The Agility Angst
What does my age have to do with anything? Well - it basically means that I grew up with a very, very different type of software development practice. OO was still young. The mythical man-month was still a thing. And methodologies all depended on strict, rigid waterfall development models.
Nothing wrong with the odd waterfall, of course, but with the emergence of more and more, and better and better, software tools, libraries and frameworks - this whole idea of the time consuming waterfall process has kind of become irrelevant. Who would still go through this entire process and ask their users to wait for months before they would be able to give any feedback? What users would accept that type of arrogance on behalf of their IT department? Seriously?