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] shared services comments

In many recent conversations with promoters of EA, I have found how the distinguish between Organisation and Enterprise [BTW, a name Enterprise Architecture originated by Dr. J. Ross in 2006, has nothing to do with the term Enterprise as it is understood today by the think-tanks in this area]. So, an organisation is a formal, usually, legal entity what has control on its assets and related boundaries (in some cases organisations may have some controls outside of their boundaries), An enterprise is a group of people who agreed to act/work together for certain goals/objectives/benefits. An Organisation and Enterprise overlap: an Organisation may have one or several Enterprises inside its boundaries as well as some Enterprises can cross the Organisation's boundaries. For example, members of OASIS form an Enterprise thIMO, at overlaps with the Organisations where the members work.
IMO, an Application is a technoloy SW means with the pimary task/goal in solving certain task using comuter's capabilities; a task of servicing consumers is not the pimary task/goal. This is why Applications used to expose its internal constraints and problems on thir consumers.
A notion of dependencies is the 1st Class Citizen for Services: they work on a narrowed functonality while acquiring results og many others.
Principle of Composability is about abolity of a service to participare in as many (external) compositions as needed and also to compose as many other composisitons as needed. A buisness process here is opnly a means of the composition execution. Moreover, it may be not a process but a case (i.e. when the executions logic is not pre-defined). 
I do not know how a statement "a consumer should doubt an SLA unless there is some proof, e.g. the provider has historically met SLAs and history is still a valid predicted of the future." has ended up in this discusstion, but I think it is incorrect. If a Service Provider serves consumers based on the explicit contract only, nobody would be able to test/prove any historical compliance with the SLA becuase they are in the private contracts. I use only the definitions that are in RAF. Moreover, using new definition of Business Capabilities, it is impossible to rely on the historical data for the future in the dynamic environment, i.e. in where we all heading to.
- Michael
Sent: Tuesday, August 18, 2015 at 3:10 AM
From: "Ken Laskey" <klaskey@mitre.org>
To: soa-rm@lists.oasis-open.org
Subject: [soa-rm] shared services comments
My apologies for not getting back to this sooner.  I’ve inserted comments to comments made by Michael and Martin in their respective mark-ups.  We can discuss these further during Wednesday’s meeting — call-in details to be distributed.
A couple of definition questions came up that have bothered me for a long time, and I’d be interested to know if others have suggested definitions.  
- I used the terms Organization and Enterprise, and Martin asked for definitions.  I found a useful definition of Organization* but nothing satisfying for Enterprise.  Any suggestions.
  * Organization -- A specific real-world assemblage of people and other resources organized for an on-going purpose. 
- Michael talked about services and applications, and I have never seen a good definition of Application when the discussion is on Services.  Any satisfying definitions for Application?
As for composability, a service may interact with another service as part of following a business process.  The idea of composability is to be able to concentrate on the higher level process and not the details of subprocesses that might make use of other services.  This is where opacity comes into play.  Yes, there are dependencies, but I believe there may also be dependencies for “applications”.  It is up to the provider to manage dependencies, and a consumer should doubt an SLA unless there is some proof, e.g. the provider has historically met SLAs and history is still a valid predicted of the future.
In general, I’ll stick by sections 3.3.1 and 4.3.5 of the SOA-RAF.  
Dr. Kenneth Laskey
MITRE Corporation, M/S F510          phone: 703-983-7934
7515 Colshire Drive                           fax: 703-983-1379
McLean VA 22102-7508

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