Hi @Thomas Teglund,

I usually start with this list, and then I adapt it to the context of the company:

• ID of the Decision Record
• What do we need to decide?
• Why do we need to decide?
• What are the options and their advantages and disadvantages?
• Which option was selected?
• What was the reason for selecting this option?
• Who decided?
• How long will the decision be valid, and under what circumstances can it be reconsidered?
• If the decision leads to technical debt: What is the Technical Debt ID?

I do not think that LeanIX really is fit for purpose for ADRs, I think it is better to focus LeanIX efforts on what it is good at and keep the rest out of it, LeanIX will never be the sole documentation platform. Squeezing in ADRs feels almost like trying to squeeze in API documentation, that is better maintained elsewhere 

We link out (using the MarkDown syntax) to the decision record held in SharePoint. 

Hi Thomas,

we do currently also check if we can use leanix for decision records. I think that utilizing LeanIX for this would greatly benefit our decision making and recording process, in particular to “connect the dots”, to understand what decision had an impact on what “factsheet” (system, process...) and record them in a structured way.

At the beginning, we will start with a very simple template (based on Michael Nygard ADR):

• Status (proposed, accepted, rejected,...)
• Context (What is the motivation to have a decision)
• Decision (What is the decision)
• Consequences (What are the consequences, gets better/simpler/more difficulte...)
• Relationship to all other factsheets

Bests

André

Hi Thomas,

There is also a Roadmap item that could help in this space: https://roadmap.leanix.net/c/372-rfc-process-support. Not sure if there is already any preliminary design concept, but it would be great to have something native and not have to stitch something manually (which I have been considering also). Maybe we can all “vote” for that item or to register the use cases each of us would like to see covered?

Cheers

We use ADRs, but have customized them as a specific work item type in azure devops which then can be put on a kanban board, have tags, description, options, consequences, impact, assigned persons to this etc.

ADRs is also about at what height do you document the ADRs, we have bigger decisions (firm wide, IT wide, multiple domain wide, or single domain) in our, but we aspire to get further down in the stack as we go. ADRs that is connected to some type of implementation would probably be best suited coupled with the code, and stored in git as the code moves and decisions are then coupled with that repo.

I see the point of using it in LeanIX, however we usually have multiple ADRs running at the same time, and keeping track of states, who wrote this, discussions about it etc are important context. The kanban board view of tracking this is great, with allowing us to move, at a glance se all ADRs in different states etc. Nothing that LeanIX can do atm. Azure DevOps also keeps track of history, any change is recorded, it is the tool for both developers and architects, where LeanIX is more in the architect toolbelt.

Sorry to be late here; in short, we do use leanIX to keep a “decision record” and we tie that to almost any type of other fact sheet for visibility.  The issue for us is not per se the tool (though we migrated to leanIX from JIRA for ease of use for our architects and wider non-technical users), it’s really all about process and adoption.  Happy to discuss further.

hi…

Interesting thoughts a lot of of people have… I’m struggling with the same, and just started an EA function and need to start capturing the decisions… 

Any experience for the last 5 months since this thread started

/Michael

We currently have the Decision Record as a Jira ticket and/or a confluence page with a template + some PowerBi reports. We link those records into some factsheets. It is working ‘ok’ish’ but the fact that you have to go into 4 tools to get the context is not ideal IMHO. But I am not sure that putting everything in LeanIX is better either.

I have added a field in the lifecycle to indicate the Architecture decision. Of course the full documentation behind it is linked on the resources page as needed.