OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [soa-rm] Groups - shared services_15-07.docx uploaded


I'd like to discuss one of the Martin;s comments related to teh 'translation' example:
"
This is the most interesting and SOA-specific case discussed. Use of composable  shared services to build apps, vs. separate development of complete apps, presents new challenges in governance--to evaluate investments serving multiple value chains; to allocate usage costs; to prioritize requirements initially and over time; and to manage the added external- dependency risks to systems using the service. 
"
Services cannot be composable - services do not include other services. In SO Ecosystems, each service is an independent entity and interacts with other services based on the Service Contracts. A service can organise a cooperation of other services playing a role of orchestating service. Combinations of services behave as service, not as an application. You cannot build apps out of services - Microservices are not services and this allows them to form applications. 
 
"to evaluate investments serving multiple value chains" - value chains comprises certain processes and activities involved in delivering business values to the consumers. How we evaluate investments in a business process or case serving multiple value chains? The same is for the services. Moreover, a service might not know it is used in this or that value chain.
 
"to manage the added external- dependency risks to systems using the service" - this the most interesting comment, IMO. Any system does and will consider a service as an "added external- dependency risk" because services are based on dependencies while systems avoid dependencies. It seems that the more services are adopted, the less room is left for systems that do not appraciate dependencies. BTW, a services redundancy is the consequence of hired dependencies in the service world - a service may not rely on one supplier for a data or a function becuase a service has to serve its consumer no matter what happened with the supplier; if a service makes a consumer involved in the sharing of supplier problems, the consumer will find another service quickly. 
 
Regards,
- Michael
 
 
Sent: Wednesday, July 22, 2015 at 9:57 PM
From: "Martin Smith" <bfc.mclean@gmail.com>
To: "Ken Laskey" <klaskey@mitre.org>
Cc: soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] Groups - shared services_15-07.docx uploaded
Ken, all-- Track-change comments attached per discussion at today's TC call. 
 
Regards,
 
Martin
 
 
 
On Tue, Jul 21, 2015 at 8:56 PM, Ken Laskey <klaskey@mitre.org> wrote:
Submitter's message
For discussion
-- Dr. Ken Laskey
Document Name: shared services_15-07.docx
Description
This is a thought piece for consideration and possible future action by
this TC.

The document begins with a general discussion of the term service, looks at
SOA services in the enterprise, considers how to identify and define SOA
services, and characterizes SOA services bases on how they delivers SOA
value.
Download Latest Revision
Public Download Link
Submitter: Dr. Ken Laskey
Group: OASIS SOA Reference Model TC
Folder: Member Submissions
Date submitted: 2015-07-21 17:56:17
 
 
 
--
Martin F Smith, Principal
BFC Consulting, LLC
McLean, Va 22102
703 506-0159
703 389-3224 mobile
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]