I have used LSP for software architecture development as well as for some related IT problems.
What works well is to use LSP for building risks, non-functional-requirement-drivers (architecture goals), users (end-users and architecture-users) as well as metaphors for core principles and building-blocks of the architecture. All of these can be assembled as landscapes or shared models to clarify and communicate the underlying intend and trade-offs of an architecture. As with all LSP workshop, I usually start at the end and try to picture what aspects would be important to represent in the landscape that the participants will be building. Then I try to figure out in which steps that landscape could be realized, in order for the participants to have useful conversations and insights whilst on their way.
In that sense it’s not about finding the concrete solution but about finding out what is important, what is not and how a good solution would feel like. Just like the LSP standard applications are not about concrete results or agreement but about the participant discovering how they can act with shared intent towards a common goal.
To finish off, the usual warning: LSP is not about modeling the real world solutions and in particular with software (architecture) you probably find, that there are a number of better options available for that. Whilst „finding holes in an architecture“ and „negotiating solutions“ may be important goals within your context, LSP is probably not a good fit for that.
Become a LEGO Serious Play facilitator - check one of the upcoming training events!