It seems to me that this thread closely parallels the views/viewpoint aspect of an architectural description as defined by IEEE 1471 and TOGAF. � Namely, that there are participants, which they call stakeholders, who have concerns and that similar concerns from potentially different stakeholders are grouped into a view.� An architectural description is then composed of the set of descriptions of each of these different views.� Our idea of capability can be looked at as a solution to a single, coherent set of concerns, i.e. the solution to a single view.
The above specs go on to say that a given stakeholder may have different concerns which are satisfied by different views.� Another point they make is that the different views must be checked for consistency and completeness when addressing the complete architectural description.
Don
Frank picked up a very important point: "different stakeholders will have different� understanding of the capabilities on offer".
For example, retrieving certain data from a database - is it a capability? What if I need to retrieve another data - is this another capability? Or a capability is just a set of operations on the database?
Yes, it is too late for one service = one capability. Plus, I think we may not decide this - SOA mirrors business world which may have several cohesive capabilities and consider them together as one business service.
Moreover, one capability does not mean one policy. In my previous message I gave an example where one capability expressed as one� operation(just for the sake of explanation) may still have a lot of message namespaces each of which may have an association with separate policy.
- Michael� �
--�
Don Flinn
President
Mansurus LLC
Tel: 781-856-7230
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.� You may a link to this group and all your TCs in OASIS
at: