Ok, Michael … perhaps my lack of regular participation in the group led to a false premise on my part … I had assumed a certain context in which this work seemed to make the most
sense … namely, the context corresponding to this (typical) dictionary definition of “Enterprise”: “unit of economic organization or activity; especially a business organization”.
On the basis of that false premise, I am happy to yield the point (and apologize for the distraction).
From: Mike Poulin [mailto:firstname.lastname@example.org]
Sent: Monday, August 24, 2015 2:53 PM
To: Natale, Bob <RNATALE@mitre.org>
Cc: Martin F Smith, BFC Consulting <email@example.com>; Laskey, Ken <firstname.lastname@example.org>; email@example.com
Subject: Re: RE: [soa-rm] shared services comments -- enterprises and organizations?
Unfortunately, I disagree with the Bob's observation. I will follow the definitions of enterprise and organisation I articulated in the previous messages.
An enterprise may be not an organisation - an enterprise does not require controls
All organisations have at least one enterprise - its owners and/or executives
An enterprise is not a type of organisation (by definition). Also, I think that the statement "enterprises
as bigger than organizations" is inaccurate: an enterprise can cross the organisation's boundaries, but can at the same time leave some parts of the organisation ouside of the enterprise
" Some enterprises are larger than some organizations; some organizations are larger
than some enterprises." This is an ambigous statement because it does not specify how some enterprises relate to some organisations. It is unclear, if people formed an enterprise and ready
to form an organisation, why they form this organisation smaller than their own enterprise?
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.
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: