[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: RE: [soa-rm] shared services comments
Team,
I do not see the entire thread here, so my apologies if I am out of context. DoD very deliberately defines enterprise in an Enterprise Architecture context as “ an endeavor”. Endeavors can range in size and duration from a one off, short term, small team, special ops mission to the entire Army Payroll and Personnel system. An special offs endeavor is less of an organization and more of an activity. I hope this is helpful.
William
From: soa-rm@lists.oasis-open.org [mailto:soa-rm@lists.oasis-open.org] On Behalf Of Martin F Smith, BFC Consulting
Sent: Monday, August 17, 2015 11:01 PM
To: Laskey, Ken <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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]