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

Re: [service-orientated-architecture] BPM

Expand Messages
  • 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 1 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 ===
    • 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.