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
> >
> > Jerry
> >
> >
> >
> >
> >
> > --- "Shashank D. Jha" <[EMAIL PROTECTED]> wrote:
> >
> > > I agree with your view expressed earlier
> > > --start
> > > SOA is the architecture at the level of service
> > > modeling. The implementation
> > > of Services maybe using OO that needs another
> > > architecture at different
> > > level of abstraction. In other words, we need
> > > different architectures at
> > > different levels of abstraction.
> > >
> > > So we need a BMP architecture as much as we need a
> > > architecture at
> > > service level abstraction. Architectures at
> > > different levels of
> > > abstractionare ontologicially and sementically
> > > distinct and are not overlapping in
> > > representation of reality.
> > > --end
> > >
> > > Your this view slightly contradicts the scope of
> > SOA
> > > as mentioned in this message.
> > >
> > > If BMP architecture decides to meet IT
> > architecture
> > > (based on SOA) I will definitely qualify that as
> > one
> > way of doing Enterprise Architecture (EA).
> > > Certainly not SOA.
> > >
> > > I agree with Steve when he says
> > > ---start
> > > Which to me is the dust, because we've been there,
> > > done that and
> > > failed a whole load of times. CICS was the same,
> > MVS
> > > (IIRC) was the
> > > same, CORBA was the same, EAI was the same, DCOM
> > was
> > > the same and now
> > > we have WS.
> > >
> > > For SOA to actually matter it must change the way
> > > people think, and
> > > neither BPM nor SOA 4 IT is capable of achieving
> > > that.
> > > ----end
> > >
> > > But if we want to achieve what he and we all want,
> > > that enterprise must have
> > > seamless integration between BP and IT
> > > infrastructure we need to change our
> > > approach, towards enterprise as a whole and
> > organize
> > > all the activities and
> > > process within an organization within a common
> > > framework, which according to
> > > some is SOA, but I think that is EA.
> > >
> > >
> > > regards,
> > > Shashank D. Jha
> > >
> > > On 5/10/07, Jerry Zhu <[EMAIL PROTECTED]> wrote:
> > > >
> > > > I correct what I said below as ... reusable by
> > > BP.(not
> > > > IT)
> > > >
> > > > It is interesting to diferentiate IT capability
> > > from
> > > > business capability. Business capabilities are
> > the
> > > > driving factor and requirements of IT
> > > capabilities.
> > > >
> > > > So when we say SOA, we mean both SOA business
> > and
> > > IT
> > > > capabilities. In SOA, services are defined as IT
> > > > assets that encapsulate business capabilities
> > (of
> > > > certain business granularity) accessbile over
> > > network
> > > > and can be assembled and reassembled to form
> > > business
> > > > processes (larger business granularity than
> > > service).
> > > > SOA is IT strategy that make services standard
> > > based,
> > > > interoperable and reusable. This IT strategy is
> > > made
> > > > possible only when we model business processes
> > in
> > > SOA
> > > > way. So SOA is also a business strategy in
> > > business
> > > > process modelings.
> > > >
> > > > So I agree what you say below.
> > > >
> > > > Jerry
> > > >
> > > > --- "Shashank D. Jha" <[EMAIL PROTECTED]
> > > <shashank.dj%40gmail.com>>
> > > > wrote:
> > > >
> > > > > Can I say that SOA is IT capability which will
> > > be/is
> > > > > used by BP?
> > > > >
> > > > > regards,
> > > > > Shashank D. Jha
> > > > >
> > > > > So SOA is not just dust but business
> > > capabilities
> > > > > > enabled by IT and made accessible and
> > reusable
> > > by
> > > > > IT.
> > > > > >
> > > > > > Jerry
> > > > > >
> > > > > > --- Steve Jones <[EMAIL PROTECTED]
> > > <jones.steveg%40gmail.com>
> > > > > <jones.steveg%40gmail.com>> wrote:
> > > > > >
> > > > > > > I have to disagree here Jerry, Business
> > > Process
> > > > > is
> > > > > > > a long way away from being the only way
> > that
> > > > > value
> > > > > > is _generated_ within a business. When
> > people
> > > > > > > interact with businesses they tend to
> > > interact
> > > > > at
> > > > > > > specific points, these tend to be marked,
> > > and
> > > > > indeed
> >
> === message truncated ===
>
>
