Loading ...
Sorry, an error occurred while loading the content.
 

RE: [service-orientated-architecture] Re: BPM & SO

Expand Messages
  • Simon Plant
    How about multiple layers of services, which include a Process as a Service? Process services (composites) à Business Services (Task, entities) à Application
    Message 1 of 85 , Apr 30, 2007

      How about multiple layers of services, which include a Process as a Service?

       

      Process services (composites) à Business Services (Task, entities) à Application Services (COTS, function, utility, etc)

       

      Simon

       

       

      From: service-orientated-architecture@yahoogroups.com [mailto:service-orientated-architecture@yahoogroups.com] On Behalf Of Steve Jones
      Sent: Sunday, April 29, 2007 1:05 PM
      To: service-orientated-architecture@yahoogroups.com
      Subject: Re: [service-orientated-architecture] Re: BPM & SO

       

      I'm not buying the Process is a higher level of abstraction than service.  Lets put it this way

      General Electric offer me a service as a shareholder, there is a defined contract and a defined value and a defined set of interactions.  In otherwords its the entire General Electric company that I'm interacting with.  This isn't even the most abstract service I can think of, take the UN, EU or whatever all can be, fairly easily, described as a service.

      You can't describe a business just in terms of its processes.


      On 28/04/07, Jerry Zhu <jerryyz@... > wrote:

      Form business people's perspective, yes, SOA and BPM
      are the same thing. From IT people's perspective,
      they are different as much as they are different
      between OO and SOA.

      We often say that Service is higher level of
      abstraction than Objects. In the same line, Processes
      in BPM is higher level abstraction than Service. Both
      business logic and infrustracture units at these
      different levels of abstraction are different. I see
      BMP is the highest level of abstration in the
      evolution of IT started from machine language 0's and
      1's.

      Jerry

      --- Todd Biske <todd.biske@...> wrote:

      >
      > On Apr 27, 2007, at 8:51 AM, Robin wrote:
      > >
      > >
      > > What I say is that my business decision makers
      > don't understand why
      > > they should invest in SOA if it does not help them
      > to optimize their
      > > business processes, so they tend to consider that
      > BPM and SOA are one
      > > same thing. I don't know how far this thinking is
      > the result of vendors marketing.
      > >
      >
      > This is consistent with the statements that came out
      > of the SOA
      > Consortium Executive briefings. The CIOs
      > participating pretty much
      > said the same thing, as the first of the five
      > published insights was
      > that "There should be no artificial separation
      > between BPM and SOA."
      >
      > -tb
      >

      __________________________________________________
      Do You Yahoo!?
      Tired of spam? Yahoo! Mail has the best spam protection around
      http://mail.yahoo.com

       

    • Jerry Zhu
      Steve, Let me continue. Dependency in the direction of stability and separation of concern of IT and business have profund implications in our approach of
      Message 85 of 85 , May 31, 2007
        Steve,

        Let me continue. Dependency in the direction of
        stability and separation of concern of IT and business
        have profund implications in our approach of
        modelings.

        We first model the most stable, hence the most
        independent, level to its completion. This level is
        at the bottome hence foundational. Secondly we model
        next level that depends only on the foundational level
        to its completion. This modeling process continues
        until all levels of abstraction are modeled.
        Accordingly we have a hierarchy of models that is
        complete without scrap and rework.

        This means we model business as outside-in or top-down
        and model IT bottom-up or inside-out. Because IT
        depends on business therefore we first model business
        top-down from most abstract to most concrete to its
        completion and then model IT bottom-up from most
        concrete to most abstract. Because we have modeled
        business top-down thoroughly, we have the knowledge
        and competence to model IT bottom-up that maximizes
        reusability, interoperability and adaptiability.

        Jerry

        --- Steve Jones <jones.steveg@...> wrote:

        > So you aren't saying so much stable from an IT
        > perspective as intransigent,
        > which I certainly agree with. This is the real
        > challenge of IT, the
        > mis-match between business objectives which want to
        > be flexible at the end
        > and IT systems which are rooted in concrete.
        >
        > I feel a blog post coming on :)
        >
        > Steve
        >
        > On 16/05/07, Jerry Zhu <jerryyz@...> wrote:
        > >
        > > I agree with your business perspecive view that
        > lower
        > > level depends on higher level. A strategic change
        > on
        > > top will impact organization units below, not the
        > > other way around. Therefore higher levels are more
        > > stable than lower levels.
        > >
        > > Dependency is in the direction of stability, less
        > > stable ones depend on more stable ones.
        > >
        > > As this forum stated many times to separate
        > concerns
        > > of business from concerns of IT. My talking about
        > > stability is in IT perspective. Higher level
        > depends
        > > on lower levels. That is why we still keep these
        > > lagecy systems for long time by exposing their
        > > functions as services. So from IT pespective, high
        > > level components (less stable) depend on low level
        > > ones (more stable). Services should be more stable
        > > than BPs because BPs depend on services for their
        > > creation.
        > >
        > > Regards
        > >
        > > Jerry
        > >
        > > --- Steve Jones <jones.steveg@...
        > <jones.steveg%40gmail.com>> wrote:
        > >
        > > > I'm still a bit confused at the stability bit
        > having
        > > > worked with lots of different businesses. The
        > key
        > > drivers for change tend to come from
        > > > the highest levels and these have the largest
        > impact
        > > > on the lowest levels (e.g. "We are getting out
        > of
        > > distribution and outsourcing that
        > > > to a 4PL"). So most companies I've worked with
        > are
        > > > pretty stable at the top (the know they are an
        > > > airline/manufacturer/bank/IT/Shipping/etc
        > company)
        > > > but its lower down
        > > > that the rate of change becomes greater.
        > > >
        > > > How do you mean that the company
        > > strategy/service/need of the non-executive board
        > > depends on the lower level elements? For me it
        > > > appears to be the other way around.
        > > >
        > > >
        > > > On 16/05/07, Jerry Zhu <jerryyz@...
        > <jerryyz%40yahoo.com>> wrote:
        > > > >
        > > > >
        > > > >
        > > > >
        > > > >
        > > > >
        > > > > I agree outside in approach when looking at
        > > > business.
        > > > > If inside out it would be too slow or unable
        > to
        > > > > understand the business. I am talking about
        > > > concepts
        > > > > and symbols to describe business. The more
        > > > outside
        > > > > the business the larger context the more
        > > > abstraction
        > > > > required to describe. So there are levels of
        > > > > abstraction in describing business and each
        > level
        > > > of
        > > > > abstraction uses different concepts and
        > symbols.
        > > > > Objects, Services, and BPs use different kinds
        > of
        > > > > concepts and symbols. When we look outside in
        > > > level
        > > > > by level we use these concepts and symbols of
        > > > each
        > > > > level.
        > > > >
        > > > > I am talking about building these conceps and
        > > > symbols
        > > > > inside out level by level, not looking at
        > > > business
        > > > > inside out. This is because higher level
        > > > concepts and
        > > > > symbols depend on concepts and symbols of the
        > > > lower
        > > > > level. Services needs objects for their
        > > > > implementation. So we need to know what
        > objects
        > > > are
        > > > > before services. So we build concepts and
        > > > symbols
        > > > > inside out to be able to look at business
        > outside
        > > > in.
        > > > >
        > > > > Clumps are business needs, buckets are
        > services,
        > > > > elements in the buckets are objects. So they
        > are
        > > > at
        > > > > different levels of abstraction and have
        > > > different
        > > > > length of life cycles. The higher level the
        > less
        > > > > stable and lower level the more stable. Hence
        > > > higher
        > > > > level depends on the levels below.
        > > > >
        > > > > Jerry
        > > > >
        > > > > --- Steve Jones <jones.steveg@...
        > <jones.steveg%40gmail.com>>
        > > wrote:
        > > > >
        > > > > > On 13/05/07, Jerry Zhu <jerryyz@...
        > <jerryyz%40yahoo.com>>
        > > > wrote:
        > > > > > >
        > > > > > >
        > > > > > >
        > > > > > >
        > > > > > >
        > > > > > >
        > > > > > > Sometimes my fingers do not catch up with
        > the
        > > > > > scope of
        > > > > > > my brain. My brain says that when we have
        > > > some
        > > > > > common
        > > > > > > understanding along these lines we can
        > move
        > > > up to
        > > > > > EA.
        > > > > > > but not to conform to what I typed below.
        > (
        > > > I
        > > > > > hope I
        > > > > > > do not turn people off) Because higher
        > > > level
        > > > > > concepts
        > > > > > > depend on concepts of the lower levels. So
        > > > > > conceptual
        > > > > > > accuracy of the lower levels must be
        > reached
        > > > > > before
        > > > > > > attaining that of higher levels.
        > > > > >
        > > > > > Thus doesn't make sense to me. This seems to
        > > > say
        > > > > > that a CEO can't
        > > > > > have a business strategy before the catering
        > > > > > department knows what it
        > > > > > is doing. Now clearly you aren't saying that
        > > > but
        > > > > > why do you think
        > > > > > that higher level concepts need the lower
        > level
        > > > > > elements to be defined
        > > > > > first? To me, when looking at businesses,
        > its
        > > > > > completely the other
        > > > > > way around.
        > > > > >
        > > > > > >
        > > > > > > The question I was thinking for quite a
        > > > while is,
        > > > > > waht
        > > > > > > is the unit of analysis at the level of
        > > > > > abstraction
        > > > > > > above BP? My thought is Business Needs
        > that
        > > > > > > categorizes BPs. Each category of BP
        > > > contains
        > > > > > many
        > > > > > > types of BPs. This level of abstraction is
        > > > not
        > > > > > > functional but categorial. So we have SOA
        >
        === message truncated ===
      Your message has been successfully submitted and would be delivered to recipients shortly.