Versions Compared

Key

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

...

  1. Know the difference between a functional requirement and a solution. It's easy to be led by the nose into a clumsy solution. Many 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. Service design is a different paradigm. It is about assigning responsibilities among blocks of code.
  2. Some functional requirements are short sighted. Tightly coupling organizational affiliations with authorizations is not necessary in small environments and never holds up well in an enterprise (changing hold authorization requirements will never cause an institution to do a re-org).
  3. Squirreling through a problem creates new problems to be solved, and solving those creates more problems, and so on. Sometimes it helps to go back to the very beginning and change find that one initial assumption on which everything else was based. It's so much easier to do this on a whiteboard rather than wait until the code was written. 
  4. People 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. 
  5. Generally speaking, encapsulation is good. But here, it made 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.

...