Re: [soa-rm] shared services comments

[Ken Laskey <klaskey@mitre.org>]

The last point falls under the category of if you are going to screw up, do it on a grand scale beyond which you can be held commensurately liable.  One consumer can collect damages from a provider but if there are a million claimants, the provider goes (or can threaten to go) bankrupt and the aggrieved consumers get to fight over the carcass.  This is true for any business and no SLA or service contract I know of can promise more.

Recall, the SOA-RAF discusses a balance between trust and risk with no guarantees.

Ken 

On Aug 18, 2015, at 4:29 PM, Martin Smith <bfc.mclean@gmail.com> wrote:

Mike--I always understood that "enterprise architecture" was invented by John Zachman, then at IBM working on business systems planning, in the 1980s. 

Regarding evidence and SLA's -- where there is a contract (or a "public offering" of a product or services with associated claims of functionality and performance) there is, in principle, legal enforceability. But most business buyers take account of whether or not the offeror is a "responsible source", which means a track record of some sort and enough net worth to allow the buyer to actually collect something via the legal system, 

I believe Ken and I have similar experiences with services offered "internally" (within some organizational boundary) where formal contracts don't apply (Division A can't sue Division B).  In that case, Division A would like to have some assurances that Division B will perform, or some more ad-hoc recourse (like the Manager of Div B's head, for example.) 

I think most commercial IT services will be offered on a "public offer" basis--same terms for all or most customers, which would be public.  In fact, we often also see offerors of all types citing their own or a third-party's statistics on performance, etc. So certainly there is evidence available to buyers in most cases. 

Regarding Ken's story of an individual trying to get resources from a large company:  that's an interesting observations.  Maybe we ought to formally recognize the role of "relative market power" in modeling shared services. 

Martin

 

 

On Tue, Aug 18, 2015 at 3:45 PM, Mike Poulin <mpoulin@usa.com> wrote:

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.

 

Regards,

- 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.  

 

Ken

 

 

 

 

 

------------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S F510          phone: 703-983-7934
7515 Colshire Drive                           fax: 703-983-1379
McLean VA 22102-7508

--------------------------------------------------------------------- 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

--

Martin F Smith, Principal

BFC Consulting, LLC

McLean, Va 22102

703 506-0159

703 389-3224 mobile