[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-blueprints] Primer
The Soalogic manufacturing Level 0 - Level 2 is relatively general (odd things like Website in Marketing aside). There is probably more chance of having tight domain specific blueprints (like POS or CRM) than generalist high level process, beyond the top level 4 step order to cash. Steve > -----Original Message----- > From: Ken Laskey [mailto:klaskey@mitre.org] > Sent: 29 November 2005 13:32 > To: Jones, Steve G; marchadr@wellsfargo.com; jinu.joseph@polaris.co.in; > soa-blueprints@lists.oasis-open.org > Subject: RE: [soa-blueprints] Primer > > Steve, > > Good luck on the head cold :-) > > The key is modularity. You can't reuse pieces if one piece is the > entire process. You can't effectively modify your process if every > change requires a rewrite of your stovepipe software. > > This gets back to the question of what we mean by blueprint and what > we are writing it/them for. Do we write a detailed POS > blueprint? How reusable is that for someone not interested in > POS? Can we lay out a few generic blueprints for things like > long-running processes with structure that says, "Your company > specific piece fits here."? > > So I think we mostly agree. > > Ken > > At 04:48 AM 11/29/2005, Jones, Steve G wrote: > > > > > > -----Original Message----- > > > From: Ken Laskey [mailto:klaskey@mitre.org] > > > Sent: 23 November 2005 15:40 > > > To: marchadr@wellsfargo.com; jinu.joseph@polaris.co.in; soa- > > > blueprints@lists.oasis-open.org > > > Subject: RE: [soa-blueprints] Primer > > > > > > > > OK, now we're getting to some meaty issues :-) > > > > > > > > It would seem that a useful pattern would be a long-running business > > > process, where the "business" could as likely be technical as > > > commercial. What are the requirements of such a process? What > > > assumptions do we make about the process? What are the notional > > > pieces of a solution? How do these pieces notionally work > > > together? Where are there alternatives? Finally, what combination > > > of completed standards, specifications within standards committees, > > > and private specifications will likely enable such a blueprint? > >[Jones, Steve G] > > > > > >Depending on what you mean here by process I'll either massively agree or > >throw my hands up in despair :) > > > >Unfortunately I'm in Q4 Crunch at the moment so time is stretched, but on > >the Soalogic (Google aware in 3 days Dan!) business I'm looking to define > >(help would be great) the hierarchy of order to cash processes. Most IT > >efforts at the business level that I've seen fail, and which have been > the > >hardest to clean up, is when IT tries to map an end to end process in its > >entirety. This fails for many reasons > >1) The process is too large and unmanageable > >2) It's the first time the business has seen its process codified, > they'll > >want to change it > >3) Different parts of the organisation want to change the process in > >different ways > > > >This is why structure is (IMO) 100% required to have a successful and > >effective SOA. Taking the loan decisioning example.... > > > >This is long running from the CUSTOMERS perspective but for several > >departments it's a short-lived process, and one which they want to > optimise > >(e.g. credit check and scoring) on a regular basis. Thus there is a > >high-level process for tracking progression (long lived), within which > each > >step is probably in itself a process, some long lived (confirmation of > paper > >work), but mostly short-lived. This is where service really comes into > its > >own as it provides the boundaries for both the high-level process > (normally > >fairly static) and the lower level processes (often required to be > dynamic) > >this differing rates of change in different parts of the organisation is > a > >massive challenge if you view this as a single process. > > > >Each process step should be a service invocation therefore that has its > own > >associated control and rate of change, which has a clear boundary from > the > >main process, which is itself just a service offered to the customer. > There > >is an interesting challenge here on how interactive processes are exposed > >and managed from a service, does the process "request" interaction with > the > >user, or does it have its own contained user interface? > > > >I agree with the principle of taking a "thread" through an organisation, > but > >I'd argue we should treat it more as a series of service invocations than > a > >CICS transaction. > > > > > >The example below from Dan is a great one, in theory you could view the > POS > >transaction as being a process that includes stock-reordering, warehouse > >management, back to manufacturing, back to the supplier etc etc. But its > >not, it's a process that has an effect that could result in other > processes > >being triggered. Equally strategic budgeting effects everything in the > >business, but its an "information in", "information out" high-level > command > >process. > > > >In terms of standards WS-Contract (pre,post,invariant) would be a welcome > >addition! > > > >Steve (with a massive head cold) > > > > > > > > > > > > > > Note, part of the output of this thought process could be feedback to > > > existing committees on what is needed from their specs or how the > > > process needs to be curtailed to fit the current and evolving > standards. > > > > > > > > Ken > > > > > > > > At 10:24 AM 11/23/2005, marchadr@wellsfargo.com wrote: > > > >Jinu these are good points. > > > > > > > >Something I would say to this would be that in most implementations > > > >of SOA there are basic structures that could be followed with the > > > >variation being the actual business logic. > > > > > > > >Even within a certain space there are multiple blueprint needs. > > > > > > > >For instance, > > > > > > > >- Fulfilling a loan may be a long running process that might take > > > >into account a workflow with certain security requirements etc... > > > > > > > >- While making a wires transfer would have to be highly available > > > >and have routing based on fraud and security rules without the need > > > >of long running process > > > > > > > > > > > >To apply them to some of the cases within the soalogic approach you > > > >could see the following: > > > >1. Based on the process of developing a product within soalogic they > > > >need a managed long running process. This pattern without the > > > >specific business logic could be applied to the loan case. Or could > > > >even be applied to strategic budget planning, etc... > > > > > > > >2. The retail store is using a pos process that needs to be secure > > > >and have fraud detection for purchases made by the customer this > > > >could be applied without the specific business logic to a wire > transfer > > > case. > > > > > > > >The actual blueprints could be extracted for 1 that state: > > > >- WS-BPEL - manage the long running process > > > >- Transport types that could apply (HTTP/HTTPS/MQ) > > > >- WS-Security - for managing who is able to update from a client > > > >auth perspective > > > >- WS-Coordination - to coordinate with different SORs > > > >- WS-Notification - to alert either an operation or customer service > > > >agent of an issue within the process through an intermediary service > > > >- WS-Profile - for indentify the service > > > >- WS-CAF - to provide context around who the requestor is > > > >- Fault Management - how and what type of responses would happen, > > > >sending an WSN event? > > > >- XACML - for determining the rights of the user invoking the service > > > >- etc... > > > > > > > >So what you end up doing is creating a stack of patterns that could > > > >be applied to a problem area that involves long running operations > > > >or short fast operations, etc... > > > > > > > >Of course the specific technology may not be decided upon within the > > > >blueprint but the concepts within WS-BPEL will be abstracted with an > > > >example implementation of how WS-BPEL fulfills the specific request. > > > >Essentially think of the types of services you have ever created and > > > >think about a lot of the common problems you had to solve along the > > > >way to get specific business logic to be invoked within a service > > > >context. There are a lot of problems that are common across > > > >implementations such as security, event management, auditing, even > > > >in some cases accounting to chargeback for a service invocation to a > > > >specific customer or internal client. Some of these could be in a > > > >ESB or some could reside with the service and it may be worthwhile > > > >to come up with a sample deployment for each blueprint that may > > > >determine the type of system needs associated with the blueprint. > > > > > > > >I'll try and come up with an example at the end of the week or next > > > >week so you don't think I am crazy :) > > > > > > > >- Dan > > > > > > > > > > > >-----Original Message----- > > > >From: jinu.joseph@polaris.co.in [mailto:jinu.joseph@polaris.co.in] > > > >Sent: Tuesday, November 22, 2005 7:58 PM > > > >To: soa-blueprints@lists.oasis-open.org > > > >Subject: RE: [soa-blueprints] Primer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Hi Folks > > > >I am just thinking aloud here. I feel that while a blueprint does > give a > > > >kind of basic map while moving into uncharted territory, it still has > the > > > >following limitations > > > > > > > >- Blueprints as discussed are limited to a category of contexts. > Going by > > > >the house analogy the blueprint i need for the house will be > dependent on > > > >who I am and where I want to build the house. If I am the President > of > > > the > > > >United States, then I cannot build the house using the same blueprint > > > that > > > >you and me would use, Similarly if I would use different blueprints > to > > > >build my house in the Sahara Dessert and my house in Antarctica. > What I > > > am > > > >trying to say is that the Blueprint might applicable for a type of > system > > > >and may not be useable for all software systems wanting to go the SOA > > > way. > > > >The SOA blueprint for the Financial Services Systems used by Banks > would > > > be > > > >different from that used by Corporates for their Inventory Management > > > >System. > > > > > > > >- Trying to make a generalized blueprint will lead to such a high > level > > > of > > > >abstraction that the blueprint itself might not be of much use. Going > > > back > > > >to the house analogy trying to make a generalized blueprint might > lead to > > > >the blueprint only containing guidelines like, there should be a > > > >foundation, there should be a ceiling, there should be windows etc... > > > > > > > >- What I feel is that we should have SOA blueprints based on software > > > >segments such BFSI segment, ERP segment, Services like Utilities etc. > > > > > > > >What do you say ?? > > > > > > > >Regards > > > >Jinu Joseph > > > >Polaris Software Lab Ltd > > > >e-mail: jinu.joseph@polaris.co.in > > > > > > > > > > > > > > > > > > > > <marchadr@wellsf > > > > > > > > argo.com> To: > > > > <klaskey@mitre.org> > > > > cc: > > > > <soa-blueprints@lists.oasis-open.org>, (bcc: jinu.joseph/Polaris) > > > > 23-11-05 03:53 Subject: RE: > > > > [soa-blueprints] Primer > > > > AM > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >See comments below. Good feedback Ken. > > > > -----Original Message----- > > > > From: Ken Laskey [mailto:klaskey@mitre.org] > > > > Sent: Tuesday, November 22, 2005 12:07 PM > > > > To: Marchant, Dan R. > > > > Cc: soa-blueprints@lists.oasis-open.org > > > > Subject: Re: [soa-blueprints] Primer > > > > > > > > At 09:50 AM 11/22/2005, marchadr@wellsfargo.com wrote: > > > > Ken these are questions that I am sure with be > concretely > > > > established by this tc. Here is my take (keep in mind I > am > > > on a > > > > blackberry so it might be more terse than normal). > > > > > > > > 1. A blueprint in my mind is to establish a structure to > an > > > > other wise disorganized approach to developing software. > I > > > have > > > > typically called blueprints a reference architecture > (not to > > > be > > > > confused w/reference model). > > > > > > > > 2. Think of the scenario of buying building blueprints > from > > > a > > > > house designer and than having though blueprints tweaked > by > > > a > > > > local architect of the house. Maybe for your > requirements > > > you > > > > need the kitchen closer to the family room or a water > closet > > > > turned into a walk in closet. Whatever the changes the > basic > > > > structure is defined for what you need to accomplish > > > building a > > > > house with N number of rooms that each have a function. > > > > > > > > You might find this analogy interesting: > > > > > > > > > Go back to our house analogy. The RM captures concepts > related > > > to > > > > > what makes up a house, e.g. room, window, door. It might > include > > > > > the concepts of food preparation area and personal hygiene > area > > > and > > > > > > > > > the relationship that there should be physical separation > > > between > > > > > the two. Note that this provides a very North > American/western > > > > > Europe reference and not necessarily one that covers a tent. > So > > > a > > > > > given RM already provides a perspective. > > > > > > > > > > Given RM concepts, various RAs show how these concepts can > be > > > > > arranged in a useful pattern. So RA examples would be (sorry > for > > > > > the American terms) a colonial, a split-level, a rambler, > etc. > > > You > > > > > can play with the pattern but one can say that any given > pattern > > > > > serves a particular set of purposes (e.g. a rambler is on > one > > > level > > > > > > > > > for those who want/need to avoid stairs). > > > > > > > > > > An architecture is then a specific plan to build a house or > set > > > of > > > > > houses. There can still be some variations but you don't do > > > things > > > > > like moving fireplaces or structural walls, else you have a > new > > > > > architecture. > > > > [Marchant, Dan R.] Sounds a lot like the movie "Kitchen > Stories" > > > > about the period of time where sweden was conducting studies > on > > > the > > > > usability of a kitchen to identify patterns of usage. In some > ways > > > > the development of a blueprint is similar in nature to the > kitchen > > > > studies in the 50s. > > > > > > > > Is a rambler a ranch style house? I agree with the structural > > > > statement creating a bit of constraints that take care of the > > > > reduntant nature of developing an SOA. Everyone in the US > probably > > > > has a water closet (bathroom) in the master bedroom a pattern > that > > > is > > > > identified based on the experience of the architects in > finding > > > the > > > > needs of the consumer of the house. Likewise the blueprints > can > > > > evolve by building on the reference model. > > > > > > > > > > > > 3. To establish direction or rudder the ship. You need > to > > > > establish the pie in the sky and a blueprint can help > get a > > > > handle on that pie. > > > > > > > > If you have a ship without a rudder, you are likely beyond > being > > > > saved by a blueprint :-) > > > > > > > > 4. There is a type of tracability that can be > accomplished > > > > through following a blueprint. Also it may be important > to > > > use > > > > a third-party blueprint to establish a motive for > changing > > > the > > > > way a business does things, not sure if this applicable > for > > > > everyone but there is definely value in having something > to > > > > refer too. > > > > > > > > Good points. Now can someone craft those into a paragraph or > two > > > > that any of us can present to a client and they would feel > they > > > know > > > > something they didn't know before? > > > > [Marchant, Dan R.] Wiki ? > > > > > > > > My take is this on the blueprint roadmap so to speak. > > > > > > > > 1. Establish a couple different scenarios where services > > > would > > > > help and how the service would be structured within that > > > > context and including supporting services. > > > > > > > > 2. Take the scenarios and generalize them into patterns > with > > > > some technology choices as and example of implementing > > > pattern. > > > > > > > > 3. Establish an overview of how all the supporting > services > > > > could be structure to support the various patterns. > > > > > > > > It would essentially turn into a type of framework, a > > > service > > > > could follow and establish the need for supporting > services > > > in > > > > a formal way. > > > > > > > > Step 2 after you define a blueprint is to lay out how you > would > > > > create one. Your roadmap looks like a good initial approach, > both > > > > for motivating a blueprint and showing how one blueprint > > > > can/should/might support more than one scenario. > > > > > > > > I could see it on the same lines of developing anything > > > spring > > > > or a portal. You have a set of facilities that are > > > applicable > > > > for certain scenarios that than could be implemented of > > > > configured appropriately. > > > > > > > > The great unknown being what business logic is performed > but > > > > most of it could be generalized into some type of > pattern. > > > For > > > > example, transaction based, inquiry based, aggregation, > or > > > even > > > > everyone's favorite semantic service. > > > > > > > > Thoughts from the group? > > > > > > > > Dan > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Ken Laskey <klaskey@mitre.org> > > > > To: Marchant, Dan R. <marchadr@imc.wellsfargo.com> > > > > CC: soa-blueprints@lists.oasis-open.org > > > > <soa-blueprints@lists.oasis-open.org> > > > > Sent: Mon Nov 21 22:42:48 2005 > > > > Subject: Re: [soa-blueprints] Primer > > > > > > > > I have not been following the email carefully enough, so > > > > forgive me if this has already been established but > > > > > > > > 1. Exactly what is a blueprint? > > > > 2. What purpose does it serve? > > > > 3. Why should I think one will be generally applicable? > > > > 4. Why do I care? > > > > > > > > Do we expect that a blueprint will be a sort of turnkey > > > > formula? How do we determine the limits of > applicability > > > for a > > > > given blueprint? Are there underlying assumptions that > all > > > > blueprints have in common, or is each blueprint > > > fundamentally > > > > different (a very possible construction), or are there > > > > fundamental groupings with multiple non-redundant > examples > > > in > > > > each group? > > > > > > > > I think agreeing on a clear strawman definition of > blueprint > > > is > > > > essential. It can be modified as we learn more but we > need > > > a > > > > clear starting point. > > > > > > > > Ken > > > > > > > > On Nov 21, 2005, at 9:12 PM, <marchadr@wellsfargo.com> > > > > <marchadr@wellsfargo.com> wrote: > > > > > > > > > > > > > > > > One question to pose to the group is maybe the case > study > > > > actually becomes a type of primer for the blueprints > once > > > the > > > > blueprints are defined. > > > > > > > > Thoughts? > > > > > > > > Dan > > > > > > > > > > > > > > > > > > > > > > > > --- > > > > Ken Laskey > > > > MITRE Corporation, M/S H305 phone: 703-983-7934 > > > > 7515 Colshire Drive fax: > > > > 703-983-1379 > > > > McLean VA 22102-7508 > > > > > > > > > > > > -- > > > > > > > > > > > >--------------------------------------------------------------------- > ---- > > > -------- > > > > > > > > / Ken Laskey > > > > \ > > > > | MITRE Corporation, M/S H305 phone: 703-983-7934 | > > > > | 7515 Colshire Drive fax: 703- > 983- > > > 1379 > > > > | > > > > \ McLean VA 22102-7508 > > > > / > > > > > > > > > > > >--------------------------------------------------------------------- > ---- > > > --------- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >This e-Mail may contain proprietary and confidential information and > > > >is sent for the intended recipient(s) only. > > > >If by an addressing or transmission error this mail has been > > > >misdirected to you, you are requested to delete this mail > immediately. > > > >You are also hereby notified that any use, any form of reproduction, > > > >dissemination, copying, disclosure, modification, > > > >distribution and/or publication of this e-mail message, contents or > > > >its attachment other than by its intended recipient/s is strictly > > > prohibited. > > > > > > > >Visit Us at http://www.polaris.co.in > > > > > > > > -- > > > ---------------------------------------------------------------- > ---- > > > ------------- > > > / Ken > > > Laskey > \ > > > | MITRE Corporation, M/S H305 phone: 703-983-7934 | > > > | 7515 Colshire Drive fax: 703-983-1379 > | > > > \ McLean VA 22102-7508 > / > > > ----------------------------------------------------------------- > ---- > > > ------------- > > > > > > > > > > >This message contains information that may be privileged or > >confidential and is the property of the Capgemini Group. It is > >intended only for the person to whom it is addressed. If you are not > >the intended recipient, you are not authorized to read, print, > >retain, copy, disseminate, distribute, or use this message or any > >part thereof. If you receive this message in error, please notify > >the sender immediately and delete all copies of this message. > > -- > -------------------------------------------------------------------- > ------------- > / Ken > Laskey \ > | MITRE Corporation, M/S H305 phone: 703-983-7934 | > | 7515 Colshire Drive fax: 703-983-1379 | > \ McLean VA 22102-7508 / > --------------------------------------------------------------------- > ------------- > This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]