"...IT systems which are rooted in concrete" because of stubborn habit of doing
only what is asked today like there will be no tomorrow. This is called
concrete, yes, but concrete is the perfect ballast to get drowned as well as a
means used by Mafia to eliminate undesired guys, however, for IT, it is a sort
of self-service.
When we finally understand that the power is not in 'concrete' but in
flexibility?
IT has perfect technologies for the flexibility but acts quite stupid waiting
for the business to require them. Business has no clue about it, they have just
tacit knowledge which IT must unleash (to survive) using flexible, ready for
changes solutions.
- Michael
Steve Jones <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[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.
> > >
>
=== message truncated ===
---------------------------------
Boardwalk for $500? In 2007? Ha!
Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.
