I want to model not just the applications and infrastructure of our system, but also associated documentation.
For example, if Application A is changed, then documents x.docx and z.xlxs need updated. Application B might also be affected.
I suspect Essential can be used for this, but I'm getting tied up in knots with all the abstraction i.e. application services, roles, application_deployments, etc.
What I'm after is a nice diagram with Application A at the top, and dependencies shown from Application B, x.docx and z.xlxs.
I've trawled through the examples but have not seen any similar cases. If Essential is suitable for this type of modelling, could you point me to, or provide, a simple example, please?
Thanks,
Bradley
Applications and their documentation
-
sarah.smith
- Posts: 56
- Joined: 04 Feb 2009, 15:44
Hi Bradley,
We would usually link off to external documents using the "External Document Link" that is included in each class - this allows you to add the name and url of any documents associated with, for example, an application. This is accessible from the summary view pages.
Would this work for you or are you after a different solution?
Regards
Sarah
We would usually link off to external documents using the "External Document Link" that is included in each class - this allows you to add the name and url of any documents associated with, for example, an application. This is accessible from the summary view pages.
Would this work for you or are you after a different solution?
Regards
Sarah
I'll have a play. Thanks.-
colinfrewen
- Posts: 67
- Joined: 10 Dec 2013, 01:22
- Location: Australia
Hi,
Might be drivel or something useful in here:
For whats its worth, my comments, having gone through a similar exercise.
Firstly: The Application_Provider should be see as a conceptual object. Its not technical and typically described by a local name. Changes against the application occur as a technology change (version upgrade) functionality uplift Functions / Services and or physical process. IE: The usage pattern changes. < Poorly My Views
When you get into modelling an Application, the bulk of the information associated is held at technology class level. (Software, support etc). If you work though all the available slots to describe an Application across 15 classes and around 60 slots you have 90 % of the information required to generate a report on that application.
The goal is to produce a report which describes an application though a life cycle which includes technology events (upgrades, versions etc) as well usage patterns and well as providing detail to the application portfolio framework.
I have moved away from the bulk of external data (integrate with cmdb / bpm / help desk) and we create full reports from the system. Of course you need to add in integration to vendor information sources, support practices, management structures, governance which we do though google sites integration and opentext (any DRM) solution). We have built up the linkage to records management as a construct of the class and instance name to reduce the manual linkage for external data, mostly history which adds no value to the repository.
OK: Many points here but I guess I would close off by saying that I am at the point where I don't think meaningful information should be outside the system.
If you do want to link the data I would suggest: Use the excel import doc. Create a spec for the links as a list download from the repository. Do the link in Excel against the application and import it. You can also create a dependency view at this point. We do this as a taxonomy as applications dependency is generally though multiple classes (same function service, same server, data store) provide you insight on impact across the instances.
I would suggest you build some scenario reports for change impact as well. Scenarios can be built in the Taxonomy to give you a baseline.
Colin
Might be drivel or something useful in here:
For whats its worth, my comments, having gone through a similar exercise.
Firstly: The Application_Provider should be see as a conceptual object. Its not technical and typically described by a local name. Changes against the application occur as a technology change (version upgrade) functionality uplift Functions / Services and or physical process. IE: The usage pattern changes. < Poorly My Views
When you get into modelling an Application, the bulk of the information associated is held at technology class level. (Software, support etc). If you work though all the available slots to describe an Application across 15 classes and around 60 slots you have 90 % of the information required to generate a report on that application.
The goal is to produce a report which describes an application though a life cycle which includes technology events (upgrades, versions etc) as well usage patterns and well as providing detail to the application portfolio framework.
I have moved away from the bulk of external data (integrate with cmdb / bpm / help desk) and we create full reports from the system. Of course you need to add in integration to vendor information sources, support practices, management structures, governance which we do though google sites integration and opentext (any DRM) solution). We have built up the linkage to records management as a construct of the class and instance name to reduce the manual linkage for external data, mostly history which adds no value to the repository.
OK: Many points here but I guess I would close off by saying that I am at the point where I don't think meaningful information should be outside the system.
If you do want to link the data I would suggest: Use the excel import doc. Create a spec for the links as a list download from the repository. Do the link in Excel against the application and import it. You can also create a dependency view at this point. We do this as a taxonomy as applications dependency is generally though multiple classes (same function service, same server, data store) provide you insight on impact across the instances.
I would suggest you build some scenario reports for change impact as well. Scenarios can be built in the Taxonomy to give you a baseline.
Colin
