One of the main challenges of developing a business web application is in the adaptation of business language into a set of rules that can be programmed. Economic concepts such as agents, resources or events are not easy to translate into software. Typically this challenge is battled using code-centric approach and, more recently, different model-centric solutions start to appear. We believe we’ve improved the model-centric approach.
Our approach takes the model-centric development and builds on it. By adding a rich business semantics layer on top of the model-centric approach, we re-imagined the way you model your applications and our results tell us that we’re in the right path. Modelling with our platform is not only faster but more intuitive, and because it’s a no-code feature, it can easily be done by non-developers.
Based on an economic theory called Resources, Events, Agents (REA), we’ve developed several economic concepts in our low-code development platform to help create business software applications, from the ground up.. By taking advantage of our domain specific [business] language, getting started with a business web application and define its core model has never been easier.
To allow our users to easily develop their core elements without the need for code, we’ve developed a few economic elements that will serve specific purposes in your web applications:
– Economic Resource: something scarce, has utility for economic agents, and is something users of business applications want to plan, monitor, and control. Examples of economic resources are products and services, money, raw materials, labour, tools, and services the enterprise uses;
– Economic Agent: individual or organization capable of having control over economic resources, and transferring or receiving the control to or from other individuals or organizations. Examples of economic agents are customers, vendors, employees, and enterprises;
– Economic Event: represents a change in the value of economic resources that are under the control of an agent. Some economic events occur instantaneously, such as sales of goods, and some occur over time, such as rentals, labour acquisition, provision and use of services;
– Economic Commitment: promise or obligation of economic agents to perform an economic event in the future. For example, line items on a sales order represent commitments to sell resources.
We believe that by applying these economic principles directly into the core of our development experience, we’ll guarantee not only a much better web application but also its adaptability to future business changes.
Now that we know what purpose these business elements serve, let’s exemplify how you can easily identify which type of elements you should use when developing a web application with OMNIA.
(Example Use Case)
For this example, we’ll create a scenario for a company named Analog Sound, detail what its basic business logic is and define the structure for a business web application that will allow it to automate its sales and purchase processes.
Analog Sound is a business that makes money by reselling analogue music-related products, like record players and vinyl records to its customers, via its website. The customer gives money to the company that, in turn, will purchase it to its supplier and deliver it to the customer. A simple cash for product transaction.
The orders come in via its website and are manually placed in its supplier’s platform. One of the goals of the company’s new web application is to eliminate this manual step, by merging the sales and purchase processes.
To properly develop a web application able to deal with this issue we need to define its sales and purchase processes so that we can identify the core business elements needed for our web application.
Domain Rules (from the book “Model-Driven Design Using Business Patterns” by Pavel Hruby)
- Every increment economic event must be related by exchange duality to a decrement economic event, and vice versa.
- Every increment economic event must be related by inflow relationship to an economic resource.
- Every decrement economic event must be related by outflow relationship to an economic resource.
- Every economic event must be related by a provide relationship to an economic agent, and by a receive relationships an economic agent. At runtime, these two agents must represent entities with different
Sales Process Structure Elements
|Company (Analog Sound)||Product||Sale|
Purchase Process Structure Elements
|Company (Analog Sound)||Product||Cash Payment|
As we can conclude from the previous diagrams, the Sales and Purchase processes share most of their core elements, therefore, the elements needed for the structure of our web application are:
|Company (Analog Sound)||Product||Sale|
Platform Sales Event UI
Platform Purchase Event UI
Developing a business application from the ground up involves a lot of work hours and complicated adaptations of business language into mathematical business rules, resulting in expensive, long and unproductive processes. In addition, business rules can, and often will change, making the adaptation of these rules a key aspect of a modern business application. We provide that by design.
Thanks to our rich semantic modelling language, derived from the REA model, coupled with our no-code structure modeller, the path from business rules to a basic web application becomes much simpler and intuitive. Defining these elements correctly is fundamental for a solid and scalable application model.
This is only the first step of our web application development experience, the next steps will be featured in future posts. We hope we’ve shed some light into why we’ve adopted this methodology and made clear the modelling advantages of using our low-code development platform.
If you want to try out some of our other features just send us an email and will provide you with a free, full featured, demo of our low-code platform.