Hello,
I´d like to filter within the Application Lifecycle Viewer by Capability.
Therefore I captured an Application Cabability, assigned an Application Service to it and entered three Applications in "provided By Application".
For each Application I added a Lifecycle Model and entered the Lifecycle_Status_Usages.
The Lifecycles are shown in the viewer, but I can´t filter by Capability.
It seems to me as if I have to capture more data.
Unfortunately, there is no further explanation available for this in the essential university.
https://enterprise-architecture.org/uni ... lifecycle/
When trying to sort this out, I realised that there are two ways of linking applications to a service: 1. directly and 2. as a relationship. What is the difference here?
I´m currently using the open source version with Protege.
Thanks in advance.
Sven
Data Capture for Application Lifecycle Viewer
Can you confirm it is this view: enterprise/core_el_lifecycle_viewer.xsl
It will almost certainly be via the physical process. The difference is you have a Business Process that supports a business capability and has an implementation in the organisation that uses applications. If you know exactly what functionality in the application is used, then you map the process via the service(s) used. If you don't know, then you can map to the application directly.
This route is the IS USED route, the application is used by the business
The logical process to service route is a COULD BE USED mapping, so this process needs these services to function and these applications provide those services. The service may not be being used but could be to support that process. We can use this in duplication analysis/rationalisation
Does that help?
It will almost certainly be via the physical process. The difference is you have a Business Process that supports a business capability and has an implementation in the organisation that uses applications. If you know exactly what functionality in the application is used, then you map the process via the service(s) used. If you don't know, then you can map to the application directly.
This route is the IS USED route, the application is used by the business
The logical process to service route is a COULD BE USED mapping, so this process needs these services to function and these applications provide those services. The service may not be being used but could be to support that process. We can use this in duplication analysis/rationalisation
Does that help?
-
sven.kuhnert_ger
- Posts: 6
- Joined: 23 Jun 2023, 14:53
First of all: Thanks for the emidiate reply.
Yes I can confirm, it´s the enterprise/core_el_lifecycle_viewer.xsl, I´m talking about.
I will go through your post and come back to you asap.
br
Yes I can confirm, it´s the enterprise/core_el_lifecycle_viewer.xsl, I´m talking about.
I will go through your post and come back to you asap.
br
-
sven.kuhnert_ger
- Posts: 6
- Joined: 23 Jun 2023, 14:53
All right, that makes it clearer for me, but I'm still not sure what data needs to be captured so that I can filter on the capability in the lifecycle viewer.
Some of the applications I have entered are also assigned to a physical process, but this has no influence on the function in the Lifecycleviewer.
br
Some of the applications I have entered are also assigned to a physical process, but this has no influence on the function in the Lifecycleviewer.
br
Apologies Sven, I've checked the code and it uses the Application Capabilities for mapping the apps.
Application Capability --> Application Service --> Application Provider Role --> Application.
You need the physical process to understand the processes impacted when you click the information icon on an application.
I'll ask the team to make it clearer.
Application Capability --> Application Service --> Application Provider Role --> Application.
You need the physical process to understand the processes impacted when you click the information icon on an application.
I'll ask the team to make it clearer.
