Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The service architect poses the question to the product owner who reiterates that the authorizations should be based on organizations. When she asks if there are any exceptions to the organization rule, the product owner reports that these exceptions do exist but the project can iterate on the development of that feature later. However, the service architect wants to nail down the services to which application will interface and contain development iterations to within those boundaries. This is the key.

If there's any part to this system that ought to be stable, it is the line between the end user application and the services it talks to. The stated requirement was to list a bunch of organizations who can create and update Holds. This is a solution, not a requirement. When there's a new authorization rule to which organizations can do something else to a Hold, a new record Type agreement will have to be made. This isn't stable. If this line isn't stable, then it destabilizes everything underneath it. 

Solution 1: Ignoring the Organizations

Solution 2: Mixing in the Organizations