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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
>
> > On 13/05/07, Jerry Zhu <[EMAIL PROTECTED]> 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 level
> > that
> > > is operational, BPM as functional, and BN as
> > > categorial. It is interesting to think what is
> > the IT
> > > capabilities at the level of BN. I think that
> > many
> > > questions and confusions Steve Jones has can be
> > answer
> > > at this level of abstructure. Many of the
> > confusions
> > > we experience in today's business world are due
> > to
> > > questions being asked at the wrong levels of
> > > abstraction.
> >
> > Business Needs are again just a facet of the
> > business, as are its
> > goals, its restrictions, its interactions, its costs
> > and opportunities
> > etc etc. When people re-organise businesses they do
> > it around a
> > "clump" of these related elements which they give a
> > general term to
> > "Supply Chain", "Finance", "Sales", "Catering" and
> > those things are
> > further broken down.
> >
> > Starting with these clumps (what I call business
> > services) helps to
> > put in place the buckets into which all of these
> > other elements can be
> > grouped. That is the power of business services in
> > that it gives a
> > contextual framework within which the concepts can
> > be quickly assigned
> > and related.
> >
> > Most of the issues I see with IT talking to business
> > is the instance
> > in doing it a single view of the business which is
> > based around the
> > current product set that they are looking at for
> > implementation. So
> > we talk BP because we want to use a BP modelling or
> > execution tool ,
> > we talk "class models" when we want to do OO and we
> > talk screen shots
> > while making up how the thing actually works.
> >
> > Hence I'd advocate using business language and
> > simplicity, because the
> > only way to represent complex things effectively is
> > to break the
> > problems down into simple bits.
> > >
> > > BTW, today's EA frameworks are fads in my view as
> > much
> > > as UP software development methodology is a fad.
> > They
> > > are fads becuase the practice of them are more
> > art
> > > than science, not much a discipline of
> > engineering.
> > > They are putting forward solutions to be selected
> > as
> > > chance events. Only a third are selected as a
> > success
> > > in software projects.
> >
> > Now here I'm with you. Not so much around UP as it
> > certainly
> > formalises and helps to provide an engineering
> > framework for
> > improvement, but I'm certainly there around the
> > scale of EA that is
> > required for a business. If the goal of EA is to
> > create a simple
> > clear and consistent image of the enterprise and
> > then help in the IT
> > delivery of it then its fine, if it becomes a goal
> > in itself (as BP
> > often does for instance) then it ceases to have a
> > point.
> >
> >
> > >
> > > Best to all,
> > >
> > > Jerry Zhu
> > >
> > > --- Jerry Zhu <[EMAIL PROTECTED]> wrote:
> > >
> > > > I found no disagreement with what you said. And
> > also
> > > > no conflict between my views. Only open to
> > termilogy
> > > > explanations.
> > > >
> > > > I should say :"... accessible and usable by IT
> > > > (aspect of BP)" Or "...by BP('s IT aspect)"
> > > >
> > > > And I should say: "This IT strategy is made
> > possible
> > > > only when we model business processes in SOA
> > way (at
> > > > the level of service abstraction)" "SOA way" I
> > mean
> > > > business modeling as service orientation not IT
> > > > architecture.
> > > >
> > > > We have discussed three levels of abstraction
> > so
> > > > far:BP, B Service (B sub-Ps), and B Activity.
> > Higher
> > > > level
> > > > units have lower level units as constituents.
> > Each
> > > > level may also be a hierarchy. One way to
> > understand
> > > > each level is to model it and multiple models
> > are
> > > > needed. They are business capability model, IT
> > > > capability model, and data model. The highest
> > level
> > > > of modeling is the architecture which is our
> > focal
> > > > point of discussion therefore B capabiity
> > > > architecture
> > > > and IT capability architecture at each level.
> > So we
> > > > have top-down three pairs of business and IT
> > > > architecture models: (BP architecture, BMP), (B
> > > > service architecture, SOA), and (B Actvity
> > > > Architecture, OOA)
> > > >
> > > > B architecture is the meat at each level and IT
> > > > architecture at each level is the skin. How
> > models
> > > >at different levels of abstraction meet? Skin
> > touches
> > > > skin. So OOA is used by SOA that is used by
> > BPM.
> > > > How business architectures at different levels
> > meet?
> > > > They do not meet but encapsulated at each
> > level. Or
> > > they are modeled independently. At BP level, it
> > does
> > > not limit how business processes are internally
> > > modeled whether it is SO or OO.
> > > >
> > > > When we agree on this, we would be able to move
> > up
> > > > to next level of abstraction.
> > > >
> > > > Regards
> >
> === message truncated ===
>
>
