Re: [soa-rm] shared services comments -- enterprises and organizations?

["BFC.McLean" <bfc.mclean@gmail.com>]

Just a data point on actual usage of "enterprise" as "big org hq". (I'm not advocating this usage for our purposes, necessarily.). 

From today's Fed News Radio e-newsletter:

NASA CIO to retire in December

NASA could be soon looking for another chief information officer.

Sources say Larry Sweet has told his staff he plans on retiring at the end of the calendar year.
Sweet moved to NASA headquarters from Johnson Space Center in June 2013 and worked for the agency for what will be 28 years in December.

Over the last two years, he has been advocating a concept called “enterprise first,” where the 18 space centers and organizations could take advantage of shared IT services.

Martin

Sent from my iPad

On Aug 19, 2015, at 5:06 PM, Ken Laskey <klaskey@mitre.org> wrote:

So I would tweak this to allow multiple purposes, with the caveat that the purposes should have appropriate synergy and not be a random grab bag.  “Entities” that take on too many things become unfocused; however, too narrow a focus could hamper understanding context and addressing the large, but still focused, picture.

Ken

On Aug 19, 2015, at 5:00 PM, Martin Smith <bfc.mclean@gmail.com> wrote:

Bob, all--

Lots of words are used in multiple ways ("overloaded" if you like) and this is one of them. 

I've concluded that it's pointless to try to establish the "correct" definition for such words-- we are not the Academie Francaise, after all, or the OED; we can, however, decide how we will use the term in a particular document, report or whatever (and make that clear.)  Or, rather than use really horribly overloaded terms, we can avoid them and pick another less popular term, and provide a nice clear definition in a glossary appendix.

With that preamble, I think a useful distinction I've heard in the discussion (e-mail and oral) in the SOA-RM TC is that "enterprise" should be used (in SOA-RM TC documents) to denote organizations (including joint ventures, associations, programs, temporary organizations) with a single purpose (and not merely "large" organizations, for example, despite my own first thought on the topic.)  

If we adopt that ("common purpose") idea, then we should definitely state the definition in any document that uses it. 

Best regards,

Martin

 

On Wed, Aug 19, 2015 at 4:13 PM, Natale, Bob <RNATALE@mitre.org> wrote:

Wrt “enterprises as bigger than organizations” -- I think that in the context we are all talking about here the following would be generally accepted observations:

 

- All enterprises are organizations; not all organizations are enterprises.

- An enterprise is a type of organization; an organization is not a type of enterprise.

- Some enterprises are larger than some organizations; some organizations are larger than some enterprises.

 

I have not been following this full thread carefully, so you folks might have already integrated these observations into your thinking. If so, I am certain that whatever the consensus is among the active participants will be valid and workable.

 

If you have discounted any of those observations as inaccurate, I’d like to understand the thinking behind that.

 

Avanti,

BobN

 

From: soa-rm@lists.oasis-open.org [mailto:soa-rm@lists.oasis-open.org] On Behalf Of Mike Poulin
Sent: Wednesday, August 19, 2015 3:12 PM
To: Martin F Smith, BFC Consulting <bfc.mclean@gmail.com>
Cc: Laskey, Ken <klaskey@mitre.org>; soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] shared services comments

 

It seems I am in sync with Martin on org. vs ent. and on control.

 

BTW, I see the following statement common for both org. vs ent. :

 <<it represents a decision-making unit -- which lets it makes policies effective for the whole entity, make commitments and accept liability (via contract) for the whole entity, and direct resources of the entity. >>

 

I'd like to comment on 

<<My sub-sub-sub organizational unit may feel most comfortable if it runs all the parts of my mission system, but is it "outsourcing" when the next-level up CIO requires us to use their "shared-services" IdAM system for access-control? Or only when one of our engineers wants to leverage a call to an authentication-as-a-service offering on AWS? Again citing my experience working in the US Federal Government, I might have more "control" over the AuthN-aaS via contracted SLA commitments (and the ability to fire them) than I do over my HQ's IdAM service.>> Particularly,

 

 a) Shared services can be "outsourcing" inside the company only if the the BU has the full ownership on its systems and solutions (processes). This is a rare situation within one organisation, becuase both the BU's systems and shared services are considered internal resources. A corporate business can still own its A capability if it contropls the A-function while the A-implementation is outsourced. If the capability's function is outsourced, the entier capability is outsourced and the company loses it

 

b) If an authentication-as-a-service or any other services provided by anbother business organisation, it is the outsourcing indeed. I agree with the need of 'more control', especially for a Government organisation. But here is a decision to make: more control AND higher cost VS. lower cost and less control :-) 

 

CHeers,

- Michael

 

Sent: Tuesday, August 18, 2015 at 4:01 AM
From: "Martin F Smith, BFC Consulting" <bfc.mclean@gmail.com>
To: "Ken Laskey" <klaskey@mitre.org>, soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] shared services comments

Ken, all--

A bit more on organization vs enterprise.

1. My impression is that people (Trekkies aside) think of enterprises as bigger than organizations, but of course that's just the connotation I've absorbed based on usage I've seen. And size probably is not a useful basis for distinction in any case.

2.  I suggest that whatever the term, the most significant things about an "organization" are that it has resources (as Ken says) but also that it has a boundary.  That is, it represents a decision-making unit -- which lets it makes policies effective for the whole entity, make commitments and accept liability (via contract) for the whole entity, and direct resources of the entity. 

3.  The authority of the entity is always limited the context of the jurisdiction(s) to which it is subject. This context will always include governmental jurisdictions (at multiple levels...); but it also could simply be limitations imposed by higher levels of the organization of which the entity is a part, if it is, for example, a business unit of a large corporation. In any case, within the limitations imposed by its context, the entity can direct and commit (via contract) resources and set its own rules/policies.

4.  For our purposes and the discussion of "outsourcing" I think we should recognize that the key issue is control (and its flip side, commitment.)  Control is nice because dependencies add various risks (often overstated, IMHO.)  But control (like commitment) is not absolute, and does not necessarily correspond to insourcing or outsourcing. My sub-sub-sub organizational unit may feel most comfortable if it runs all the parts of my mission system, but is it "outsourcing" when the next-level up CIO requires us to use their "shared-services" IdAM system for access-control? Or only when one of our engineers wants to leverage a call to an authentication-as-a-service offering on AWS? Again citing my experience working in the US Federal Government, I might have more "control" over the AuthN-aaS via contracted SLA commitments (and the ability to fire them) than I do over my HQ's IdAM service.  

Talk to you Wednesday.

Martin


  



 

On 8/17/2015 10:10 PM, Ken Laskey wrote:

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