I am very new to the toolset and metamodels. In the past I have used and examined the applicability of the 3LGM2 models (healthcare domain). You may want to take a look: http://www.3lgm2.de/en/index.jsp
Their tool and visualizations are very useful. The enhancements are slow in coming and it does not appear to be quite as flexible as your tool. It is much more engrained in the Information, Application/component (data flows), and physical world.
Thank-you for sharing this toolset
Have you referenced the 3LGM2 models?
-
jonathan.carter
- Posts: 1087
- Joined: 04 Feb 2009, 15:44
Thanks for pointing out the 3LGM2 models.
We haven't referenced those - in fact, personally, I wasn't aware of their work. Looks interesting, though.
From what I can see, as you say, they do include physical models of data heading towards things like database table design.
We've taken a conscious decision to keep the meta model focussed on Enterprise Architecture and have therefore not gone into software component modelling beyond capturing relevant software components as quite coarse-grain instances in the Application Layer. We don't plan to get into Class Models and CASE capabilities that are best managed in, e.g. UML modelling tools. However, we can reference these more detailed models from the software components that are in our model.
Similarly, we approach Information and Data from the EA, rather than a detailed data modelling perspective. So, we wouldn't have ERDs etc. in the model but again, might reference these data models from instances in model. Our physical Information meta classes deal with where physical instances of Information are stored, rather than their detailed database table structure.
We're currently trialling some extensions in the Information Layer that help to understand and manage the Data that supports the Information but again, this is from an architectural perspective (albeit detailed and about understanding logical relationships) and does not venture into table design etc., in line with our approach to software architecture.
Jonathan
We haven't referenced those - in fact, personally, I wasn't aware of their work. Looks interesting, though.
From what I can see, as you say, they do include physical models of data heading towards things like database table design.
We've taken a conscious decision to keep the meta model focussed on Enterprise Architecture and have therefore not gone into software component modelling beyond capturing relevant software components as quite coarse-grain instances in the Application Layer. We don't plan to get into Class Models and CASE capabilities that are best managed in, e.g. UML modelling tools. However, we can reference these more detailed models from the software components that are in our model.
Similarly, we approach Information and Data from the EA, rather than a detailed data modelling perspective. So, we wouldn't have ERDs etc. in the model but again, might reference these data models from instances in model. Our physical Information meta classes deal with where physical instances of Information are stored, rather than their detailed database table structure.
We're currently trialling some extensions in the Information Layer that help to understand and manage the Data that supports the Information but again, this is from an architectural perspective (albeit detailed and about understanding logical relationships) and does not venture into table design etc., in line with our approach to software architecture.
Jonathan
Essential Project Team
