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
