Re: [service-orientated-architecture] Is the WS- vision achievable?

Fri, 30 Sep 2005 04:56:15 -0700

Hi John,
What you said makes sense. Making an interface somewhat like a portal through which the user can interact and invoke the relevant services in the back ground.
Let us try and elaborate further.
As we go on further we can also have additional work flows . For example a when sales rep submits a requests for a discount as asked by customer, a higher role above sales rep can approve the sales price less than what pricing engine recommends and puts back the control to sales rep to proceed further. I believe such actions can be designed in the process without effecting the individual web services.
Best regards,
Raja Mohan

John Hirsch <[EMAIL PROTECTED]> wrote:
Raja:
  Perfect sense...

  SO:  From a business standpoint, to START, a
customer and a sales rep.  At this point the SALES REP
interacts with the system, the CUSTOMER interacts with
the Sales Rep...(leaving out the old internet at this
point, eh?)...The Sales Rep interacts as the Starting
Actor.  As the Sales Rep interacts with the system
(and customer), OTHER Actors, such as The
Manufacturing System The Delivery System, et al..

If I'm on the right track we will continue...

IF I am anticipating correctly, we could eventually
build an internet Interface (for use by the customer)
to REPLACE the sales rep and invoke all of those
functions as services....IF we build them as services,
now..


Later,
And Thanks
John
--- Raja Mohan <[EMAIL PROTECTED]> wrote:

> Hi John,
> I suggest we will take a process that goes across
> many functions such as Planning, Order
> Management,Supply and delivery etc.
> 1. I propose to have a business process  ORDER
> ENTRYfor an assemble to order manufacturing and
> sales system.
> 2. sales rep receives the order for an assemble to
> order item (Computer). Sales rep calls the service
> orderentry from a order management application
> 3. The item computer need to be configured from
> various optional features available for computer
> (Such as Memory,disk space and minotor size). The
> sales rep must call the list of features and options
> available for computer from a configurator product
> which stored these data.
> 3. After selecting the features the sales rep needs
> to know the promising date for which he calls ATP
> from planning application to determine the possible
> delivery date.
> 4. Sales rep calls the pricing to determine the
> price of the selected computer based on the settings
> defined in the pricing data.
> 5. Once the customer is happy with the price and
> date of delivery the sales rep books order which
> calls for updating the sales order data in order
> management as well as the on order data in Inventory
> master.
> This may not be a best example of what really
> happens because there are many other things that
> happen at the time of order entry. But we can use
> this as a starting point.
> Do I make sense?
> regards,
> Raja Mohan
>
> John Hirsch <[EMAIL PROTECTED]> wrote:
> Keith/Jan
>
> I simply HAVE to jump in here to make an
> observation:
>
>   Kieth:  Are you saying that we've come full
> circle??
> The massive PROCESS ORIENTED systems we USED to
> build
> on the mainframes are now 'back in style'?  That my
> PROCESS ORIENTED skills are now worth something
> (again)?  My business ANALYSIS skills are now golden
> again?
>
> If NOT then what are you talking about? 
>
> Can we, as a group, analyze a specific problem and
> build some concepts that illustrate what we are
> talking about?
>
> If you need suggestions, I have them, I've worked in
> a
> number of different industries and know their
> BUSINESS
> processes fairly well:  Mortgages, Railroads, and
> Telco's.
>
> Thanks
> John Hirsch (with ancient skills)...
>
> --- Keith Harrison-Broninski
> <[EMAIL PROTECTED]>
> wrote:
>
> > Jan Algermissen wrote:
> >
> > >Keith,
> > >
> > >what exactly does it mean for an architectural
> > style to be 'process 
> > >based'?
> > > 
> > >
> > Here are some quotes from BPM author Martyn Ould
> > (slightly paraphrased
> > in places for readability):
> >
> > > The key thing about a paradigm shift is that old
> > ways of thinking just
> > > won't work in the new world. If your structural
> > engineers have only
> > > had mud to work with in the past, their ways of
> > specifying and
> > > designing buildings will be fine for mud
> buildings
> > but they won't make
> > > a lot of sense when the steel girder appears on
> > the scene. Today's
> > > dedicated follower of fashion in information
> > system development is
> > > likely to be speaking UML and using one of the
> > various development
> > > approaches based on the UML. [But] we cannot
> view
> > business process
> > > management systems as just another sort of
> > information system.
> > > Information-oriented languages and
> > information-oriented methods have
> > > evolved around a world of storing, retrieving,
> and
> > updating
> > > information, not the dynamic world of process.
> > >
> > > Simply extending our information-based methods
> > simply won't work -
> > > they don't have the necessary concepts at their
> > heart. We're moving
> > > from the Information Age to the Process Age. We
> > need purpose-built
> > > methods for working with processes to replace
> our
> > methods for working
> > > with information. The process-managed enterprise
> > demands that the
> > > center of automation be shifted from
> /information
> > processing/ to
> > > /process processing/. The traditional paradigm
> > views organizations as
> > > things that work with information, so our
> systems
> > have been about
> > > looking after information. In the past we have
> > specified our
> > > information systems in terms of what data they
> > will store and how we
> > > can access it and change it and move it around.
> > And we have designed
> > > our information systems in terms of data
> > representations and
> > > operations on data.
> > >
> > > Processes need an architecture and conceptual
> > framework of their own,
> > > not a data-oriented information systems
> paradigm.
> > While new
> > > "service-oriented" architectures and techniques
> > for software
> > > development offer flexible, loosely-coupled
> > approaches to computing,
> > > these advances, though good, are aimed at
> > technical people who build
> > > and manage information systems, e.g.,
> programmers,
> > not business
> > > analysts who want to build and manage business
> > processes. To this end,
> > > a modeling framework based on techniques
> > compatible with
> > > process-oriented architecture is needed to
> > supersede
> > > information-oriented approaches to process
> > modeling and analysis. This
> > > shift from the Information Age to the Process
> Age
> > in terms of
> > > architecture and methods will serve as the
> > cornerstone of BPM, now
> > > that the tinkering, tactical deployment phase is
> > moving on to
> > > strategic enterprise BPM.
> > >
> > My own approach to POA is couched in terms of
> Roles
> > and Interactions,
> > which bear a resemblance to swim lanes that is
> > purely superficial.  The
> > detailed semantics I propose are different to
> (say)
> > the UML and the
> > differences are very important!  As with any
> > architectural approach,
> > there are deep issues that must be addressed in
> > order to fashion working
> > computer systems - with processes, these issues
> are
> > not just IT-related
> > but extend into various other domains including
> not
> > only
> > business/management theory but also the "soft
> > sciences".
> >
> > HTH?  If not, I am always happy to write more on
> the
> > subject.
> >
> > --
> >
> > All the best
> > Keith
> >
>
=== message truncated ===



           
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com


Yahoo! India Matrimony: Find your partner now.

SPONSORED LINKS
Service-oriented architecture Computer monitoring software Computer and internet software
Free computer monitoring software

YAHOO! GROUPS LINKS



Reply via email to