It's a dream as old as business computing: the ability to create a graphical model and then to deploy it as a working information system. Many attempts to realize this dream have come and gone with varying degrees of success, from visual programming languages like Visual Basic and Scratch, to business workflow systems like BPMN and its proprietary commercial variants, to engineering-focused systems like UML. But let's face it: most low-code and model-based application development tools fall far short of the needs of modern software development teams. At best, they're useful for rapidly testing ideas and creating prototypes. At worst, they're used by "citizen coders" to cynically circumvent good engineering practices, with IT operations left holding the bag of operating, securing, and scaling black-box applications that cut against modern DevSecOps practices. Event-driven application architecture, enabled by infrastructure like Kafka and its ecosystem, has the potential to dramatically advance toward the age-old, model-driven and low-code dream. But what would an event-centric and developer-friendly low-code look like? This talk will outline strategies for low-code and model-driven development based on Event Modeling. We'll explore how event-driven application architecture provides a simple yet robust framework for generating DevSecOps-friendly code for the UI, for the web services layer, and for event-processing.

1. Copyright 2021 Evident Systems LLC
Bobby Calderwood — September 15, 2021
Model-driven and low-code development
for event-based systems

2. The goal and the problem
• My name is Bobby, and my team makes https://oNote.com
• Our goal is to help software teams design, implement, and operate event-driven
systems
• Design with your team on our collaborative Event Modeling canvas
• Operate via platform integrations and streaming data visualizations
• Implement is a tricky one…

3. A brief (and incomplete) review
of model-driven and low-code approaches

4. Visual programming languages
• Notably Visual Basic, Scratch, Xojo, Xcode IDE and languages
• Not much to say here other than, “cool!”
• Often focused on UI and/or low-level program
fl
ow
• Designed for single-process, non-situated programs with transient state
• Still in common use, lots to learn from these tools

5. System modeling languages
• Notably UML
• In theory: comprehensive round-trip engineering, integrated documentation, shared model that
improves system comprehension among stakeholders
• In practice:
• Very little business stakeholder involvement/comprehension
• Mostly about system-level concerns (nerd stuff), not so much business and user concerns
• Lots of static nouns and OOP stuff, not great at describing state change over time
• Some helpful stuff: sequence diagrams, state machine diagrams

6. Business workflow and rules systems
• Notably BPMN, BPEL, jBPM, YAWL, Drools, RETE/Clara etc.
• Primarily about composing business logic rather than recording the business narrative of state
change over time
• Business events are transient and merely transition the FSM among states
• de facto: poorly named states that are more like events (“Approved by Management”)
• Business process diagramming is complex, and often devs confound business-process scale
constructs with programming-language constructs
• Initially intended for business users, but in reality end up being programmed by developers (tying
devs hands)

7. — Martin Fowler
Often the central pitch for a rules engine is that it
will allow the business people to specify the rules
themselves, so they can build the rules without
involving programmers. As so often, this can
sound plausible but rarely works out in practice.

8. Full stack low-code/no-code
• Lots of commercial offerings here, many as outgrowths of Business Work
fl
ow systems
• Designed to empower a legion of non-developer citizen coders, implicitly to work
around slow or unresponsive IT departments
• Often end up creating systems that don’t
fi
t in well with DevSecOps practice/ethos
• Black box ops, analytics, and security increases reliance on vendor
• Often very in
fl
exible and inextensible
• Easy to get going, but hit a wall if you want to go outside of well-trodden path

9. Open and standard interface definition languages
• Notably WSDL, OpenAPI/Swagger, GraphQL, gRPC, AsyncAPI
• Declarative and data-oriented rather than visual
• De
fi
ne (usually transient) communication protocols
• Not much structure/opinion around state over time via business events
• Great for de
fi
ning pieces of technical infrastructure and automating boring, repetitive
tasks

10. UI wire-framing tools
• Notably Figma, Adobe XD, Sketch.app, Balsamiq, etc.
• Similar to older visual programming environments like Visual Basic, Xcode, etc. but
almost exclusively focused on UI/UX design
• Some limited code generation, especially for UI-components-as-functions ecosystems
like React, Elm, other FRP-ish
• Emerging class of schema-driven form UI tooling

11. What has changed to justify a new approach to
model-driven and low-code development?

12. The need to understand the customer journey
Web
Call Center
Location
Mobile
Social Media
Email

13. The need to understand the customer journey
Web
Call Center
Location
Mobile
Social Media
Email
Business Event Log

14. The need to understand the customer journey
Web
Call Center
Location
Mobile
Social Media
Email
Business Event Log

15. The need for real-time
• Customer noti
fi
cation
• Decision making
• Analytics and machine learning
• Systems and data integration

16. Other factors
• Polyglot persistence
• Resurgence of functional programming ideas
• Better
fi
t for distributed computing
• Heavy in
fl
uence on UI development
• Components as functions that specify their data requirements
• Functional reactive state-management patterns, driven by business events
• Useful ideas emerging from Domain-Driven Design, and related communities

17. In short:
Business event-based application design

18. Requirements for event-based model-driven/low-code development
• A model for describing how state changes over time
• An extensible schema language for describing data: state, transition, transfer/
protocol
• Suitable output targets
• Intermediate representations
• Runtime languages, libraries, frameworks

19. Event Modeling describes state changes over time

20. Event Modeling describes state changes over time
• Focus on state change over time rather than business logic or system concerns
• Explicit patterns for integrating with external systems not under our control
• User experience design is
fi
rst-class
• Semantic data transfer objects (DTOs)
• Business logic
fi
ts into:
• Limited places
• Speci
fi
c types

21. Schema languages describe immutable data values
• Neutral: can target many output languages and formats
• Powerful and Flexible: can describe a wide variety of data structures
• Serializable and transmittable: can be saved and sent as part of an Event Model
• Extensible: can be extended to
fi
t new use-cases and output targets

22. What makes a suitable output target?
• DevSecOps friendliness!
• Git/SCM-amenable
• Easily integrated with CI/CD pipelines
• Change-log auditable
• No black-boxes!
• Intermediate representations vs. runtime code
• Programming-language neutral and/or broad coverage and support

23. Full-stack output targets
UI Components
Figma, etc. HTML/React output
Declarative, schema-based forms
Web Services
Interface De
fi
nition
gRPC via Protobufs/Avro
GraphQL
OpenAPI/Swagger
Event Processing
KSQL & ksqlDB
AsyncAPI
Event schemas as Avro/Protobufs/json-schema

24. It all comes together:
oNote generates Avro Protocol and
Event Schemas

25. Conclusion
• Model-driven and Low-code development are worthwhile pursuits, and need a refresh for
modern constraints and practices
• Don’t pursue low-code development to replace dev teams with citizen coders!
• Instead:
• Accelerate development with robust models and generation of real code and open-standard
intermediate representations
• Facilitate feedback from ops/production (coming to oNote soon!)
• Facilitate communication and learning along value chain via shared goals, incentives, and
models

26. Thank you!