Business Event Driven Architecture & Governance in Action
•
0 likes•146 views
"Event-Driven Architecture is the only way to achieve resilient scalable reactive systems. It enables loose coupling, drives autonomy for the dev teams, and is the key to digital business behaviour monitoring. But how do you implement EDA the right way? And make sure that it keeps being implemented the right way? At Current 2022 there was a talk from Confluent explaining the value of a COE (Center of Excellence). However, in this talk, We’ll be sharing several experiences in setting up a COE for large industrial companies, insurance and logistic environments. From setting up a strong foundation, defining event designs, best practices, and principles to the guidance of development teams. The COE brings business and IT together to ensure EDA is set-up and used correctly, but also to identify and capitalize on new opportunities that automatically arise from using EDA. Using several real life experiences (AXA Belgium, Engie, Nike, ...)"
Recommended
Recommended
More Related Content
Similar to Business Event Driven Architecture & Governance in Action
Similar to Business Event Driven Architecture & Governance in Action (20)
More from HostedbyConfluent
More from HostedbyConfluent (20)
Recently uploaded
Recently uploaded (20)
Business Event Driven Architecture & Governance in Action
- 1. Wim Debreuck EDA Architect Event Driven Architecture & Governance in action!
- 2. EDA Journey Positioning Business Event Driven How? (governance)
- 3. Monolithic Impossible to scale Small change? Full redeploy No separation of concerns
- 4. Monolithic Impossible to scale Small change? Full redeploy No separation of concerns Possible but still difficult to scale Heavy interdependency High-complexity due to number of interfaces SOA P2P
- 5. Monolithic Impossible to scale Small change? Full redeploy No separation of concerns Possible but still difficult to scale Heavy interdependency High-complexity due to number of interfaces SOA P2P Central logic Still not fully scalable Volatile communication ‘Integration team’ SPF SOA ESB
- 6. Monolithic Impossible to scale Small change? Full redeploy No separation of concerns Possible but still difficult to scale Heavy interdependency High-complexity due to number of interfaces SOA P2P Central logic Still not fully scalable Volatile communication ‘Integration team’ SPF SOA ESB No central logic No central integration team Persistent communication Scalable by nature Loosly coupled (micro)-Service Event-Driven-Arch
- 9. An Event is (not) a message A Business Event is (not) an Event
- 13. EDA How ?
- 14. What’s the root of all Architectural Evil? COUPLING
- 16. Defeating Coupling REST API’s HAPROXY ESB like stuff Async API Mulesoft Service Mesh Frameworks WSO2 And many, many others…
- 17. EDA is the next big battle against ’(tight) coupling’ WHY?
- 18. • Log of events • Each event has a key and a value • Constant-time reads and writes • Persistent on disk bb bb b bb Key: 1234 Payload:… Producer K/V
- 19. …. bb b bb bb bb bb …. bb b bb bb bb bb …. bb b bb bb bb bb Key: 1234 Payload:… Key: 1234 Payload:… Key: 1234 Payload:… Key: 9001 Payload:… Key: 9001 Payload:… Key: 4035 Payload:… Key: 2006 Payload:… Key: 7645 Payload:… Key: 7645 Payload:… Key: 4035 Payload:… Key: 4035 Payload:… Key: 3344 Payload:… Key: 3344 Payload:… Key: 2006 Payload:… Key: 3344 Payload:… Claim 1234 Registered Claim 1234 Non Fraudulent Claim 1234 Accepted
- 22. Now you can imagine: • You can use it a the single source of truth (HA) • The speed of build/delivery without: - Central integration authority (post-esb-era) - API contract negotations, the event ‘is’ the api • The potential of (realtime) Business Event Behavior… • We raised the decoupling-bar!
- 24. EDA How ? Align & evangelize with EDA Manifest Define Operating model Elevate & Repeat
- 25. Align & evangelize with EDA Manifest Topic naming conventions Order guarantee with Key Use Schema’s (on write) Define Retention Policy … Manifest Allignment sessions
- 26. Topic Naming Convention: Topic is the logical group level of Events on Kafka Mindset prerequisite A: How to define/recognize a Business Event?
- 27. A Business Event… • Broadcasts data about an action happened in de past M a c h i n e P r o d u c e d • Broadcasts that something happened to something/someone ServiceEngineer H ired • Has a verb in the past tense and a ‘subject’ (the main ‘something/someone’ the action has impacted) Machine Com issioned Warranty Expired • The subject has (in general) an immutable character (at the core) • Can be assigned to a process-step in a process diagram quite easy (it has a business meaningful meaning) ServiceTask Finished • Is expressed in a human understandable, unambiguous language • Is produced by the owner of the subject (within its domain) ServiceContract Sold
- 28. Topic Naming Convention: Topic is the logical grouping of Business Events Mindset prerequisite B: capability behavior vs application/domain model
- 30. • Machine Identifier • Customer Identifier • Customer Site • Machine Room • Online Connected at timestamp • Installation BOM – array • Competition Spotted – Boolean • … Machine Commissioned
- 31. Inventory Domain Service Domain Marketing Domain … Domain • Machine Identifier • Customer Identifier • Customer Site • Machine Room • Online Connected at timestamp • Installation BOM – array • Competition Spotted – Boolean • … Machine Commissioned Event Data Reality Real Time Data in Motion Materialized Sourced from Reality At Rest Shaped for Purpose
- 32. Machine Commissioned Machine Upgraded Machine Relocated Machine Disconnected Machine … Behavior Machine Behavior Data on the outside* *: https://www.cidrdb.org/cidr2005/papers/P12.pdf Business Event MachineCommissioned = Event Type Machine = Event Subject Commissioned = Event Action Machine Behavior by AFTERMARKET Service Capability
- 33. BUSINESS DOMAIN (CAPABILITY L?) CAPABILITY L ? SUBJECT Machine Commissioned Machine Upgraded Machine Relocated Machine Disconnected Contract Sold Contract Extended Contract Cancelled Machine Contract Part … … We group Business Events on capability subject level Task Started Task Finished Task Service Sales Aftermarket BUSINESS DOMAIN (CAPABILITY L?) Business Unit BU01 Production … By the way: Data Governance Council: interested ?
- 34. Machine Commissioned MACHINE Machine Connected Machine Upgraded Machine Serviced Machine Serviced … SERVICE.MACHINE AFTERMARKET.SERVICE.MACHINE BU01.AFTERMARKET.SERVICE.MACHINE BU01.AFTERMARKET.SERVICE.MACHINE.EVENTS BU01.AFTERMARKET.SERVICE.MACHINE.EVENTS.V1 QA.BU01.AFTERMARKET.SERVICE.MACHINE.EVENTS.V1 EVENT GROUP = KAFKA TOPIC Capability structure Data Governance Aligned Capability Behavior Subjects Domain Information Architecture
- 35. Rationale: 1 Security Security levels on • Env • Domain/Capability • Behavior Subject 2 Simplicity • Clear structure • Enterprise standard • Self service 3 Domain Driven • Tech/Application agnost • Grip on Complexity • Aggregate concept 4 Causality • Business value of ‘causality’ • ‘One thing leads to another’ • Lifecycle of the Subject • Order we must have Why do we need to group Business Events? (on capability-subject level)
- 36. Align & evangelize with EDA Manifest Topic naming conventions Order guarantee with Key Use Schema’s (on write) Define Retention Policy …. Manifest Allignment sessions
- 37. Order guarantee with Key: Key selection is a modelling concern Key defines Lifecycle of the Subject Key Schema’s or not ? Input for Operating Model (Design)
- 38. Use Schema’s (on write): Enforces clear company vocabularity (ubiquitous capability language) Enforce schema validation Schema on write
- 39. Retention Policy Align on the single source of truth Position your (Near) Real Time Data Products Retain until proven otherwise
- 40. Use the Manifest to : Align Apply Drive
- 41. EDA How ? Choose Approach Align & evangelize with EDA Manifest Define Operating model Elevate & Repeat
- 42. Operating Model: Reference Architecture Event Design Event Publish App Develop App Deploy App Operate Event Observe
- 43. EDAReferenceArchitecture: Continuous Integration EDA Design Develop Deploy Operate Observe Design Design Design Design Design Event schema Design tool Event Catalog Event Standard s Code Repository Continuous Deployment APP using EDA Design Behavior Automated Test tool Test environment EDA EDA Operational Registry EDA Change Data Capture Application databases Lakehouse EDA Client Public PaaS FaaS EDA Client EDA Source/Sink Connector Event Streaming Processes proxy API Application with connector API oriented applications Self- Service & Admin Portal Distributed Event Monitor Owner Dev Engineer Release Engineer EDA Analytics Discovery. Publish EGO Reference Board Release Management Operations Feature Team Analyst API Federated EDA Public PaaS Cloud Message broker Public PaaS Technical Monitoring Business Monitoring QOS * Product Team APP Business Events APP Business Events APP Business Events IoT devices Dashboard & Reports. Real Time Data Products Feature Team
- 44. EDA How ? Choose Approach Align & evangelize with EDA Manifest Define Operating model Elevate & Repeat
- 45. Elevate & Repeat
- 46. Elevate & Repeat
- 47. Work Package Responsible Accountable Consulted Informed 1. Use Case A 1. Use Case B 4. Operating model 5. Architecture – EDA manifesto 6. Ubiquitous EDA Vocabulary 7. Technical engineering guidelines 8. EDA solution architecture guidelines 9. EDA Platform setup and operations 10. EDA capability Roadmap RACI matrix:
- 48. EDA How ? Choose Approach Align & evangelize with EDA Manifest Define Operating model Elevate & Repeat
- 49. Supporting reading material: Systems Thinking: Managing Chaos and Complexity: A Platform for Designing Business Architecture – Jamshid Gharajedaghi Building Evolutionary Architectures – Neal Ford, Rebecca Parsons & Patrick Kua Mastering Kafka Streams & ksqlDB – Mitch Seymour Designing Data Intensive Applications – Martin Kleppman Designing Event-Driven Systems – Ben Stopford Ref cases: -TVH/Mateco -AXA Insurance BE -Sabbam -Atlas Copco -Engie -A Huge Sports Brand -… wim@cymo.eu https://www.linkedin.com/in/wim-debreuck/