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.
From: email@example.com [mailto:firstname.lastname@example.org]
On Behalf Of Mike Poulin
Sent: Wednesday, August 19, 2015 3:12 PM
To: Martin F Smith, BFC Consulting <email@example.com>
Cc: Laskey, Ken <firstname.lastname@example.org>; email@example.com
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. >>
<<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 :-)
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.
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.
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: