I really appreciate the agnosticism and flexibility in this definition. I'm curious to see how you approach the intersection of descriptive and normative modeling, i.e. the process of a) modeling what currently is, and b) modeling what could or should be.
I've been thinking about it recently in terms of building semantic systems, which is a close cousin, or maybe right-hand/left-hand kind of relationship. Different ground rules and constraints, but a similar process, perhaps.
Observe: make an honest and complete assessment of all the data sources, intermediate and final destinations, with good attention to the details and provenance of the sources and the capabilities needed at the consuming end.
Investigate: fill in the details of the components and their connections, already keeping an eye out for redundant or unnecessary levels of manipulation or abstraction, as well as traps like duplicate data and asynchrony. Also note which parts of the process are legitimately beyond your control vs ones that can be codified and modified by data contracts.
Refine: look again with an eye toward simplifying, identify actual fires and potential failure and choke points. This is an 'expert' stage, because it requires a combination of tech-specific knowledge and a sense of broader system modeling, but it can also both find immediate value opportunities and give the broader visibility needed to support deeper conceptual or structural change.
Design: Use the resulting insight into existing data and its sources, related external systems and desired capabilities to model either a clarified version of the current system or a re-engineered system, potentially with different (and presumably more natural/appropriate/harmonious) architecture and technology.
I know this is sort of an inversion of the Hoberman sequence, but I think starting at the ground level (where data originates) and working outward is a sort of useful humility that can sometimes fix quality issues first and suggest routes for improvement, especially in a scenario where there may be less opportunity or appetite for a top-down redesign.
While it is standard practice to go through the aforementioned 3 phases of modeling you describe here in the relational world, it is worth noting that this is specific to relational modeling. In knowledge graphs there is only the conceptual process phase .
I really appreciate the agnosticism and flexibility in this definition. I'm curious to see how you approach the intersection of descriptive and normative modeling, i.e. the process of a) modeling what currently is, and b) modeling what could or should be.
Very good question. What do you think?
I've been thinking about it recently in terms of building semantic systems, which is a close cousin, or maybe right-hand/left-hand kind of relationship. Different ground rules and constraints, but a similar process, perhaps.
Observe: make an honest and complete assessment of all the data sources, intermediate and final destinations, with good attention to the details and provenance of the sources and the capabilities needed at the consuming end.
Investigate: fill in the details of the components and their connections, already keeping an eye out for redundant or unnecessary levels of manipulation or abstraction, as well as traps like duplicate data and asynchrony. Also note which parts of the process are legitimately beyond your control vs ones that can be codified and modified by data contracts.
Refine: look again with an eye toward simplifying, identify actual fires and potential failure and choke points. This is an 'expert' stage, because it requires a combination of tech-specific knowledge and a sense of broader system modeling, but it can also both find immediate value opportunities and give the broader visibility needed to support deeper conceptual or structural change.
Design: Use the resulting insight into existing data and its sources, related external systems and desired capabilities to model either a clarified version of the current system or a re-engineered system, potentially with different (and presumably more natural/appropriate/harmonious) architecture and technology.
I know this is sort of an inversion of the Hoberman sequence, but I think starting at the ground level (where data originates) and working outward is a sort of useful humility that can sometimes fix quality issues first and suggest routes for improvement, especially in a scenario where there may be less opportunity or appetite for a top-down redesign.
I like this. Happy to chat further
Thanks. Likewise.
While it is standard practice to go through the aforementioned 3 phases of modeling you describe here in the relational world, it is worth noting that this is specific to relational modeling. In knowledge graphs there is only the conceptual process phase .
Very valid point Andrew. Thanks!