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”

Hi @Lusheez,

Adding to what @Steen Jensen just said relating to Application fact sheet subtype of “Deployment” (see caveats / recommendations here: https://docs-eam.leanix.net/docs/application-modeling-guidelines#advanced-how-to-model-deployments, and also read the Antipatterns section on that page)...

As for Versions, I would use separate IT Components for that (one for each version). I imagine this is not for a SaaS Application, so when we talk about different deployed Versions, we are talking about different IT Software versions (code versions). 

Cheers.

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,

We have a similar situation, further complicated by the fact that applications A, B and C are developed by a global development team that is geographically diverse yet deployed to different countries to meet local business needs, including regulatory responsibilities e.g. information custodians/owners etc.

• The development IT components used in the development of the application e.g. development framework, language, UI layer etc. are set by the global development team. 
• The infrastructure IT components used in the hosting of the application and its data e.g. server operating system and database version are set by the consuming business units, within the constraints of the applications technical requirements.  

Can I ask which way you decided to go please? Or would recommend?

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 do tackle the same issue or challange:

We have multiple sites and sites use different version of the same application with different life cycles. I don’t have a perfect solution for this, but some ideas, what we want to test:

1. We want to use Deployments to model a specific version per site of an application
2. Deployments are children of one logical application
3. Our idea is to make use of automation or the API. If an organization (in our case a site) is added to  the generic application, we want to automatically generate a deployment.
4. The version and lifecycle must be added manually afterwards to the deployment
5. We want to reduce the information on a deployments (e.g. no capabilities, processes), maybe business criticality. But not sure if this will work, as sites might use different software for different capabilities and processes

Regarding IT Components: I don’t know how this can help in modelling different versions. This might work, but would also mix up components and applications. But not sure…

Bests

André

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 :) 

Thank you @Drewbertlemon 

For curiosity, what are shared fields or do you mean the same field on a fact sheet which should hold the same information? Ist this a feature LeanIX support can configure?

If you use different Fact Sheet Types for the “same” purpose. Doesn’t this mix things up? How do you which report you need. A version might be an application or a IT component.

Would be great to hear your experience with this approach :)

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 :)

Hi @Drewbertlemon

thanks alot for sharing you insides :)

Bests wishes,

André

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.

Hallo @Felix Hoffmann ,

thank you for summarizing the different approaches, in particular topic 2, emphasizing, that Applications are mainly viewed from a business value perspective. 

So LeanIX recommends to model versions/deployments by using IT Components (Topic 2). I thought about it and from a data model/meta model, it feels okay. Not sure, if there any implications from the built-in reports.

Question: Following the recommendation, how should other IT components be modelled?

If we follow the recommendation, what is the best approach to model other IT components (e.g. OS, DB, HW). Is it best to relate them to the version (Relation: requires) or directly to the application.

Attached a diagram with possible relations from Deployments, Versions to the (Business) Application. Not sure if this works and if this is good practice.

Would be great to hear your thoughts :)

Bests,

André

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 :)

Hey @Drewbertlemon

no worries . I really appreciate your feedback!!!

Actually, after playing a little bit with a configuration I depicted above, I think it will not work. As you said, the reports are limitied to the first tier and it gets very tricky to create reports with just one fact sheet type - even if there are multiple subtypes.

Approach Subtype “Deployment” of Application

I still have the feeling that using deployments as a subtype of Applications works fine, but need to further investigate the reports and the effort to maintain.

The good part is, that you can see all relevant IT components in a landscape for all deployments and it is possible to aggregate to the “logical” app, which is good.

It is also possible to generate roadmap to see the lifecycle of deployments.

So far, I can’t see a issue with using the Deployment Subtype, beside that it doesn’t feel “correct”.

Approach IT Components (Version → Deployment)
By removing the “Application Twin” Layer and directly work with Versions → Deployments, we can see the versions in a risk landscape. I wasn’t able to find a way to generate a report, where we can see the IT components for a version (e.g. OS) but thats okay for now.
With roadmaps it would also be possible to display the lifecycle of IT Components “Deployments”

We can use a “Service” component to mange the licence costs which is related to a System.

So, need to further work on this, but maybe there are some Best Practices I wasn’t able to discover so far :)

Bests,

André

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).

Small note… If you use the concept of Application type Deployment, then is will not incur extra Application count towards LeanIX licensing, provided that you use the new Subtype of Deployment to identify them, plus not use some relations (Business Capabilities, Business Contexts) and that the Deployment has a distinct relation to the Business Application. At least that is how I interpret the guidelines here: https://docs-eam.leanix.net/docs/application-modeling-guidelines#advanced-how-to-model-deployments

Cheers

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.