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: bank example of shared services [was: [soa-rm] SOA-RM agenda for 18 March 2015]


MIchael,

I don’t think we’ve closed on the question below, so I am pinging you on that and raising the bar.  

I recently talked with our old friend Jeff Estefan and he pointed me to the ITIL Services Management so-called “Type II” service provider type (see, for example, http://www.20000academy.com/blog/2014/09/16/itil-service-provider-types-type-2-shared-services-unit/).  

My feeling on reading the blog entry at this link was the Types I, II, and III service providers are all dealing with support services that are necessary but not important to the domain expertise of the organization.  Payroll is an obvious example of something that makes little sense to be Type I — provided individually by each business unit.  In some recent work, I was dealing with an agency where each project had its own development and test capability, and the plan was to make this available as a set of shared services.  The blog post thought the major problem was that eventually the shared service would fall behind in technology.  However, the real concern that I heard was more immediate, that the Type II replacement(s) — services provided centrally by some designated internal organization — would likely be better than the weakest Type I services but not as good as the best, customized Type I services.  Those responsible for the future Type II said they would aim for being better than the best Type I, but that is frankly unreasonable and likely costly to cover the superset of what was provided individually.  The debate will fall to whether the Type II has provided enough and whether what some Type I provided was really necessary.  Let’s just say this will be a management challenge: not necessarily impossible, but a challenge.

Type II sounds like what I have heard called in-sourcing as compared to Type III being outsourcing.  At the moment, I don’t think I care about that distinction.  The challenge for both the provider/owner and the consumer is what to do when the service is critical to your domain business, but it is also critical to the business of your peer projects.  Traditionally, each provides the service but we find that to be too expensive.  Do we have a model for someone else providing the critical services?  What is the position of the service provider/owner?  What is the position of the consumer?

The example of Netflix using Amazon Web Services follows this last situation.  What type of organizations are willing and able to make this leap of faith?  What does it take to establish that kind of trust?

Ken

On Mar 18, 2015, at 2:44 PM, Ken Laskey <klaskey@mitre.org> wrote:

Michael,

While discussing this with Rex during today’s call, I realize I made some personal assumptions in what the bank example identified as shared services, and it is better to ask than to assume wrongly.  Could you please tell us what some of those shared services were, how you identified these, and how you managed/tracked them once identified?

Ken

On Mar 18, 2015, at 10:58 AM, Mike Poulin <mpoulin@usa.com> wrote:

Ken,
 
your explanations are clear to me. Thank you. So, an external shared service is a shared outsourcing (including Cloud) though not every outsourcing is a shared service  (including Cloud).
 
Q: "does it make sense to have common security and access control services that have much more of an IT flavor than the core business might". Based on my experience in security - I designed and built an Entitlement Solution for credit risk managment in JP Morgan in N.Y. - the entitlement or access control _may be_ a part of core business. E.g. this control can drive the post-trading securities processing - who may do what at each process' step. In this case, a  post-trading securities processing as well as each of its steps appear as a protected business asset the core business of Institutional Credits.
 
CHeers,
- Michael
 
Sent: Wednesday, March 18, 2015 at 1:59 PM
From: "Ken Laskey" <klaskey@mitre.org>
To: "Mike Poulin" <mpoulin@usa.com>
Cc: "soa-rm@lists.oasis-open.org" <soa-rm@lists.oasis-open.org>
Subject: Re: [soa-rm] SOA-RM agenda for 18 March 2015
Michael,
 
Thanks for sharing your experience.  I think this is important to teasing out what we mean by shared services.
 
Let me clarify what I meant by internal and external, and I’ll try to work off your bank example.  The bank’s specialty is to come up with different financial instruments on which they can generate profits and return to their shareholders.  You note that this bank had spans of control based on geography and products.
 
Let’s look first at possible “internal” and “external” shared services.  The bank employs many people and needs to deal with payroll and benefits.  The old bank structure may have each had their own departments for payroll and benefits, but these departments could be considered “support” units because they were doing necessary things that were not part of the bank’s core capabilities.  The bank could decide to centralize the payroll and benefits function and remove the duplication of each old structure having their own.  This could be done through something like the shared services you describe for vanilla securities.  I might consider these “internal” shared services.  Alternately, the bank could decide that it could do better by getting an “external” service provider for the support functions, i.e. give up running their own payroll and benefits departments.  This is what I meant by internal vs. external.  The core mission of the bank is not the support functions, so they may have no vested interest in keeping those functions in-house.
 
The shared services for vanilla securities is an example of overlap but for functions that are clearly part of the core business.  Here, the bank will be looking for an internal entity to take responsibility as the service owner/provider for those shared services.  These services could be focused on fairly high level functions that are common or may get into common aspects of processes.  I don’t know banks well enough to give good examples here, but you can probably help flesh this out.
 
Then there are opportunities for common shared services within the bank’s ecosystem.  For example, does it make sense to have common security and access control services that have much more of an IT flavor than the core business might.
 
I will end this hear because I have a meeting in 2 minutes.  However, these are the areas I’m hoping we can flesh out.
 
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 18, 2015, at 9:19 AM, Mike Poulin <mpoulin@usa.com> wrote:
 
Hi Gentlemen,
 since I will not be able to participate in today meeting, here is a short description of my experience with shared services in one of the major UK banks.
 
I am not sure what an external shared service means; shared by whom? My example is about an internal  shared services.
 
An international/global investment bank had operations around the world; so, management of, e.g. Equity investments in EMEA  was quite actual. An initial organoisation of business was based on a matrix of product-centric and geography-centric. The Region Management ruled modifications of Products. You have to understand that I talk about financial investment products that are, in essence, sets of rules and sell-buy activities for particualr types of shares and stocks in different financial markets, as well as the operatinoal semi-autometed implementation 
 
Business Architecture have found that different products include more-or-less standardised securities ("valnilla") and specialised ones, and that vanilla presented in the majority of products were implemented by different teams reporting to different Product Managers. Also, Regional Managers tried to comuflage vanillas as specific to thier regions, which gave them a management power over the regular parts of the producrs as well. 
 
Teh shared services initially aimed the vanillas while such products might be the perfect candidates to be composed of the services only. The shared services had their own managment set around the 'function' of valilla securities; all deviations from the core had to be provided by this management only. As a result, the  Regional Managers had to deal with two suppliers - old Product Management and new Shared Services Management while the latter was centralised and off the controls of regions. The saving and efficiency of this solution was high though the resistence of Product and Region Management was high as well. The latter lost thier influence on the vnillas; usual arguments that local view and opinion of regions are the only right ones did not work any more - standard is standard even in finance. 
 
This, in this example we have a set of products/solutions/entities that share certain common functionality. This functionality (= shared services) is under its own control/supervision/managment [though under the same ownership in this case, which is not necessary for the general case].
 
Personally, I do not see a "federal case" for shared services. A lot od technical services are shared for the long time already. The specifics here may be in that existing applications/systems might use the same functionality and shared services have to extract this functionality from the applications/systems and reduce redundancy (the problem here is how to do this for COTS). The second problem is in how (and what) to generate DR per shared service that would be able to realise the Principle of Business Continuity.
 
Regards,
- Michael
 
Sent: Wednesday, March 18, 2015 at 2:44 AM
From: "Ken Laskey" <klaskey@mitre.org>
To: soa-rm@lists.oasis-open.org
Subject: [soa-rm] SOA-RM agenda for 18 March 2015
Two major items for the agenda are
1. Continued work on SOA ontology
2. Discussions on shared services
  - paper sent out last week and comments from Michael Poulin
  - shared services as something external (e.g. payroll) vs. shared services to improve core mission delivery of things you can’t get externally
 
If you would like to join the call and have not received the call-in info, send me an email and I will send you the specifics.
 
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]