Your Knowledge Strategy: And Magic Filled the Air

In my last post, 'You Don't Need a Data Strategy, You Need A Knowledge Strategy,' I painted a high level sketch of why we need knowledge strategies, and the key features they need to address. I skipped ahead pretty quickly, rambling on<the time is now to sing my song /Zep> to cover a breadth of … Continue reading Your Knowledge Strategy: And Magic Filled the Air

You Don’t Need a Data Strategy, You Need a Knowledge Strategy

In my post "Throw Off Those 1960's Data Strategy Shackles" I suggested that the days of the Inmon/Kimball model strategy for analytics are past, sketched out a couple of notes on making events the atoms in our data strategies, and promised a longer answer to what our future states should look like. Continuing on that … Continue reading You Don’t Need a Data Strategy, You Need a Knowledge Strategy

At Any Event, or at Every Event?

Still on the trail of conceptual clarity around events. In the last post in this - this is the third, so let's say 'series' - we discussed the difference in knowledge and data. I used the familiar-to-most query against a relational database to illustrate the difference. Let's return to that example for a moment. The … Continue reading At Any Event, or at Every Event?

Throw Off Those 1960’s Data Strategy Shackles

(This is the first in a series of posts on data strategy. Next post here.) I’ve been reviewing and providing feedback on a number of data strategies lately, each presented as a future state ‘conceptual’ architecture which is mixed-level-of-abstraction Dagwood technology sandwich with an implied left-to-right flow.  You know the kind of diagram I mean: … Continue reading Throw Off Those 1960’s Data Strategy Shackles