Hi Roberto,

Not sure what type of relation you would like to add to another app, but I wondered if the use of the “Interface” fact sheet type might be something useful for you to use, as this would indicate a Providing app is sending something to the Consuming app.

Apologies if this isn’t the type of relationship you were thinking of… perhaps you could expand on the specific use case to help frame the problem?

Thanks

Mike

Hi Mike,

my company is doing a lot of M&A’s.

Our approach is to import in LeanIX whatever set of applications we inherit from the company we are acquiring / merging with and map those apps against our BCM to highlight overlaps with our apps. Since we buy companies in the same sector as us, most of our M&A targets use applications that largely overlap with ours. Meaning not only they support the same capabilities, but they are the same COTS package (maybe different edition / version).

So, when I add an app to the inventory that is used by a M&A target, and this app is the same as an app we already have (say SAP 4 HANA), I’d like to add to the new app a reference to the fact sheet that represents the same app that is already in the inventory. Obviously in these cases the new app is transient, since sooner or later the users and data will migrate and we’ll have a single instance.

Now I am wondering if perhaps I should user groups to deal with this use case (i.e. a single app fact sheet associated to 2 user groups, one for the parent company and one for the target), although I would prefer to keep the 2 instances separated to track the progress (or lack thereof) of the migration and retirement.

Does this help?

Thanks!

Roberto

Hi Roberto,

Yes, that’s a great help - thanks!  Sounds interesting.

When I’ve done something similar previously incl demergers, I’ve used the “Organisation” with two relationships, one for “Used By” and the other for “Owned By”, but you could choose a better relationship name for your use case.

(I don’t like having Locations and Organisations as the same single fact sheet as User Group, so we have two separate fact sheet types for this - Locations and Organisations…  but you could achieve the same with the User Group fact sheet type.)

Thank you Mike,

You had me scramble to check the model for Org and Location fact sheets until I read you 2nd paragraph!

I like the idea of adding an Org fact sheet to represent legal entities. 

I am still thinking that I want to track applications as they migrate / get retired, given, in my experience, tendencies to “forget” about such apps and leaving them hanging around for much longer than needed (if I’m being charitable, I could assume that it’s done to provide nice “low hanging fruits” for the next generation of enterprise archs  ).

So, in sum, I’d still like to have the ability to add a “to be replaced by” app-to-app relation. Could this be a kind of “successor”?

Roberto

Roberto,

I understand it is by design that you cannot create a new relationship to the factsheet you are configuring. However in the use case you describe regarding M&A’s it is sensible to keep separate application records for them.

The only relationships I have seen that can relate to the same factsheet type is the Requires and Required By ones present in the dependencies section. If not already used for another purpose you could store that relationship between applications there, and “translate” the relationship name and help text to something appropriate for your needs. Hope this helps give an alternative solution to your needs.

Justin.

Thanks Justin,

It looks like Requires / Required By do not allow to link to other applications. But Parent / Children and Predecessor / Successor allow for that so I guess I could overload those relationships.

More to think about!

A possible practical way is to use the Successor relationship, specially because you want to indicate that App A is intended to be replaced by App B. You could even use Successor relationship to “plan” your migration using appropriate lifecycle dates.

I may end up doing exactly this - could use the description to distinguish different (potentially) predecessor/successor relationships. Although I’d prefer a more structured way than a free text field for distinguishing relationships (a single selection field would be preferable in my mind)

Thanks Helder