Handle version history without overloading Application factsheets

We have FactSheet for each Application and separate Application/SubType for each instancies.

Mostly for  Application subtypes does not includes i calculations of applications for LeanIX licens

• Application “Orbit - Operation Planing”
  • Application Orbit/Instans “Hospital 1”
  • Application Orbit/Instans “Hospital 2”

Hello @Lusheez ,

we are using the version on the relation entity:
 

It is not possible to use it as a filter for and display in inventory/reports, but I summited an idea for that. We are getting certain data with graphql, it enables filtering & extracting data.
Best regards,
Carsten

Hi all,

Sorry me again… the best practices (below) has confused me.  I was under the impression that deployment could only be used for environment e.g. dev, uat, system test etc. not for different versions of the same logical application. 

• Does this mean that multiple versions of the same logical application, (e.g. App A v33P3, App A v33P4, App A v32P1 etc.), should be implemented as IT components and not as applications with a subtype of deployment?  If so, how do I implement them as IT components and still track all the dependencies, technical debt, risk sign off?  Can you provide a working example for me please?

OR

• Because we wanting to track different technical dependencies, (IT component usage), and technical debt, (of the IT components in use), and risk sign off for the deployed locations, we fall within the second bullet point below and can implement the multiple versions of the same logical application as an application with a subtype of deployment? 

Advanced: How to model deployments

Modeling instances or deployments is not a frequent use case, but if your organization needs to model such cases, the general recommendation to do so in LeanIX is to follow a light-weight approach and model relevant instances or deployments as IT Components (see modeling guidelines for IT Components).

There are two scenarios where we recommend modeling Deployments on the level of Applications by using the Deployment Fact Sheet subtype:

• In the case of an automatic import from a CMDB. Concretely, the ServiceNow CSDM best practice establishes that "Application Services" are mapped to Deployments in LeanIX.
• In case you want to track different technical dependencies & risks for the instances.

We had something similar to this and it really depends on what the application is used for. 

     For some of the versions that vary greatly from each other, we found having one parent Application factsheet that has children factsheet for the different versions worked best. For the shared fields, you could use the parent factsheet to keep them updated rather than updating each of the child factsheets. 

     For versions that were still used for the same task, we found the IT Components to be a better option. Since the apps functionality itself stays the same through the different versions, we didn’t see a need to make more Application factsheets. Once again, if you are worried about the shared fields, having that parent IT Component is a great way to store all that data. 

I hope this helps, 

Drew :) 

Hey @andreh, 

     The shared fields are fields that will stay the same throughout versions. Things like the overall description of the application, the criticality of the application and the departments that use this application could stay the same despite the different versions. Instead of adding these details to each version of the application, the parent application can hold all the general information to give an overview of all the versions. For example, something like Team Desktop, Mobile and Online all serve the same purpose. While things like the technical fit may differ for each, most of the information will remain the same. 

     The different fact sheet types depend on the scale of the versions. When there are big differences between the versions, each version can almost be seen as its own application. Since there is a limit on the number of applications we can have, for version differences with little to no changes, we can’t justify the use of an application fact sheet. 

     As for the reporting, this can be a little confusing. My recommendation would be to use tagging. If you tag the IT Components, say a tag called “Version”, we can filter these out in reports. Since the IT Components are for the versions with little changes, seeing them in the application reports is not as important, as they are all linked to one general application fact sheet.

I hope this helps, 

Drew :)

The aspect of versioning in LeanIX indeed brings up an interesting discussion and has seen various enlightening inputs. 
At LeanIX, we try to give a strong guidance to users who are not familiar with EA yet and that’s what we encoded in our documentation as cited by @AndiW. 
 

Let me summarize the track a bit for more mature practices:

To handle tracked versions of an application that are installed in parallel and around different geographical sites, there seem to be a few options on the table:

1. Using Deployments for Specific Version per site of an Application: As suggested by @andreh, deployments, being children of one logical application, can be used to model a specific version per site of an Application. However, detailed factors such as version and lifecycle would need a manual update post-creation of the deployment. Similarly, as @Steen Jensen highlighted, one could consider using Application subtypes to handle each version of an Application. Keep in mind, that LeanIX has a strict policy about the usage of deployments and will intervene if you deviate from the intended purpose of deployments with that subtype.

2. Using IT Components for Different Versions: Both @Helder.Luz  and @Drewbertlemon mentioned using IT components for different versions for non-SaaS Applications, and the version variations are not significant enough to treat them as separate Applications. This is our standard proposal and also reflects the nature of Software dependencies, with versions modelled as IT Components vs. Applications delivering a specific business value that are agnostic to the underlying technologies.

3. Using Parent-Child Relations: This was proposed by @Drewbertlemon for situations where versions vary greatly or when an Application is used for the same task across different versions. By creating a parent Application with children Applications for each version, you can keep the shared fields (the description, the application owner, etc.) updated on a single fact sheet, encouraging better organization and efficiency. You will have to work around LeanIX not providing an inheritance mechanism, though.

It's worth emphasizing that the implementation of either option is highly case-dependent and may require iterations and adjustments as you navigate through the implementation.

Remember, the aim is to facilitate an efficient flow of information that aids business decisions rather than create informational redundancy or confusion. Always center your choices around the specific needs of your enterprise, considering factors like scale, the degree of version differences, etc.

Hey @andreh 

     I know you asked @Felix Hoffmann, but I have a bit of insight on this. First, in our onboarding process, we were told that the requires field is mainly for IT Components. From what I understand, the requires field would be appropriate to use in your situation. 

     For the components related, I would say that the IT Components in the “for TRM” circle should be related to the versions, but I would highly recommend adding in categories for the IT Component fact sheets. This can be changed in the configuration of the fact sheet under category.

     As for the question about relating it back to the application, I believe this depends on you and what data you want to see. If you want to be able to see what applications are using what OS and DBs, it would be easier to see if you attached them back to the application. I know it is possible to drill down into components from applications in reports, but I believe it is only the first tier. If you wanted to see everything, the direct relation from the IT Components to the application might work best.

Hopefully this can help in some way.

Drew :)

We have a very similar situation in which there might exist multiple independent deployments of the same application in different organization units. For a couple of days now, I’m trying to wrap my mind around the pros and cons of modeling it using

• the deployments-as-application-subtype approach (i) versus
• the deployments-as-IT-components approach (ii).

I have to agree to @andreh’s comment that I can’t see an issue with (i) except that it somehow doesn’t feel correct. By that I mean that neither the concept of an application nor the concept of an IT component feels appropriate to subsume application deployments. So, (ii) doesn’t feel correct either. What is more, to me, an IT component is the complement of an application: the set of applications versus the set of IT components that may exist within an organization are disjoint, and together they span the set of IT assets (i.e. all kinds of hard- and software) within some organization. According to this understanding, an IT asset is either an application or an IT component. Of course, one can broaden the definition of an IT component to include applications (and there are reasons to do so). But then I would like to ask why the concept of an application became a top-level type in LeanIX’ meta model in the first place, rather than just having IT component alone as a top-level type and application being a sub type of it?

Anyway, I want to add another aspect to the discussion: The strongest disadvantage I see in (i) is really just the fact that each deployment will increase the license-relevant application counter (because it is an application). Whereas, if we would model them as IT components it would not; though it would be subject to the fair-use ratio of 1:10. As such my posting is also a request towards LeaIX to consider changing the licensing model in a way that would make (i) and (ii) equal in this regard. More clearly, no matter if someone, for whatever reasons, decides he/she wants to use (i) in favor of (ii), or the other way around, it should have no impact on the application license counter: Application deployments should not count as applications, no matter if someone wants to use (i) or (ii).

If you use the concept of Application type Deployment, then is will not incur extra Application count towards LeanIX licensing

Thanks for the pointer. I wasn’t aware of that. Great to see that someone seemed to have the same thought and actually acted in the same direction.