Re: [soa-rm-ra] service, capability, and concise description

[Don Flinn <flinn@alum.mit.edu>]

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

michael.poulin@uk.fid-intl.com wrote:
> 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
e-mail: flinn@alum.mit.edu
Tel: 781-856-7230
http://mansurus.com