Simplifying the metamodel
I am interested in understanding how the meta model can be modified to make it simpler to apply and more likely understandable and easier to adopt for a low maturity organisation that currently feels more comfortable to maintain some architecture portfolio info using spreadsheets. And if the meta model can be simplified, how can the existing reports be modified / maintained so that you can for example have a view for all applications related to a business domain and its functions, without the need to specify application services as the linkage between the business and application layer?
-
colinfrewen
- Posts: 67
- Joined: 10 Dec 2013, 01:22
- Location: Australia
Hi,
Our approach to this has been to identify key views where the full conceptual to physical design would be impacted by lack of data or maturity. An example would be where we needed physical process, function and service across all applications, logical tech linkages etc. We then defined around a 100 views where we need to create extra slots or use taxonomy terms / add to the enumerations.
Our rules we follow are:
1) Extra slot cannot remove an existing linkage
2) We simplify on custom reports only.
3) When we have a complete modelling scenario we revert to core (although we have customized around 200 reports)
4) We focus on key information areas. (Sap downloads, aris downloads, etc)
Example Reports:
As you can see the reports are mostly based on view overlays on our complex capability model.
Regards
Our approach to this has been to identify key views where the full conceptual to physical design would be impacted by lack of data or maturity. An example would be where we needed physical process, function and service across all applications, logical tech linkages etc. We then defined around a 100 views where we need to create extra slots or use taxonomy terms / add to the enumerations.
Our rules we follow are:
1) Extra slot cannot remove an existing linkage
2) We simplify on custom reports only.
3) When we have a complete modelling scenario we revert to core (although we have customized around 200 reports)
4) We focus on key information areas. (Sap downloads, aris downloads, etc)
Example Reports:
As you can see the reports are mostly based on view overlays on our complex capability model.
Regards
You do not have the required permissions to view the files attached to this post.
Thanks for the reply. It confirms that the sensible thing is to maintain the core and add classes, modify forms and reports to present the info that fits the maturity and also the terms that the organisation is comfortable with. Btw, very impressive reports that you've provided as examples!
For anyone else who may have the same question, here's links to tutorials that I found on another post:
Modifying the meta model
• Creating new classes
• Adding new attributes to a class
Creating or modifying forms and reports
• Customising forms
• Creating or editing reports
Source: discussion board - meta model extensions
For anyone else who may have the same question, here's links to tutorials that I found on another post:
Modifying the meta model
• Creating new classes
• Adding new attributes to a class
Creating or modifying forms and reports
• Customising forms
• Creating or editing reports
Source: discussion board - meta model extensions
-
colinfrewen
- Posts: 67
- Joined: 10 Dec 2013, 01:22
- Location: Australia
Hi,
There is always impact if any library's change so the advice would be to maintain a section with css / js links within the user folder. We do not modify any of the core. But as an institution with over 5000 applications and 30 organisations the core structures don't work. You can achieve scale with clever filters (we use a combination of js and simple filter classes for this.
The reports all have a similar structure and we insert (sometimes hidden) the same filters / dropdowns template calls as a reference in all the reports. Our standard view is a combination of overlays on an anchor model, which is not done well in some of the older models in essential. Some of the newer ones are great but typically don't have a single focus to apply multiple events over.
We moved to bootstrap 4 a while ago and we tend to stay on Trend although we have had multiple direct edit upload forms for years. Too your point, at the core, this is a very very good platform but like most things needs some real life experiences to help understand how best to use.
Regards
There is always impact if any library's change so the advice would be to maintain a section with css / js links within the user folder. We do not modify any of the core. But as an institution with over 5000 applications and 30 organisations the core structures don't work. You can achieve scale with clever filters (we use a combination of js and simple filter classes for this.
The reports all have a similar structure and we insert (sometimes hidden) the same filters / dropdowns template calls as a reference in all the reports. Our standard view is a combination of overlays on an anchor model, which is not done well in some of the older models in essential. Some of the newer ones are great but typically don't have a single focus to apply multiple events over.
We moved to bootstrap 4 a while ago and we tend to stay on Trend although we have had multiple direct edit upload forms for years. Too your point, at the core, this is a very very good platform but like most things needs some real life experiences to help understand how best to use.
Regards
Thanks again for your insights, Colin. At this stage I'm doing an initial trial to better understand the tool and its possibilities but also the implications if we go down this track. So definitely useful information and much appreciated.
