Quick answer: If you are going the SOA route as an important system strategy, you need to start thinking about what a service is, how they relate to each other and how they differ and make great building blocks for use/reuse - hence Service categorization. If you are writing a (silo) application, which only consumes a few WebServices, you are home free, not bothering with service categorization.
- You easily learn that you do have different types of services
- Each category of services have their own requirements to technical infrastructure
- Each category of services have their own design rules (governance)
- To build a SOA, you need to have a precise definition of what a service is which is meaningful.
- WebServices can lead to function oriented services, while REST can lead to a resource oriented architecture. Are both SOA?
- I don't think I understand what's meant with law 4 and 5 (I understand the words, but not what you want people to do and when)
- I think I agree with law 3, Establish service ownership and Key Performance Indicators for your services, but an example of a KPI would be helpful
- I think I agree with law 8, Security is not optional in SOA, but I don't understand what you mean by it yet
- In SOA - Is my customer the same entity as your customer? Is my product list the same as your product list? In which situations?
- [Question still to be asked..]
NB! Feel free to add any question you might have here