I am looking forward to seeing your blog. Do we still have differences to talk about? Anyone?
Jerry --- 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] > <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 <[EMAIL PROTECTED] > <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 <[EMAIL PROTECTED] > <jones.steveg%40gmail.com>> > > wrote: > > > > > > > > > On 13/05/07, Jerry Zhu <[EMAIL PROTECTED] > <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 ===
