OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [soa-rm] ideas on shared services


I wanted to thank Michael for his comments and encouraged others to contribute their thoughts in preparation for Wednesday’s cll.

Ken
------------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S F510          phone: 703-983-7934
7515 Colshire Drive                           fax: 703-983-1379
McLean VA 22102-7508

On Mar 12, 2015, at 9:00 AM, Mike Poulin <mpoulin@usa.com> wrote:

Since I will not be able to participate in the next meeting on 18th March, below are a few of my comments to the major open items
Regards,
- Michael
 
Sent: Wednesday, March 11, 2015 at 1:59 PM
From: "Ken Laskey" <klaskey@mitre.org>
To: soa-rm@lists.oasis-open.org
Subject: [soa-rm] ideas on shared services
The attached is largely a repurposing of something I needed to write elsewhere.  It begins to capture ideas that can use some formal capture and wider dissemination.  I’ve bounced some of this off Michael Poulin and a piece of that exchange is captured at the end of the attachment.
 
Major open items would be thoughts and recommendations on:
 
- top-down vs. bottoms-up identification of services: to what extent do we have top-down planning and approval to create services?
 
[MP:
the top-down vs. bottoms-up identification of services: all services have to be planned and approved. I am for planning anywhere in the company - in an office of a Chief Architect or in a Department architect team. However, I recommend only top-to bottom approaval. In the enterprise divided by LOBs, Divisiona, Departments people tend to duplicate functionality and services for the sake of convenient management and strenthening puersonal positions. An approval model I have in mind is Cross-Functional Cross-Divisional Management Unit that controls creation of all new services and changes in the existing services from the functionality and information perspectives. This relates also to the investments into new/modified services. For example, if a division wants to build a new service, this has to be justified via the reasons why an existing service is not suitable, why internal build is better than an available external service and what additional business value a new/changed service will bring.
]
 
 To what extent do we allow (encourage?) services to organically appear.
 
[MP:
I do not understand what does mean "organically appear" unless it is a need identified in the practice and omited in the previous planning. IMO, such 'organic' services should be allowed with the approval described above.
]
 
 Is there a balance between top-down and bottoms-up?  
 
[MP:
IMO, there shold not be any artificial balances for proposing and developing services in the context of aforementioned approval procedure. The balance will come up naturally via the granularity of the consumer's needs visible at different levels of the enterprise
]
 
 
Personal opinion is top-down is usually not smart enough to work unless it is appropriately constrained in scope (and authority) and informed by bottoms-up.  Also, a challenge I’ve seen is a top-down process having to deal with a service that is a bottoms-up success.
 
- warranted/unwarranted duplication: when is two similar services duplication vs. two different ways to do something?  
 
[MP:
IMO, a SO Ecosystem must provide a means for business continuity for the enterprises. This is an ability to perform the same business functionality and to produce the same RWF in more than one way. These ways may be different. For example: an orchestrating automated service engages services S1, S2 and S3. This  orchestrating service gets down, but the should be a way to engage S1, S2, S3 and apply the orchestation logic to the outcome via a Workflow App or even manually.
]
 
When is “duplication” needed for innovation?  
 
[MP:
An  innovation may appear in the process of cretion of alternative access paths to the functionality and information
]
 
When is duplication needed for risk mitigation?
 
[MP:
It is needed for a disaster recovery and/or load balance and failover
]
 
- scalable governance: the previous items touch on governance.  Large projects have governance as part of their “overhead" but service governance needs to be lighter weight because it likely needs to be done for more instances and needs to be done much more quickly with fewer resources if it is to be scalable.
 
[MP:
Service governance needs to be constant, not per project. It should include both execution/run-time, availability/adverticement time and development time. Number of resources do nor impact business service scalability because such services do not own and contact resources directly. Data Access Service exist for such purpose and they have to be designed in very special way dependent on connectivity with resources, resours locations and allocations.
]
 
- other topics?
 
We can discuss via email over the next week and then take up as one of the topics for next week’s call.
 
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]