The Dream of an Enterprise Data Model

[Michael DeBellis]

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 polyseme for 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

[hpo...@verizon.net]

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

--
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.

[Alex Shkotin]

Michael,

This reminded me of two crucial ways of thinking: abstraction and concretization. The enterprise model as a whole exists, at least among management and their departments, and it is necessarily abstract—abstracted from irrelevant details at this level.

The enterprise manager's terminology is harmonized (as Gary Berg-Cross would say) with that of the department head, and the latter's terminology is harmonized with that of the employees, right down to the operators who work with the information system or clients.

Thus, we have a system of consistent models within the enterprise.

It can certainly be integrated, but fortunately, it's not necessary. Well-established interfaces are sufficient.

Alex

чт, 7 мая 2026 г. в 19:42, Michael DeBellis <mdebe...@gmail.com>:

[Michael DeBellis]

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

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.

[Michael DeBellis]

Alex, yes that's definitely a similar idea as Domain Driven Design. The one idea from DDD I really like is something called a Context Map. With a Context Map Relationship you go beyond the basics of public or private. Instead you explicitly define patterns for sharing microservices or data products. There are predefined types of Context Relationships and they have a direction.

Michael

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/CAFxxROTVEvjJPyb4ecW34-dVsqyq73WugZ8n84%3DZgnwZw1J18g%40mail.gmail.com.

[hpo...@verizon.net]

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.

To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/CALGFike1Z8wTT27GwqZMpXuTkLRraSc0i2-7PcP_xLKYk%2B6FaQ%40mail.gmail.com.

[Michael DeBellis]

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 

To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/017e01dcdef7%24b53e4e40%241fbaeac0%24%40verizon.net.

[hpo...@verizon.net]

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.

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

[Paul Tyson]

+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
------------------------------------------

To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/2f0b6ae0-6b0e-48b9-a5a4-d33ec05ce84bn%40googlegroups.com.

[hpo...@verizon.net]

Agreed. “Best practices” carry a lot of implicit context scope assumptions with them, many of which may not really apply to a given enterprise, in a given environment. That’s why I wrote: “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” in my earlier email.

Also, I would quibble a bit with saying “it’s an architecture, not a code problem”. Architecture is just another way of saying “organizing principle(s)” or “patterns” – which we also find in code. Also, high level architecture decisions can have significant impacts on code, and code can constrain architecture, especially due to embedded scope assumptions.

To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/e0967a55-1461-463c-953b-8074e8ea1754%40sbcglobal.net.

[Igor Toujilov]

Michael,

Encapsulation was introduced in imperative (another word,
“procedural”) programming languages to cope with the destructive
assignment which is the main source of bugs. So, the purpose is to
separate interfaces from implementations having destructive assignment
or side effects. This increases software reliability, maintainability
and so on.

OWL, SWRL and some other languages are not imperative. They have no
destructive assignments. So, there is no point to apply encapsulation
to them. Those languages are called purely functional.

There is a similar concept – modularity which is more widely useful,
including in ontologies, for the scope separation. You can have
ontology modules through the OWL import mechanism.

Igor

> To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/CALGFike1Z8wTT27GwqZMpXuTkLRraSc0i2-7PcP_xLKYk%2B6FaQ%40mail.gmail.com.