Whether you call it a conceptual data model, a domain map, a business object model, or even a “thing model,” a concept model is invaluable to process and architecture initiatives. Why? Because processes, capabilities, and solutions act on “things” – Settle Claim, Register Unit, Resolve Service Issue, and so on. Those things are usually “entities” or “objects” in the concept model, and clarity on “what is one of these things?” contributes immensely to clarity on what the corresponding processes are.

After introducing methods to get people, even C-level executives, engaged in concept modelling, we’ll introduce and get practice with guidelines to ensure proper naming and definition of entities/concepts/business objects. We’ll also see that success depends on recognising that a concept model is a description of a business, not a description of a database. Another key – don’t call it a data model!

Drawing on almost forty years of successful modelling, on projects of every size and type, this session introduces proven techniques backed up with current, real-life examples.

Topics include:

  • Concept modelling essentials – things, facts about things, and the policies and rules governing things.

  • “Guerrilla modelling” – how to get started on concept modelling without anyone realising it.

  • Naming conventions and graphic guidelines – ensuring correctness, consistency, and readability.

  • Concept models as a starting point for process discovery

  • Practical examples of concept modelling supporting process work, architecture work, and commercial software selection.

One-sentence description

Alec illustrates the many ways concept models (conceptual data models) support business process change and business analysis, and vice-versa.