Ontology and Business Rules in an Event-Driven Architecture
Event-Driven (Business) Architecture (EDA) helps in building efficient value chains where high quality data is produced and exchanged. Adding Ontology and Business Rules perspectives to an Event-Driven Architecture helps increasing its efficiency and effectiveness even further. In this article we show how this works.
We start with describing how a Business that follows an Event-Driven Architecture (EDA) is built up:
That is quite some information packed in there! So let’s break this description down step by step, by defining each element stated in bold text individually. And let’s use the concrete example of an e-commerce business with a Value Chain that provides the Business Service of order fulfillment. We will use three perspectives on the same example: 1) Ontology view, 2) Event-chain view, and 3) Business Rule view.
If you don’t know what an Ontology or Business Rule is, please check out this article first: Difference between Ontology and Business Rule.
Perspective 1: Ontology view
Since an Event-Driven Architecture is very much data-oriented, we will start with the Ontology view shown in Figure 1. The two core elements that are shown in Figure 1 are Business Entity and Business Event. We will start our breakdown with explaining these two elements.
Figure 1: Data view
A Business Entity: represents a tangible thing or virtual concept that is used within a particular business context. You can recognize an Entity from the <Noun> that is used to refer to it. As you can see in Figure 1, the following Entities are used in our e-commerce example: ‘Customer’ (which is also an Actor), ‘Order’, ‘Invoice’ and ‘Payment’. An important requirement for specifying a Business Entity is to give it a proper definition. For example, an ‘Order’ is defined as: ‘A legal binding confirmation issued by a Customer indicating what they want to purchase and how much they will pay for said purchase’. Giving all Business Entities a clear definition prevents miscommunication and increases the chance of maintaining high data quality during the life cycle of Business Entities in the wider Value Chain. In Figure 1 you can also see that Business Entities can be interrelated. In Hapsah, these interrelations between Business Entities are expressed in short statements with the following sentence structure: <Subject noun> <Verb> <Object noun>. In essence, this is how you build what is called an Ontology in Hapsah. Examples for our e-commerce model are:
A Business Event: is a publication of a state change on a Business Entity. The name of an Event typically combines the <Noun> that represents the name of the involved Business Entity followed by the state change, e.g. ‘Invoice created’, or ‘Payment received’. At any point in time a Business Entity can have one of multiple possible states. In our example an ‘Order’ Business Entity can be in one of the following states: ‘placed’, ‘validated’, ‘finalized’ or ‘confirmed’. The creation or state change of a Business Entity, which results into a Business Event being published, is the result of a Business Activity performing one or more Business Rules.
Perspective 2: Event-chain view
To continue the breakdown of our definition of an Event-Driven Architecture, we will now switch to the Event-chain view of our e-commerce example shown in Figure 2. Figure 2 shows the entire interaction between Business Capabilities starting with the ‘Customer’ (on the left) performing the Business Activity ‘Place Order’ and ending with the ‘Customer’ receiving an ‘Order confirmed’ Business Event notification. Again, a whole lot is happening here, so let’s go through the remaining terms step-by-step.
Figure 2: Process view
A Business Activity: is a business behavior (action) that achieves a specific result, such as the creation of state change of a Business Entity. I prefer the term ‘Activity’ over ‘Process’ because that does not imply any prefabricated/fixed workflow, which is less relevant for Event-driven environments. You can recognize an Activity by its name being written like <Action verb> <Noun>, where the <Noun> refers to a Business Entity. For example the ‘Place Order’ Activity in our e-commerce example, which leads to the creation of an ‘Order’ Business Entity. When a Business Activity creates a new or changes an existing Business Entity, then it publishes a Business Event to notify its environment.
A Business Capability: is a bundling of Business Activities based on a chosen set of criteria (typically required business resources and/or competencies). So how are Business Activities bundled into Business Capabilities? This is not an exact science, but also a little bit of an art depending on the Business Architecture style you are following. In an EDA you typically see Business Capabilities being groups of Activities that together work towards given outcomes related to specific Business Entities. To make that more concrete, let’s look at the ‘Billing’ Business Capability as part of our example. This Business Capability includes all Business Activities that work together towards Invoices being ‘created’, ‘sent’, and matched on incoming Payments, resulting in the state ‘paid’.
Workflow in the Event-chain
As hinted on before, in an EDA there is no hard-coded workflow. The order in which Business Activities (as part of Business Capabilities) are performed depends on: What are the Business Event publish & subscribe interrelationships between Business Activities? This means that any Business Activity can determine autonomously (to a large extend) which Business Event(s) it will consume as its condition(s) to perform its actions. For example, we could have modeled the behavior of the ‘Finalize Order’ Business Activity differently by only taking the ‘Order validated’ Business Event as its triggering condition. This would result in a different workflow where ‘Order’ being ‘finalized’ and ‘confirmed’ would be triggered directly after it received the status ‘validated’. The Billing Capability would then lead to an eventual ‘Invoice paid’ state later on. The actual changes needed to implement this alternative workflow are very small, because it only requires removing one Business Event condition in the ‘Finalize Order’ Business Activity. That is one of the big advantages of an Event-driven Business Architecture.
Perspective 3: Business Rule view
The last topic we will briefly touch upon are Business Rules. This is actually a very broad topic where many different forms of Business Rules exist. We will only cover the type of Business Rule that is extremely relevant for Event-driven Business Architectures: Action rules. Action rules always consist of at least two parts: Conditions (the ‘When’ part) and Actions (the ‘Then’ part). An example Business Rule in our e-commerce Value Chain is:
The color coding is used for easier reading of a Business Rule. In red are the words that guide the syntax of a business rule and make it a (controlled) natural language sentence (e.g. When and then). Business Entities are marked in underlined green. The verbs that represent the relationships between Business Entities are written in italic blue. The state changes of Business Objects are depicted in bold purple.
Conclusions
By connecting Business Activities (grouped in Business Capabilities) via Business Events that are produced and consumed, a Value Chain is created. Such Value Chain delivers a Business Service to a Customer (or other type of consumer) in a very efficient and action-driven manner, due to Action Rules. Changes in workflow can easily be made with little impact on Business Capabilities. So, if you want to build an efficient and flexible business, try an Event-Driven Architecture including the Ontology and Business Rule perspectives as shown in this article. It will make your life much easier! And Hapsah is the perfect platform to build your Event-Driven Architecture in this way.
You are welcome to try Hapsah out: https://www.hapsah.org/try-now/
Further reading
If you want to know more about how an Ontology and Business Rules are connected, please check out this article: Connection between Ontology and Business Rule