Big Data Taxonomy Visualisation

[Reading Time: 15mn]

What is it?

In the last couple of blog posts, I have explained my thoughts on software architecture documentation in general, with a focus on data-driven architecture documentation.

Data management has become a complex topic over the last decade, mostly caused by the explosion of data sources, itself a consequence of the explosion of internet-connected services and devices. A term has been coined to depict this situation: Big Data.

Oftentimes, our clients want to understand 2 things about Big Data:

  • What it means, in order to understand whether they need to feel concerned.
  • What the landscape is, or the cartography, or even better: the taxonomy.

Continue reading “Big Data Taxonomy Visualisation”

Architecture & Software Documentation, Part II – The Database

[Reading Time: 15mn]


I have introduced the topic of documenting software artefacts in my previous blog post. As I said, the purpose of a good documentation is to communicate – to your technical peers, to your boss, to your sponsors.

But a good documentation set is hard to achieve and then, to maintain. It should live as close to the actual code as possible. A good deal can be obtained through reverse engineering to / from UML when your project is object-oriented. But let’s face it, we live in a polyglot programming world. At least some layers in our software design won’t be amenable to UML because they don’t use object-orientation design. The canonical example being: how would you go about documenting your SQL-based data model?

Continue reading “Architecture & Software Documentation, Part II – The Database”

Architecture and Software Documentation

[Reading Time: 15mn]


In software development projects, documentation is often considered as an after-thought – if not completely ignored. As professionals, we all know that documenting is part of the design and development activity, much like pushing artifacts to production is part of the development process. Of course, I am not talking about the project’s own documentation like specifications / requirements or sponsors meeting minutes or project planning. They are obviously necessary, but not what I want to review here. No, here I am talking about documenting the design and the code. And remember, we have all been told that it is not only good practice, but also contributes to the overall quality of the project. Not convinced? Okay, let me tell you a story we all know already.

Continue reading “Architecture and Software Documentation”