FlowArchBook

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