Model-as-Software

design, generate, and run software — starting from the model.

Go from visually designing a Model, to running as a Software Application.

“A system where software can be designed at a high level of abstraction, then automatically transformed into robust, scalable, fully functional applications — with minimal coding, full flexibility, and real-time adaptability.”
Formal Description

Model-as-Software is a declarative architecture paradigm where a formally defined model — consisting of object structures, relationships, behaviors, rules, and triggers — is executed as a live, reactive object graph. This list represents the full application state and behavior in real time.

The gap between the Model and the Software
The gap between a defined model and a working software system has long been a core challenge in software architecture. While models offer a high-level, declarative view of a system's structure and behavior, transforming those models into a functional, distributed, and reactive application requires a significant amount of complex infrastructure. This "gap" is not trivial — it involves runtime execution, real-time synchronization, event propagation, validation, transactional consistency, and extensibility.

Bridging the gap between model and software execution has been one of software engineering’s most persistent challenges.

Nearly all modern software architectures, frameworks, and platforms are ultimately attempts to fill this same gap — to take an abstract model or mental picture of a system and make it executable.

Common approaches include:

Core Requirements to Fill the Gap

1. ⚡ Live Execution of the Model
  • The model must be interpreted or executed in a live, running environment.
  • All relationships, constraints, and behaviors must be enforced at runtime.
2. 🔄 Reactive Object Graph
  • The system must maintain an observable object graph that reflects real-time state.
  • Dependencies (e.g., calculated properties, triggers) must be tracked and updated automatically.
3. 🌐 Synchronization Across Clients and Threads
  • All parts of the system — including distributed clients — must operate on a consistent view of the object graph.
  • Changes must be serialized, ordered, and propagated safely.
4. 🧱 Automated Code Generation
  • Boilerplate code (POJOs, DAOs, UI templates, REST endpoints) should be generated from the model.
  • Code must remain disposable and aligned with the model's definition.
5. 🧾 Metadata-Driven Architecture
  • The system must use rich metadata from the model for configuration, rules, access control, and behavior.
  • This metadata must remain consistent throughout the system lifecycle.
6. 🔌 Extensibility and Integration
  • The architecture must be open and composable.
  • New technologies (e.g., UI libraries, external APIs, databases) must be easily integrated.
OA’s Model-as-Software Stack
🔧 OABuilder

Visual modeling tool to design your system using a domain object graph. Enables collaboration between architects and domain experts.

📘 OA Models

The structured, metadata-rich representation of your domain. Includes object types, links, triggers, calculations, rules, and constraints.

⚙️ OACodeGen

Customized code generation: build the full-stack application for specific software targets. Learn more

🧠 OAObjectGraph

The runtime engine that executes the model as an object graph. Tracks live state, enforces rules, propagates changes, and syncs clients in real time. Learn more

📚 OA Libraries

A complete set of supporting libraries for UI binding, persistence, REST, security, datasources, distributed messaging, etc — all model-driven and integrated with the Object Graph.

📜 Model-as-Software Manifesto
Model-as-Software - A Foundation for Software Engineering