Re: [ontolog-forum] The Dream of an Enterprise Data Model

8 views
Skip to first unread message

Frank Guerino

unread,
Jun 10, 2026, 7:24:12 PMJun 10
to Ontolog Forum

Hi all,

 

Sorry I’m late to this conversation.  This concept of an Enterprise Model and modeling has been a long-time personal and professional passion of mine, for many reasons; and I love these conversations.

 

For those who aren’t aware, recent developments with AI have made it much easier to design and realize Enterprise Models.  However, doing so requires a change in how people think and work.

 

The Old Way Doesn’t Work: It uses traditional, inflexible, relational schema modeling, that is human-limited (forcing human focus on every table, attribute, key, every change, etc.), and cannot scale to handle vast model diversity, size, or rapid changes.

 

The New Way Does Work: AI coupled with ontology-wrapped inventories has changed how Enterprise Models are designed, constructed, and used.  It’s made it possible to easily and rapidly define and ingest model structures like inventories, specifications, and rules that allow inventories to act as linear dimensions within a multidimensional data/knowledge graph.  Upon ingestion, AI acts as a data compiler that synthesizes the graph (nodes and relationships) that allow full exploration and use of the model.

 

The pattern for realizing Enterprise Models with AI is pretty simple, highly repeatable, and scales.  However, it assumes you have the required memory, compute power, and proper agent(s)…

 

  1. Establish a simple linear Taxonomy to define a domain space that represents the set of all things (Noun Types) to be modeled; in this case “an Enterprise” and what it is comprised of.  (It can be any domain space, really.)
  2. Use the Taxonomy to define its Ontology so as to provide meaning, constraints, and direction for how the data/knowledge graph will be built and leveraged,
  3. Align the Ontology to enterprise inventories and rules that specify what to do with them.
  4. Use AI as the graph synthesizer/compiler to ingest the data and build the graph (this includes reifying the graph both in-AI-memory for itself and externally for other tools), and
  5. Use AI as the runtime to gain real value from the graph.
    • Examples of AI-synthesized visualizations include but are not limited to: Charts, Graphs, Dashboards, Heatmaps, Node Diagrams, Schematic Diagrams, Data Flow Diagrams, Dependency Diagrams, Expandable/Collapsable Trees, and much more.
    • You can also use any other tools you might desire that support ingestion and use of reified graphs.  Or, you can have AI synthesize a complete deployable user interface applications with AI coding.

 

Benefits & Outcomes:

  • No ties to a fixed relational meta-model that is difficult to populate and change.  Change is far simpler and rapid.
  • An interesting byproduct of the above is that the synthesized Enterprise Model is naturally semantic, since AI works better on natural language.  This, in turn, makes it easier to search, traverse, query, compare, analyze, reason, make decisions, etc., off the graph.
  • Because of AI’s ever-improving generative capabilities, it also means it’s very easy to generate simple and complex, interactive, context-specific visualizations from the graph (e.g., reports, dashboards with charts & graphs, schematic diagrams, data flow diagrams, dependency diagrams, dynamic trees, heatmaps, and anything you can imagine).
  • The model can be treated as data snapshots that can be saved, recalled, split, combined, compared, and destroyed.  How you use them is up to you.

 

Successful Implementations:  The above has been implemented and tested with Life Sciences & Pharmaceutical models, Healthcare Payer models, Insurance models, general IT-only Management models, and others.

 

If interested in learning more about this kind of modeling, you can read: Enterprise Models and Modeling Best Practices.

 

I hope you find it useful,


Frank

 

--

Frank Guerino, Principal

The International Foundation for Information Technology (IF4IT)
http://www.if4it.com
1.908.294.5191 (M)

Guerino1_Skype (S)

 


 

From: Ontolog Forum <ontolo...@googlegroups.com> on behalf of Paul Tyson <pht...@sbcglobal.net>
Reply-To: Ontolog Forum <ontolo...@googlegroups.com>
Date: Sunday, May 10, 2026 at 11:25 AM
To: Ontolog Forum ontolo...@googlegroups.com
Subject: Re: [ontolog-forum] The Dream of an Enterprise Data Model

 

+1 to what Mike Peters wrote. And I would add that every going concern has a peculiar organizational genius that sets them apart from their competitors. IT systems can suppress or enhance this genius--in my experience mostly suppress, and organizations survive in spite of, not because of, the shiny new systems that the enterprise software-industrial complex foists upon them.

I became much more effective in my career when I abandoned my passionate belief, still echoed by many, that what ails organizations are defective ontologies (or processes, or data storage, or whatever). What ails organizations are suboptimal "solutions" that ignore the present organizational genius in favor of industry "best practices" leading to cookie-cutter, convenient (only for the IT dept), anti-exceptionalist systems, leaving no room for experiment, innovation, or adaptation by the humans involved.

Best,
--Paul

On 5/8/26 21:44, Mike Peters wrote:

Michael, 

 

Great question you raised.

 

My first assumption is that all sufficiently large enterprises are complex systems with 

  • emergent properties
  • unexpected consequences
  • more than the sum of the whole
  • a life of their own
  • can evolve
  • etc

My second assumption, then, is that any software that models such a complex system must also be a complex system with similar properties.

 

DDD, model-driven design, composition (microservices <<>> monolithic), Ontologies, what coding language, data models, probabilistic vs deterministic, etc., are all tools to achieve the above.

 

I think it is an architectural problem, not a code problem.

Cheers
Mike Peters
-----------------------------------
Ajabbi
Software Engineering www.blog.ajabbi.com
------------------------------------------

 

 

On Saturday, 9 May 2026 at 10:22:39 UTC+12 hpo...@verizon.net wrote:

Michael,

 

Thank you for the feedback. As I mentioned, SCOPE is a work in progress so we appreciate any feedback from potential users.

 

Regarding Domain Driven Design, I believe it’s important to remember that domains have scope boundaries as well, usually boundaries that overlap to a greater or lesser extent with other domains. The word “Capabilities” in the SCOPE acronym could just as easily have been “Domains”, although we chose capabilities for several reasons, including the notion of capacity or quantification within a domain that the word conveys. The SCOPE Model and practitioners’ guide include sections on what we call “adjacent domain” analysis to help clarify what distinguishes one domain from another similar but distinct domain. Of course, whether the domains are considered distinct or not usually depends on the context of the intended user or applier of the domain specific artifact.

 

We suggest considering two types of “adjacency” for domains. One  type of domain is that of domains that are similar to the focus domain but considered distinct by domain practitioners. For example, consider piping or tubing for water and sewage plumbing, vice structural tubing for scaffolding, furniture, fencing, and the like. Likewise, tubing for corrosive liquids or gases or slurries may have different attributes for chemical composition, pressure ranges, rigidity/flexibility, connectors, valves, and the like. Industrial applications for these domains tend to have additional different concerns/attributes than applications in an end consumer setting such as housing or possibly university or medical facility labs. High rise housing is also a different application context from that of a typical single family residential context with a greater focus on pressure and flow volume management, as well as temperature management. One might consider it to all be just plumbing, but to those involved in working within these “sub-domains”, if you like, it all looks quite different. So it usually helps to be clear/explicit about the domain scope boundaries of whatever domain is driving your design.

 

The second type of “adjacency” is that of domains that other, very different, domains have to interact with in a typical enterprise or other operational context. They are adjacent in the sense that there is  some direct interaction between them involving some exchange of information relevant to their respective roles in an enterprise or operation.  For example, a plumbing supply manufacturer will need to have engineering and design interact with manufacturing, as well as purchasing, finance, personnel/HR, or distribution/logistics and with external entities such as tooling and material suppliers, industry associations, regulatory authorities and the like – not to mention legal. The data models used by those domains will typically overlap sparsely with the focus domain and the points of overlap are often problematic because of different choices for what entities and attributes are included, data granularity/aggregation, data element names, and attribute value ranges and units of measure or enumerated possible valid values. Some data mapping is usually required in these cases as it is often not feasible to get all the parties to agree on aligning data models – and usually for very good, domain-specific reasons on each side. Try to understand the reasons for and respect those differences, but also the purposes of the interaction and whether the alignment is good enough for those purposes.

 

Hans

 

From: ontolo...@googlegroups.com <ontolo...@googlegroups.com> On Behalf Of Michael DeBellis
Sent: Friday, May 8, 2026 11:03 AM
To: ontolo...@googlegroups.com
Subject: Re: [ontolog-forum] The Dream of an Enterprise Data Model

 

The SCOPE model is not a system or a computer model, but rather a set of scope dimensions and “value sets” for those dimensions.

 

Thanks for clearing that up. Shows how important context is, in hindsight I assumed it was a model because that's what I'm trying to do, explicitly model DDD concepts in OWL and SHACL on top of a data catalog model defined with Prov and DCAT. 

 

Some material on SCOPE is available at https://www.engineeringsemantics.com/scope.html

 

Thanks for sharing that, it looks very relevant to what I'm interested in.  

 

 You end up with a lot of implicit scope assumptions in every tool, system, data model, ontology, library, enterprise architecture, etc., etc. that you encounter. I can’t tell you how many times I have encountered people saying that product does “X”, only to find that it generally does, but not in context “Y” or for situation “Z”. The unfortunate fact is that it’s very difficult and exhausting to be specific about all the scope boundaries of any given artifact, much less those of a dynamic enterprise in a dynamic environment. SCOPE is an attempt to begin to address this problem.

 

Exactly. This sounds very much like the goals of Domain Driven Design. Look forward to checking it out. Thanks!

 

Michael 

 

On Fri, May 8, 2026 at 7:34 AM hpolzer via ontolog-forum <ontolo...@googlegroups.com> wrote:

Michael,

 

The SCOPE model is not a system or a computer model, but rather a set of scope dimensions and “value sets” for those dimensions. The closest to a computer model we have is a spreadsheet with those dimensions and value sets and some explanatory notes or rationale/suggestions. The dimensions are broken into 5 sets. 

 

The general context dimensions measure how big your enterprise is and its relationship to everything else in broad terms. 

 

The domain-independent capability scope dimensions get into the nature of the enterprise, how it is structured, how open it is, its internal culture/empowerment, how it represents spatial and temporal contexts, how it couples to physical reality, and various types of conceptual realities. The dimensions also explore how the enterprise deals with various social contexts and general semantic interoperability (aside from having our AI talk to your AI! 😊)

 

The domain-dependent capability scope dimensions are open-ended dimensions for describing the scope of the operational capabilities that an enterprise is capable of, or wants to implement,  in domain-specific terms. We have a few example domain dependent capability scope dimension sets and guidelines for developing such sets.

 

The interaction dimensions focus on the technical aspects of communicating within and between enterprises using various communication and networking technologies and infrastructure services (not just the Internet)

 

The technical/economic feasibility dimensions look at the pragmatics of implementing the desired enterprise capabilities via internal and external communications and automation, given implementation costs and operational costs and physical constraints like speed of light, bandwidth, computing speeds and power

 

Some material on SCOPE is available at https://www.engineeringsemantics.com/scope.html

 

We are currently working on revisions and expansions of some of the dimension sets.

 

Regarding your second paragraph, we developed SCOPE because the system development and system engineering communities generally give short shrift to defining scope boundaries. In part, that is due to a lack of a set of yardsticks for doing so, and in part due to the fact that it is a potentially open-ended task. The latter is why some have called me the “SCOPE Creep”. People generally acknowledge that it is important to define scope boundaries, but lack a generally accepted way for doing so. You end up with a lot of implicit scope assumptions in every tool, system, data model, ontology, library, enterprise architecture, etc., etc. that you encounter. I can’t tell you how many times I have encountered people saying that product does “X”, only to find that it generally does, but not in context “Y” or for situation “Z”. The unfortunate fact is that it’s very difficult and exhausting to be specific about all the scope boundaries of any given artifact, much less those of a dynamic enterprise in a dynamic environment. SCOPE is an attempt to begin to address this problem.

 

Hans

 

From: ontolo...@googlegroups.com <ontolo...@googlegroups.com> On Behalf Of Michael DeBellis
Sent: Friday, May 8, 2026 8:53 AM
To: ontolo...@googlegroups.com
Subject: Re: [ontolog-forum] The Dream of an Enterprise Data Model

 

Hans, Thanks. It's good to see that other people have similar ideas. Do you have any papers on Scope that you would recommend to get an overview of the system? Is it completely its own thing or is it tied in with OWL or SHACL (the way some languages to describe ontology patterns are compatible with OWL). BTW, that reminds me of another thing I've been thinking of lately: it is kind of interesting that there are no concepts in the Semantic Web to define encapsulation boundaries the way you can with most OOP languages. Of course we have different namespaces but that's not really the same thing. In fact even with the namespaces, in OWL, they don't have the basic encapsulation that packages in Lisp or imports in Python do. With both of those you can decide which specific functions, variables, etc. to import and it is usually considered poor design to just import an entire package in Lisp or library in Python. Of course even that is a very minimal kind of encapsulation because the people who "own" the package or library don't decide what is public vs. private, they leave it to each user. So there is no contract as you get with public/private methods or IDLs where the owner can tell the users "these interfaces should remain stable so if you use them you'll be insulated from most future changes". 

 

But getting back to OWL there's nothing at all I'm aware of to define encapsulation boundaries. As I think about it, that seems to be a major difference between the AI knowledge representation community and the mostly software engineering OOP community. Encapsulation has always been a major design goal for OOP but most knowledge representation languages e.g., Knowledge Engineering Environment (KEE) or Loom to pick two I used a lot in the past, never seemed to even consider encapsulation. I've always wondered if that was more due to the different communities or that the goals of explicit knowledge representation are different from OOP which was primarily designed to support reuse in large systems. I've been looking at named sub-graphs in SPARQL as one possible way to define encapsulation boundaries since an entity can belong to more than one sub-graph. So you could have two subgraphs for a domain, where one is public and the other private. Or another way is just to use some language like GraphQL to define interfaces to your knowledge graph and if it doesn't have a GraphQL (or REST, or gRPC) interface then it is considered private. 

 

Curious what you think about that. Thanks for the info.

 

Michael

https://www.michaeldebellis.com/blog

 

On Thu, May 7, 2026 at 6:58 PM hpolzer via ontolog-forum <ontolo...@googlegroups.com> wrote:

Michael,

 

We developed the SCOPE (Systems of systems, Capabilities, Operations, Programs, and Enterprises) model for precisely the reasons you outlined below. Every enterprise has scope and that scope is distinct from and informs/constrains the scope of the constituent elements of the enterprise. However, the enterprise elements have scope that is usually a lot more detailed, or if you prefer, finer grained, than that of the overall enterprise. The scope of the enterprise elements also overlap each other, but the data models supporting the operations of these elements often serve different purposes and thus require different data elements/values for the things being modeled. Importantly, an enterprise operates in a larger sea of other enterprises, many of which are customers, suppliers, regulators, or demand-chain partners of the enterprise, all of whom have their own scope boundaries, both internally among their constituent elements and with respect to external entities with which they interact. Lastly, all these enterprises evolve their scope boundaries at different rates along different scope dimensions and establish, alter,  and break relationships with other enterprises as these scope boundaries and associated operational contexts evolve. So do the data models supporting the respective enterprise operations in that evolving ecosystem.

 

Note also, that operational contexts have scope boundaries with similar characteristics as well, typically involving a number of enterprises and their operational contexts and scope boundaries. And each enterprise or enterprise element has specific perspectives on those operational contexts that differ from each other in potentially important ways. Different aspects (i.e., scope dimensions and associated attribute values) of operational contexts have different levels of importance or significance to the enterprises sharing some operational context(s). That, in turn results in data model differences for describing the operational contexts they share.

 

Identifiers for entities and concepts captured in data models is key to interoperability among all these data models and being able to manage their evolution in a pragmatic way. But one also has to recognize that identifiers are not universal and  that the same item or concept may have different identifiers in different  operational contexts (including enterprise contexts). That’s why most of us have several email addresses, a multiplicity of userids, handles, government ids, etc., not to mention all the things we buy or deal with.

 

In short, drawing boundaries around an enterprise and developing a single integrated data model has very limited benefits, especially when viewed from an evolving enterprise and enterprise environment perspective. Understanding and being explicit about our scope boundaries and considering how they are likely to evolve and in which directions, and how they are perceived by those we interact with is key to managing our data models.

 

Hans

 

From: ontolo...@googlegroups.com <ontolo...@googlegroups.com> On Behalf Of Michael DeBellis
Sent: Thursday, May 7, 2026 12:43 PM
To: ontolog-forum <ontolo...@googlegroups.com>
Subject: [ontolog-forum] The Dream of an Enterprise Data Model

 

I've been studying Domain Driven Design (DDD) which is the most common method that the people I respect the most in modern IT like Martin Fowler, Eric Evans, and Zhamak Dehgani use for designing Microservices and Data Products (a Data Product is a relatively new idea that applies the same concepts used for Microservices to data). 

 

I want to test my memory because its been a long time since I had anything to do with COBOL. I want to say something like: 

 

 "For decades, enterprise data management has been seeking the holy grail of a single integrated enterprise data model. This dream goes back at least to mainframe-era data dictionaries, COBOL copybooks, corporate data models, and later metadata repositories and CASE tools. Industry leaders like Evans, Dehgani and Fowler have realized that the problem is not simply that this goal of one integrated enterprise data model is difficult to realize. Rather, the problem is that for most large organizations, it is the wrong model! Enterprises do not have one language, one context, or one stable model that is applicable across the entire enterprise. The proper way to create a usable Enterprise Data Model is to have a minimal common model and then find the appropriate domain boundaries (called Bounded Contexts in DDD) that have their own detailed domain models. As with microservices these boundaries typically align with business units. The shopping cart, finance, authorization, marketing, and shipping groups each have the concept of a Customer but the details of what they mean by that and other concepts varies significantly.   Dehgani uses the term polysemefor concepts such as Customer or Account that appear to be shared across the enterprise but whose meaning varies across domains."

 

Curious if anyone has any feedback. Both on my memory of how people use the enterprise data model concept and the idea that one single enterprise model is an anti-pattern. 

 

Michael

https://www.michaeldebellis.com/blog

 

 

-- 
All contributions to this forum are covered by an open-source license.
For information about the wiki, the license, and how to subscribe or 
unsubscribe to the forum, see http://ontologforum.org/info
--- 
You received this message because you are subscribed to the Google Groups "ontolog-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ontolog-foru...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/21f643dc-d0a3-449c-86d7-2071e41e850cn%40googlegroups.com.

-- 
All contributions to this forum are covered by an open-source license.
For information about the wiki, the license, and how to subscribe or 
unsubscribe to the forum, see http://ontologforum.org/info
--- 
You received this message because you are subscribed to a topic in the Google Groups "ontolog-forum" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ontolog-forum/rMl4ivEipq0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ontolog-foru...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/07f701dcde8e%24288920b0%24799b6210%24%40verizon.net.

-- 
All contributions to this forum are covered by an open-source license.
For information about the wiki, the license, and how to subscribe or 
unsubscribe to the forum, see http://ontologforum.org/info
--- 
You received this message because you are subscribed to the Google Groups "ontolog-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ontolog-foru...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/CALGFike1Z8wTT27GwqZMpXuTkLRraSc0i2-7PcP_xLKYk%2B6FaQ%40mail.gmail.com.

-- 
All contributions to this forum are covered by an open-source license.
For information about the wiki, the license, and how to subscribe or 
unsubscribe to the forum, see http://ontologforum.org/info
--- 
You received this message because you are subscribed to a topic in the Google Groups "ontolog-forum" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ontolog-forum/rMl4ivEipq0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ontolog-foru...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/017e01dcdef7%24b53e4e40%241fbaeac0%24%40verizon.net.

-- 
All contributions to this forum are covered by an open-source license.
For information about the wiki, the license, and how to subscribe or 
unsubscribe to the forum, see http://ontologforum.org/info
--- 
You received this message because you are subscribed to the Google Groups "ontolog-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ontolog-foru...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/CALGFikea0V32-H3M%2BrH6Ooydg_cptdqt7reyHEmRCVg8WU_-_Q%40mail.gmail.com.

-- 
All contributions to this forum are covered by an open-source license.
For information about the wiki, the license, and how to subscribe or 
unsubscribe to the forum, see http://ontologforum.org/info
--- 
You received this message because you are subscribed to the Google Groups "ontolog-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ontolog-foru...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/2f0b6ae0-6b0e-48b9-a5a4-d33ec05ce84bn%40googlegroups.com.

-- 
All contributions to this forum are covered by an open-source license.
For information about the wiki, the license, and how to subscribe or 
unsubscribe to the forum, see http://ontologforum.org/info
--- 
You received this message because you are subscribed to the Google Groups "ontolog-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ontolog-foru...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/e0967a55-1461-463c-953b-8074e8ea1754%40sbcglobal.net.

 

Reply all
Reply to author
Forward
0 new messages