FlowArchBook

 Event-driven approaches to integration (such as what I describe in Flow Architectures: The Future of Streaming and Event-Driven Integration ) promise to change the way we solve a lot of problems in enterprise applications. Certainly the move to real time integration will change the speed at which we engage customers. However, an engineer named Scott Havens gave an interesting presentation at DevOps Enterprise a few years ago that opened my eyes to another interesting effect. One of the biggest challenges in distributed systems is managing the effects of dependencies on the functionality of the system as a whole. Take, for example, a web application that must return a value calculated from data provided by several external sources. Havens used the example of a retail inventory availability service. In a traditional service-oriented model, this task would be handled through a number of cascading service calls, starting with the service tasked with returning the final value, followed by

Fairly often a reader of  Flow Architectures: The Future of Streaming and Event-Driven Integration  will share something that indicates possible accelerated development of the World Wide Flow. One case in point is a tweet from John Tipper regarding a proposal from financial services consultancy, Atomic Wire, to rethink the way we settle cross-border payments across the world: I received my Flow Architectures book by @jamesurquhart (it’s great, btw). One of the directions of travel he identifies via Wardley Mapping is need for interoperability. Use of ISO20022 conceptual layer here is pretty novel. @clemensv , you may find some interesting ideas here? https://t.co/pbVC17QT4A — John Tipper (@john_tipper) March 23, 2021 The quoted tweet links to a page where you can download a report Atomic Wire prepared for a hackathon put on by the Bank for International Settlements (BIS) and financial messaging services powerhouse, SWIFT . In the report, Atomic Wire (which I will abbreviate to AW)

The new API destinations feature of AWS EventBridge introduces a simple mechanism for defining how events processed by EventBridge should be packaged and sent to third party web APIs using standard HTTP verbs, such as GET, POST, and others. (Most commercial APIs are REST APIs, which use these verbs.) By defining some basic connection, authentication, and data formatting information using straight forward wizards and templating mechanisms, EventBridge can automatically create the right HTTP calls every time it processes a relevant event. I highly recommend reading this blog post from AWS's James Beswick to get a better understanding of how this all works. Why is this important news? Because AWS has just made nearly the entire API economy a valid set of consumers for your event streams without requiring you to write any code. Do you want Twiilio to consume a customer's exceptions stream so that it can text them the information in a timely manner? Just create an API destinatio

Think about the ways in which the software development process resembles the flow of water running downhill. Ideas are the tiny drops of potential value that gather into features and architectures which then feed backlogs. From there, developers create code and configuration—thus adding value—which  then merges with other flows. Work done in the combined flow gains more and more value until it is presented to those that convert all that value into desired outcomes: profit, or perhaps mission success. OK, it's a bit of a corny analogy, but it represents my mental model of the challenges that developers face while creating any significant enterprise or commercial software system. First, the challenge is to convert potential energy (a worthy idea or demonstrated need) into kinetic energy (the increasing value of the solution to the end user) via a metaphorical force of gravity (the desire for the aforementioned profit or mission success). The other thing I picture is that water runnin

I suppose any blog that claims to target the subject of flow should first define what it means by "flow". There is no argument that the word "flow" is heavily overloaded in the world of technology and related practices and disciplines. It is even more overloaded when you lump in fields such as architecture, healthcare, and—not surprisingly—plumbing. So, when talking about event-driven architectures, and especially event-driven integration, what do I mean by "flow"? First, I provided a very high level overview in a thread on Twitter a few months ago: What is flow, and why is it the future of event-driven integration? I thought I'd just give a brief overview of my book which ships in mid-December. Pre-orders can be made on Amazon at https://t.co/ugMUdlQJ03 /1 — James Urquhart (@jamesurquhart) November 12, 2020 Click on the tweet to see the whole thread. In a blog we can explore the definition in a bit more detail. Defining Flow My book, Flow Architectu

Welcome. This is the beginning of my new blog about the future of event-driven integration, and the advances happening today to make that happen. The concept is described in detail in my book, Flow Architectures: The Future of Streaming and Event-Driven Integration , published with O'Reilly Media. If you have come here having read the book, thank you and I hope you find the blog equally informative. If you have yet to read the book, I encourage you to pick up a copy. Who am I? My name is James Urquhart, and I have had a 30 year career focused on distributed systems in the enterprise. I've had product and engineering leadership positions at Sun Microsystems, Cassatt, Cisco, Enstratius, Dell, SOASTA, AWS, and Pivotal. I am currently a Principle Technologist for VMware Tanzu, working with customer leaders to understand strategies that leverage the power of the Tanzu platform. I am primarily focused on developer experience today. I've also had a fairly successful stint as a blo