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 > 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 ===
