CONQUER Part 3: Flames from Agile Burning in the Back Office Light the Way

This is the third 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 3: Flames from Agile Burning in the Back Office Light the Way

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