From database-driven CRUD screens to event-driven architectures — some highlights.
Six paradigm shifts that shows my thinking about generating applications over time.
The journey began at that time when Oracle was positioned as the source of truth for entity relationships and database schemas. So I copied some of it : CRUD screens including parent-child structures could be generated directly from a drag-and-drop graphical Borland Object Pascal environment. This was a simple, predictable and remarkably effective solution.
So last century though.
Elevating beyond data structures to enterprise architecture. Modelling applications across domain, process, data, and workflow dimensions. Every model was a FBP based graph which showed the flow of information and where nodes could contain code, a neural network, a form. A comprehensive view — powerful but sometimes unwieldy for smaller projects. The olden days of Smart Mobile Studio.
Specs. Worked (up to a point)Using AI in earnest. I found it very rewarding to be able to use natural language to generate complete front-end applications — vanilla JavaScript, HTML, CSS — from just one or two sentences. Describe what you need, receive working code.
Example : Car rental booking app. Works beautifullyExpanding this into the entire stack. Front-end, database schema, API endpoints, authentication — all generated from natural language descriptions. Full applications from a couple of sentences.
Example : Maximo clone. WorksThe next idea was to define a single source of truth, a single structured document (formatted as .yaml) that serves as the definitive specification. One file that can be parsed into complete front-end and back-end applications. The specification becomes the application.
Screenshot Asset Management. WorksEvent-Driven Application Design Methodology — a complete design framework that guides application design by treating systems as reactive entities that respond to events, enforce business rules, and learn from outcomes. It moves beyond traditional database-centric design toward architectures where change—not storage—is the primary concern.
List every occurrence that impacts the lifecycle of the main actors and categorise these events.
Every event identified has a payload. Determine what attributes need to be captured or calculated when that event fires. This transforms abstract events into digital records.
Combine multiple signals into a single state assessment. This aggregates the disparate data streams of the different events into a composite score, representing the true state of the entity.
Apply the limits of reality. Take these composite scores and run them against the hard limits of the organisation. Acknowledge that the "best" technical solution is not always possible due to budget, labor, or risk tolerance.
This approach treats the asset as a receptor of, and sometimes as generator of, events—some physical, some temporal, and some strategic. EDAM can be applied manually, or the EDAM specs can be fed directly into an LLM to generate complete, event-driven applications.
Example drop-shipping app. Works beautifully