Hi Beau,

We have used TIME extensively, however implementing it in LeanIX is/was not straight forward. (let me explain...)

1. The TIME value is a combination of Functional Fit vs Technical Fit. 
   On the Application Fact Sheet, we had to make the TIME value read only, and implement 18 automated tasks (triggered by either a Functional Fit value changing, and a Technical Fit changing) gthe LeanIX support article on how to do this forgot to include if a value gets cleared from Functions/Technical Fit (hence the extra two).

2. When setting the relationship between an Application Fact Sheet and an Organisation Fact Sheet, you have the option to select the Functional Fit on that relationship, however you cannot get a TIME value for this relationship in any of the reports.
   
   e.g. Say you have an Application (‘XYZ App’).  In the Application Fact Sheet it shows as ‘Invest’, because on the Application Fact Sheet you marked the Technical Fit & Functional Fit as ‘Fully Appropriate’ & ‘Perfect’. 
   
   Now the Technical Fit is set in the Application Fact Sheet (and the rating should not change).  If I set an Organisation usage relation (in the Application Fact Sheet) to say ‘Europe’ with a ‘Function Fit’ as ‘Insufficient’, then I would like to see that ‘new’ TIME rating on a report. 
   
   Which is the combination/formula of the Application’s Technical Fit & the Functional Fit relationship attribute to the Organisation.
   
   Having a global footprint, we have a lot of Applications that the Functional Fit varies per region.
   
   The end goal is to have an Application Landscape report (So TIME color coding of Applications by Business Capability) however, per region (Organisation).  
   
   The closest we can do right now (that we know of) is Application by Organisation, and show the color coding as:
    

And then show the Technical fit on one of the properties. (see below:)

Not ideal, and not the Red, Yellow, Amber, Green report for TIME :(
 

Question 1 (For LeanIX): TIME is a ‘formula’ based on the Technical Fit & Functional Fit (either on Application, or the relation to Organisation).
Is the creation of a calculated field for TIME in the future Roadmap? (i.e. Application ‘TIME calculated’ value, and then also on the relation to Organisation Fact Sheet, ‘Organisations: TIME calculated’, in the Application Fact Sheet)

Question 2 (for the community): How are other organisations assessing TIME across their organisation with different Functional Fits per region/team/business unit ?

@Jacques Wow! This is a great reply. I am looking to find out more internally regarding TIME based calculations and will update you when I hear more. 

Thank you for this impressive write up!

Adding to the great reply from @Jacques  above, to calculate a TIME value for an Organisation relation, one could:

1. Define a new single select field in the relation between Applications and Organisations (using the Meta Model Configuration admin screen) to hold the TIME rating. Make it non-modifiable so that people don’t update it directly)
2. Use Webhooks to capture the FACT_SHEET_UPDATED events for Applications and the the RELATION_CREATED/RELATION_UPDATED events between Application and Organisation fact sheets.
3. Use an Azure Function or some other HTTPS reachable code to perform the required calculations and update the fields using the GraphQL APIs. There is an old example of using a Webhook function to create a tag from Functional Fit and Technical Fit here that may be useful as an example.

LeanIX Customer Success Manager can provide guidance if required.

Then just use the new relation field in reports. 

Cheers,

We have also utilize the TIME field however; we deviated from the assessment as a calculation of technical and functional fit.

Our issue with a straight calculation is that it doesn’t consider other factors that would influence an assessment.  We may love the product, the fit is good but there is room for improvement, but that improvement comes at a cost (time, resources\capacity, or money) that we are unwilling to spend, so we will assess it differently than a straight calculation would allow.  For us Salesforce is a great example of this, we like the platform and early experiences have been good but we are wary of the vendor lock-in and costs of placing too much on the platform.  So while functional and technical fit are good, we do not rate it as invest.  Instead we have it as tolerate until we make a decision to adopt it, or it remains a niche platform for us.

Some people may argue that those factors can\should be built into either the functional or technical fit.  That’s a great point and we could, and maybe will, do that in the future.  Currently we are keeping some of those factors outside of functional and technical fit.

@DaveT - Interesting.  We have though along those same lines, and our thinking was to rate the Application with a Technical Fit as ‘Fully Appropriate’, and Functional Fit as ‘Insufficient’, which means it will be ‘Tolerate’. (Vendor lock in concerns could go under Technical or Functional Fit? One will push it into Migrate, the other into Tolerate)
Then (on the Application Factsheet) when setting the usage relationship to the Organisation factsheet there is a Functional Fit we can put as ‘Appropriate’. 

This will result in the Application having a ‘Tolerate’, and the usage for an organisation being ‘Invest’.

e.g. ‘Some Application’ will end up with a TIME on the Application factsheet as ‘Tolerate’.  However, for the usage relationship on the organisation (say ‘Europe’) Functional Fit attribute would be set to ‘Insufficient’, resulting in a ‘Invest’ (for Europe’s niche usage) (But this bit is ‘broken’ in LeanIX: it only shows the Functional Fit for the relationship - not TIME for the relationship.  @Beau Nelson - any updates?)

That’s exactly how I could see it working if we were to build some of the other factors into technical or functional fit.  In your organization who is accountable for the functional and technical fit?  Is the TIME assessment also the same people?  At this stage we’re trying to get LeanIX adoption expanded beyond the technical community so we’re keeping the TIME assessment reserved for the business owners to assess.

@Beau Nelson after using the T.I.M.E analysis method for 5 year roadmap planning against the global and business unit applications landscape we have noticed 2 major problems with using it the way LeanIX suggests:

Firstly - The calculation of the TIME value based on subjective answers to fixed questions is flawed pseudo-logic. Best just to get a subjective answer from the application/business owners in the first place and challenge if required. The “default” should be Tolerate (keep safe/stable), so just get them to focus on where something needs to change.

Secondly - The TIME analysis needs to be multi-year, as what is Tolerate for a year or two could be Eliminate in the future. We used additional TIME analysis fields for future years and noticed the need for a “not applicable” and “already eliminated” to get reporting to make sense.

I think keeping it simple and understandable is the key and you have to model your organisations and applications appropriately for the question you are trying to answer.

@Justin Swift agreed.  One other issue with the strict calculation is how target maturity fits in.  We may assess functional and technical fit as very high and it is meeting our target for that application.  Using a strict calculation it would result in an Invest assessment, yet we have no need or desire so would assess it as Tolerate.  We’d need to artificially downplay the fit, so we are comfortable not utilizing a matrix to determine TIME assessment and instead prefer a more nuanced conversation.