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
CONQUER Part 2: The Will that Powers
This is the second part of a series describing the Command, Notify, Query (CONQUER) distributed systems architecture: distributed systems are information tools enabling volitional entities in relationships of permission and obligation to achieve their ends via purposeful dialogs, communicated among software components proxying their wills, consisting of imperative, declarative, and interrogative sentences: commands, notifications, and … Continue reading CONQUER Part 2: The Will that Powers
The CONQUER Architecture for Distributed Systems, Part 1 of Probably Too Many but Hopefully Just Enough
Some time between 2010 and 2013 I began thinking differently about integration, both among components of distributed applications and among distributed applications per se. I know the rough time span because I published an integration reference architecture here in 2010 that did not feature the new ideas, and one in 2013 that did - well, … Continue reading The CONQUER Architecture for Distributed Systems, Part 1 of Probably Too Many but Hopefully Just Enough
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?
The Event Re-Renaissance Continued: Knowledge vs. Data
In my last post, we started digging into the re-emergence of complex event processing and event-driven architectures which has been enabled by the latest generation of stateful stream processors such as Spark Streaming, Samza, Kafka Streams, Apache Flink, and Google DataFlow. Today let's start to develop a clear line of sight into the underlying conceptual … Continue reading The Event Re-Renaissance Continued: Knowledge vs. Data
The Event Renaissance is Reborn Event
We are plumbing our event-driven architecture here at Cambia, and, as we were socializing our approach internally, a question came up about how the stateful-streaming-based complex event processor we're rolling out will fit into the overall flow of data. As I struggled to answer it clearly, I realized that the layers of event-related technology that … Continue reading The Event Renaissance is Reborn Event
A Business-Level Introduction to APIs and Microservices
Health care is largely an information business. Physical treatment – medicine, surgery, therapy, the tools used to deliver it - is the tip of the spear. But it is surrounded by, informed by, enabled by, the flow of information. These days we manage all that information with software: Software is complex: it is expensive to … Continue reading A Business-Level Introduction to APIs and Microservices
A Brief History of Healthcare Interoperabilty (with some thoughts on the future)
The word 'interoperability' as used the current national healthcare dialog has a nuanced meaning. Interoperability is generally defined as the ability of computer systems to readily exchange information. In health care today, however, Interoperability (capitalized hereafter when I am trying to distinguish it from the general sense of the word) more closely means something like … Continue reading A Brief History of Healthcare Interoperabilty (with some thoughts on the future)
Trusted Applications: an Interoperability Parable
Imagine you have to go to the Florida Blues Deerwood campus to pick up a copy of your significant other Sam's claims history. (I am picking on Florida Blues because Deerwood is a compound, you pretty much have to drive there, and there is an only-friendly-to-cars guard gate. What follows is fiction, not what actually … Continue reading Trusted Applications: an Interoperability Parable
Health IT Architect 