Knowledge Hub

Business Modelling is the practice of understanding how an organization works as a whole. It explains how value is created, how work flows through the organization, who is involved at each step, and how decisions are made. At this stage, the focus is not on data, databases, or systems, but on the business itself. The aim is to clearly describe what the organization does and how it achieves its objectives.

The main goal of Business Modelling is to provide a complete and holistic view of the business. When this view is clear, it becomes much easier to align daily operations, management decisions, and supporting systems with the organization’s strategic goals. Without this shared understanding, systems and data solutions are often built in isolation and fail to support real business needs.

Business Modelling concentrates on the “what” and the “how” of the business. It looks at business processes, roles, responsibilities, rules, and policies. It helps answer questions such as: What activities are performed? Who performs them? What decisions are taken, and based on what rules? Because of this, Business Modelling is usually the first step before moving into information modelling and data modelling. It establishes where data is created, how it flows, and how it is ultimately used.

Process Modelling, often referred to as Business Process Modelling (BPM), is the practice of describing how work is carried out step by step inside an organization. It visually represents workflows, activities, and decision points so that everyone can clearly understand how a process starts, how it moves forward, and how it ends. Unlike Business Modelling, which explains the business at a high level, Process Modelling focuses on the actual flow of work.

The main goal of Process Modelling is to analyse and improve business processes. By clearly documenting each step, organizations can identify delays, unnecessary work, repeated tasks, or unclear responsibilities. Once these issues are visible, processes can be standardized, improved, or automated to achieve better efficiency and consistency while staying aligned with organizational objectives.

Process Modelling provides a structured way to document how work moves across people, systems, and departments. It shows who performs each task, when decisions are made, and how work is handed over from one role to another. Because of this, Process Modelling often acts as a bridge between business requirements and system design. It is commonly used as a foundation for automation, compliance checks, and process improvement initiatives.

BPMN, which stands for Business Process Model and Notation, is a standardized visual language used to represent business processes. While Process Modelling explains the steps of a workflow, BPMN defines how those steps are drawn and represented so that everyone reads the process in the same way. Its purpose is to remove ambiguity and provide a clear, consistent way to describe how work flows through an organization.

The primary goal of BPMN is to create a common language that can be understood by both business stakeholders and technical teams. Business users can read BPMN diagrams to validate whether a process reflects how the organization actually works, while technical teams can use the same diagrams to configure workflow systems or automation tools. This shared understanding reduces miscommunication between business and IT.

BPMN builds on the ideas of Process Modelling by introducing a defined set of symbols and rules. These symbols represent common process elements such as activities, events, decision points, and responsibilities. For example, tasks represent work being performed, events show when a process starts or ends, and gateways represent decisions such as approvals or rejections. Swimlanes are used to show who is responsible for each task, such as a person, role, or department. Because these symbols are standardized, BPMN diagrams look familiar and consistent across organizations and industries.

Domain-Driven Design, commonly known as DDD, is an approach to modelling and system design that starts by deeply understanding the business domain. The term domain refers to the problem area the business is working in, such as banking, healthcare, education, or retail. DDD Modelling focuses on capturing the key business concepts, rules, and meanings, and making sure both business people and technical teams talk about them in the same way.

The main goal of DDD Modelling is to ensure that system design closely reflects real business needs. Instead of designing systems based only on technical convenience, DDD encourages teams to model software around how the business actually operates. When done correctly, the system grows naturally alongside the business, rather than becoming disconnected from it.

A central idea in DDD is the creation of a shared or ubiquitous language. This means that the same terms are used consistently by business experts, analysts, and developers. When a business person says “approved loan,” the developer and the analyst understand exactly what that term means, without needing further clarification. This shared language reduces misunderstandings and makes collaboration much easier.

Enterprise Data Modelling is the practice of creating a single, high-level view of data for the entire organization. Instead of looking at data system by system or project by project, it looks across all business areas and defines how key data concepts are understood at an enterprise level. The purpose is to make sure the organization has a shared understanding of its most important data.

The main goal of Enterprise Data Modelling is to provide a consistent framework for managing data across the whole enterprise. When this framework exists, different departments and systems can work together more easily. Data becomes easier to integrate, compare, and trust, because everyone is working from the same definitions.

This modelling approach brings together data from different subject areas such as customers, products, finance, and operations into one unified model. Rather than allowing each system to define data in its own way, Enterprise Data Modelling defines common entities and relationships that apply everywhere. Because of this, it acts as a strategic blueprint rather than a detailed design for a single application.

Conceptual and Logical Architecture Modelling describes the overall structure of an enterprise’s systems and how they interact, without focusing on specific technologies or physical implementations. It provides a blueprint that explains which systems exist, what roles they play, and how data and processes flow between them. At this stage, the goal is understanding and alignment, not technical configuration.

The primary goal of this modelling approach is to ensure that systems, data, and processes are well aligned with business needs. By clearly defining how different parts of the architecture fit together, organizations can design solutions that are scalable, well-integrated, and easier to govern over time. This helps prevent fragmented systems and poorly connected solutions that grow in isolation.

Conceptual and Logical Architecture Modelling focuses on components and interactions, rather than code, databases, or vendors. At the conceptual level, it presents a high-level view of the architecture, typically showing major domains such as applications, data, and infrastructure. This view answers questions like which systems exist and what their responsibilities are. At the logical level, the model goes a step further by showing how data flows between systems, how integrations work, and how systems are logically grouped, still without committing to specific technologies.

Concept Modelling is the practice of identifying and defining the core business concepts and making sure their meanings are clearly understood and consistently used across an organization. It focuses on what things mean in the business, rather than how they are stored, processed, or implemented in systems. The purpose is to create shared understanding before any technical design begins.

The main goal of Concept Modelling is to establish a common vocabulary. In many organizations, the same word can mean different things to different teams. Concept Modelling removes this confusion by clearly defining key terms and agreeing on their meanings. When everyone uses the same language, communication improves and misunderstandings are reduced.

This modelling approach captures the essence of business concepts such as Customer, Loan, Product, or Approval Decision. It also shows how these concepts relate to one another at a semantic level. Importantly, Concept Modelling does not include technical details such as attributes, data types, tables, or system logic. It stays intentionally simple and focused on meaning. Because of this, concept models often become the foundation for later artefacts such as ontologies, information models, and data models.

Information Modelling is the discipline concerned with how information is described, structured, and communicated so that it can be clearly understood and consistently interpreted by people, processes, and systems. Its focus is not on technology or databases, but on ensuring that the meaning of information is precise and unambiguous.

The primary goal of Information Modelling is to achieve semantic clarity. When information is clearly defined and consistently represented, it can be exchanged reliably across departments, systems, and even organizations. This clarity is essential for effective collaboration between business and IT, as well as for building systems that truly reflect business intent.

Information Modelling concentrates on capturing facts, terms, and relationships in a structured and rigorous way. It emphasizes meaning over implementation. Instead of asking how data will be stored, it asks what facts exist in the business, how those facts are expressed in language, and how they relate to one another. Because of this, Information Modelling acts as a bridge between business communication and data modelling.

NIAM, which stands for Natural Language Information Analysis Method, is an early fact-oriented approach to Information Modelling that was developed in the 1970s and 1980s. Its key idea is simple but powerful: business information should first be expressed in plain natural language before being transformed into formal models. By doing this, NIAM allows business users to understand and validate information models without needing technical knowledge.

• NIAM originally stood for “Nijssen’s Information Analysis Methodology.” This refers to the fact-based modeling approach developed by G. M. Nijssen in the 1970s. 
• Later on, the acronym was generalized to “Natural Language Information Analysis Method.” This change was made because many people contributed to the method, not just Nijssen, and to emphasize its basis in natural language. 

The primary goal of NIAM is to capture business information in a way that is both easy to understand and structurally precise. Instead of starting with diagrams or tables, NIAM begins with sentences that describe facts about the business. These sentences reflect how people naturally talk about their work, making it easier to confirm whether the model accurately represents reality.

Object-Role Modelling, commonly known as ORM, is a fact-oriented conceptual modelling method that represents information as objects playing roles in facts. Unlike traditional data modelling approaches that focus on attributes or tables, ORM treats facts as the core building blocks of information. Each fact describes how one or more objects participate in a relationship.

The main goal of ORM is to provide a precise and expressive way to capture business information and rules directly in the model. It allows modellers to describe not only what facts exist, but also the constraints that govern those facts. This makes ORM particularly useful in environments where accuracy, consistency, and clarity of business rules are critical.

ORM builds on the ideas introduced by NIAM but adds much stronger structure and formality. In ORM, every piece of information is modelled as a fact type. For example, instead of saying that an employee has a department attribute, ORM represents the information as the fact “Employee works for Department.” In this statement, both Employee and Department are objects, and “works for” describes the roles they play in the fact. This approach keeps the model close to business language while making relationships explicit.