...
The service architect feels good. This iterative path is going somewhere.
Solution 4: Reducing Assumptions
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.
- Some functional requirements are short sighted. Tightly coupling organizational affiliations with authorizations is not necessary in small environments and never holds up in an enterprise.
- People People also have trouble with the asymmetry of services. How a consumer uses stuff coming out of a service and how that stuff gets in there are two different problems. In simpler designs, the data object goes in, the data object comes out. In a service paradigm, approach these two aspects independently.
- Generally speaking, encapsulation is good. But here, it makes more sense to surface the management of authorizations but in such a way as to carefully manage assumptions between the application and the Authorization OSID.