...
- provide a list of people who are authorized for each function
- understand the Function to be used for each authorization
- understand which use the correct Qualifier (Hold or Issue) is to be used for each Function
Solution 2: Grouping Agents
...
Now, the application can select Resource Groups that look like Organizations and use those for creating Authorizations. As far as anyone is concerned, the application is prompting for a list of Organizations for each Function but using these Organizations as Resources to manage the Authorizations. When the product owner gets around to iterating amend its exception cases, the Application need not do anything else other than allow administrative users to supplement the Organizations with a list of people.
Sooner or later, they will want to not include certain people coming through the Organization evaluation. It is around this point where the letting go process of Organizational-based authorization begins and will eventually end up back at Solution 2. It's a process.
The service architect feels good. This iterative path is going somewhere.
Retrospective
- Know the difference between a functional requirement and a solution. It's easy to be led by the nose into a clumsy solution. Most people think in terms of capturing and moving data. They also believe that any application responsibility means the end-user has to do more work. This is about service design and assigning responsibilities among blocks of code.
- People also have trouble with the asymmetry of services.