It looks like you have a pretty good handle on your problem, and either of those two will work. There is a third option you can include in your considerations, and that is to represent each party’s role independently on the ledger. So rather than having a single DevRole contract and a single ManagerRole contract each with a set of parties, instead you have DevRole and ManagementRole templates and create a single instance per party when/while each party is assigned that role. The downside of this approach is visibility, you will need an alternative means of informing employees of who has what roles, as keeping observer lists consistent across that many contracts is a problem. That being said, as these contracts are going to have to be maintained by the entitlement system, presumably represented as its own party, this may not be an issue.
A few other random thoughts on this question:
- Keep an eye out for contention. With any solution that uses a centralised contract, updating that contract will cause fetch/archive contention with any use of that contract in other workflows. This can have serious performance impacts if/when this occurs.
- Sometimes it is worth considering using a constellation of contracts instead of a single contract. Here, what is conceptually one contract (the single role contract you mention as 2), is accompanied by a number of subsidiary contracts that are maintained as projections of the primary contract. This would be a way to combine the visibility advantages of a unified per-role contract, with the contention properties of individual per-party contracts.