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] sharable RWE [was: [soa-rm] security as shared service [was: ...]


Ken,
 
I will definitely think about this topic.
 
At a glance, we might be able to recommend consumers to reduce sharable RWE by shifting some of them into shared (i.e. pre-known). This might mean that the consumers have to ask the provider some questions before using the service and this is not a pure negotiation, which requires an explicit service contract. These questions and answers aim to transform some sharable RWE in shared RWE, i.e. increase an awareness of the consumer about the behaviour of to-be engaged service over the information provided by the service description.
 
I think, we have not addressed this option of soliciting an information additional to the service description as a regula/possible practice.
 
As a result, before we had 2 options:
1) an explicit contract that prohibits automated programmatic engagement of discovered service until the negotiation of the contract is positively complete
2) an implicit contract that allows automated programmatic engagement of discovered service (no negotiations are involved) 
Now we have 3 options:
1. = 1)
2. = 2)
3. Thsi can end up in 1) or 2) but itself is neither 1) nor 2)
 
- Michael
 
Sent: Monday, March 23, 2015 at 1:41 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] sharable RWE [was: [soa-rm] security as shared service [was: ...]
Michael,
 
Controlling all of the subprocesses has a very tempting benefit but it is often costly and has limits.  For example, unless you are in a business that uses electricity on the scale of that produced by an electric utility, you will depend on the utility for your power instead of generating it yourself.  You may have a backup generator to cover outages, but from personal experience, I’ve decided the backup generator probably is not worth it for personal use.
 
The whole point of outsourcing is that there are lower costs and possibly better performance by delegating/buying subprocess RWE.  Keeping a private copy of data is often appealing but it may introduce problems for keeping the data up to date and consistent.
 
Also, the idea of controlling everything gives the illusion of control, but real control is much more slippery.
 
Back to RWE, the RM discussion of description says you can’t describe everything.  This includes what one can describe as far as RWE.  The intent is to capture what can be considered significant, but that is also subjective.  Yes, this may be even more difficult when   there is composition — orchestration or, more likely, choreography — involved.  For example, I go to the market to buy chicken.  The RWE foremost in my mind is related to a subprocess of becoming the owner of the chicken for tonight’s dinner.  (I could send someone else to get the chicken and risk the RWE that it will cost me more because whoever I send may not consider what is on sale.)  However, I have read that some of the pollution in the Chesapeake Bay is related to chicken farms.  Is the chicken I buy from a company that contributes more or less to the pollution?  That is likely not part of the description on the label of the chicken.
 
I am interested in examples of what more you see needs to be captured and what we can say about it.
 
Ken
 
On Mar 23, 2015, at 9:03 AM, Mike Poulin <mpoulin@usa.com> wrote:
 
Ken,
 no, it is not. My point id that I've 'suddenly' understood that a service, especially an orchestrating service is not really in control over the RWE it causes.
 
The effect of this understanding is amplified by the contrast with regular business process. It is a known trend that the process management tries to acquire control over or even own all sub-processes and resources as well as everything that can impact the process (i.e. impact the process’ outcome). This trend has a secondary effect – all process outcomes are pre-known and controlled. It does not work with services because of the shareable RWE.
 
Particularly, if engaged services only return requested information to the client-orchestrator, the shareable RWE is minimal; if these engaged services generate additional outcomes in response to the engagement, the shareable RWE of initial service-requester may be significant. Even more, if the service-requester asks the engaged service to perform certain work (a return is only an acknowledgement about this work), which is not the outcome of the service-requester yet, the shareable RWE may be huge.
 
I think, we have not said enough about this in RAF and I have not seen in practice that architects put enough attention on the risks of shareable RWE. I think, we have to follow up on this concern. 
 
- Michael
 
 
Sent: Sunday, March 22, 2015 at 4:44 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: [soa-rm] sharable RWE [was: [soa-rm] security as shared service [was: ...]
Michael,
 
First, I agree with your points on BP and BPM.  However, I think I look a little differently at RWE.  In the write-up on shared services, I distinguished between output (which I believe is the same as your returned) and post-conditions (which I think make up both your shared and sharable RWE).
 
As you note, there are a lot of RWE, especially when there are more participants involved because each participant has their own things they need to do.  Some of these RWE are visible to some subset of participants, a different subset of RWE is visible to a different subset of participants.  So the book buyer and the book packer share the information that is shipment tracking, but that may not be explicitly shared with the payment service.  I see shared RWE as that set explicitly shared between some participants.  
 
Now for the leap:  I see the existence of all RWE as sharable under the appropriate circumstances in, like the service, the RWE is visible.  So, to be visible, someone needs to know the existence of the RWE, there must be willingness to share (i.e. allow access to) the RWE, and reachability (i.e. a means of access).  This is easier to talk about in terms of shared/sharable information; the sharable RWE is the time the book was delivered.  The RWE of the delivered book is only directly accessible by the person who physically has the book; therefore, in some sense, the RWE of the delivered book is not sharable by someone not collocated with the book.  Is this last point what you are trying to tease out?
 
Ken
 
On Mar 22, 2015, at 11:30 AM, Mike Poulin <mpoulin@usa.com> wrote:
 
Gentlemen,
 I have a new topic for one of out meeting agendas - "a real world RWE" :-) So far, we have defined three RWE types: returned, shared and sharable. My last contacts with BPM people have stimulated my curiosity on sharable RWE.
 
I  make it more clear, I have to provide some explanations on what it is and why it is now.
 
 
I always say that a a business process (BP)  is a form of implementation of business service (BS). Finally , I have found a stron BP and BPM oriented company that believe in the same as I do - in the a business process is not about business activities but about buinsess logic that allowes moving from step by step in realisnig predefined business function and delivering predefined business outcome, the RWE. This understanding allows to distinguish between the process functionality/execution logic and the means of this ecexution including who, how and where provides information and other resources that a process needs in each of its steps. Now we can say that any adbitrary provider of whatever activities can be engaged (orchestrated) by a process if this provider preserved the SLA defined by the process for its particualr step, i.e. what should be delibered to the process and via which mechanism.
 
I think that you have noticed already a great deal of similarity with the service orchestrations here. A few years ago, I have got agreemts from several BPM specialists that each business process is a business service to its consumers (definetely, if one would look at the world from inside of IT, nothing like this were visible). 
 
This, 1) every business process is a business service (the opposit is incorrect); 2) every business process is its business logic and interfaces (with relates SLAs).
 
Let's return to the RWE. Now we can say with asurance that the BP outcome is the service returned RWE. Moreover, this outcome can form the shared RWE. However, the shareable RWE is not that clear to me.
 
Problem is in that , a sharable RWE roots not only from the returned RWE. Every arbitrary provider of the means to the intermediary process steps can causenother RWEs in all three RWE types. For example, we have a BS of selling books. When a book is perchased, a service that orchestrates the entire solution engages a payment service, then a packing service and then delivery service. However, a paching service, which acts as an intermediary arbitrary provider to the major process implementating the Book Selling Business Service, also sends notificational post-cards to its other customers about a sale of a new book (if someone buys this book also, the packing service with get another order to pack it). 
 
The Book Selling Business Service does not know about such activities of one of its suppliers (packing Service) and really does not care about it. However, a distribution of information about the book selling may have a strong sharable RWE.
 
I have a feeling that when we narrowed Services and split related processes into logic and arbitrary providers of intermediary means ( activities/actinos/ sub-processes=supporting services), we have not put anopugh emphasis on the sharable RWE. IMHO, this deserves and demands more work from us (not many others understand this issue, especially in the BP automation in IT). 
 
Regards,
- Michael Poulin
 
 
 
 
 
Sent: Thursday, March 19, 2015 at 2:10 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: [soa-rm] security as shared service [was: [soa-rm] SOA-RM agenda for 18 March 2015]
Michael,
 
What I believe you are talking about are proprietary business rules that obviously will be customized for each business.  However, the PDP/PDP/… model could have executable business rules defined as input from the policy administration point (PAP), use this and attribute information from the policy information point (PIP) for the policy decision point (PDP) to assess compliance with the rules, and finally have the policy enforcement point (PEP) allow or deny access.  All the pieces can theoretically be generic (shared?) except for local PEPs and the specific rules and assessment attributes.  One can argue that making these generic will improve security because there will be more eyes on the shared services and these can be created and maintained by those with the required expertise.
 
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
--------------------------------------------------------------------- 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: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


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