Unfortunately, not, Jerry, while I tend to agree with your explanation over all.
My point, and you perfectly described it, is that OO does not provide enough
abstraction to model real business world today.
The "...business and IT aliance is not what we struggle to do, but a
nature evolution of IT" can happen only if we struggle to do it. If we stop
design IT solutions to the business requirements like they are the last
absolute truth and came to us (IT) every time suddenly, from the blue, we can
start build services as entities that are ready for changes in the scope of our
business models.
The struggle here is with those who do not want to do it due to any reasons.
- Michael
Jerry Zhu <[EMAIL PROTECTED]> wrote: OO
business concept for OO is not as important as SOA
business concept for SOA. In other words, as we move
up in abstraction, business model becomes increasing
important, hence increasing business and IT aliance.
The higher abstraction the more inclusive, the more
business aspects IT includes. OO includes business
activities, a level below operation and hence does not
address operational goals. Or operational aspects of
business are not part of unit of analysis of IT.
therefore business and IT aliance are at the level of
business actvities. Whether IT meets business goals
is not in the conversation.
As we move up to SOA, service, the unit of analysis,
includes subprocess, or operational modules,starts to
address operational goals. Hence greater business and
IT alliance.
As we continue move up to BPM, the unit of analysis
becomes business process that adresses strategic
goals. Therefor business strategy is part of
discussion of IT implementations. Therefore business
and IT aliance is not what we struggle to do, but a
nature evolution of IT.
I hope I answered your questions, Michael. If not,
feel free continue to explore. It is fun and that is
why we do it.
Jerry
--- Michael Poulin <[EMAIL PROTECTED]> wrote:
> Just out of curiosity, can anybody point me to an
> example of live "OO
> business concept"?
>
> I would agree with Jerry - we have the disconnection
> between the business and IT now (and trying to fix
> it using SOA) partially because IT evangelized OO
> and has forgotten to tell business that "We must
> have OO business concept for object technologies to
> be useful"...
>
> - Michael
>
> Jerry Zhu <[EMAIL PROTECTED]> wrote:
> --- Michael Poulin
> <[EMAIL PROTECTED]> wrote:
>
> > When we say BPM, what it stands for (for IT and
> for
> > business): business process management or
> modeling?
> >
> > - Michael
>
> Michael,
>
> I think that business concept must be hand in hand
> with coresponding technology suites. We must have
> OO
> business concept for object technologies to be
> useful.
> We must have functional decomposition business
> concept for procedural languages to be useful. We
> must
> have concpet of how machine operates for Assembly
> language to be useful. We must have BPM business
> concept (activity/performance mornitoring
> management,
> customer satifaction, strategic/business alliance
> etc)
> for BPMN, BPEL etc to be useful.
>
> The evolution of IT is growing abstraction from 0's
> 1's (no abstraction) to BPM (the highest
> abstraction).
> Each level has corresponding modeling units such
> functions for functional orientation, objects for
> OO,
> services for SOA and processes for BPM. Higher
> level
> units have lower units as constituents. Therefor
> higher level units are more abstract. The more
> abstract the larger idea it is the more ground it
> covers, and the higher performance, the better
> longevity, and higher quality.
>
> Infrastructure capabilities (code to be configured
> not
> programmed) grow in size as we move up in
> abstraction.
> At BPM level, 70% of code are infrastructure code.
>
> Each level has different set of infrastructure
> capabilities. SOA capabilities are differnet from
> that
> of BMP. I think that capability models at both SOA
> and BPM are not elaborated and work on in the
> industry yet.
>
> Jerry
>
> >
> > Jerry Zhu <[EMAIL PROTECTED]> wrote:
>
> > What I want to say here is to
> pay
> > attention to the
> > evolution of technology, different technology
> > capabilities address issues at different levels
> of
> > abstraction. Using C++/Java code to do what
> BPEL
> > does
> > is like using Assembly to do polymorphism.
> >
> > The nature of development activities has changed
> > from
> > 0's and 1's, to assembly, to procedure, to OO,
> to
> > Service Orientation to BPM. The latest is
> graphical
> > design. they are not new ones replacing the old
> > ones,
> > but should coexist, There are still 1's and
> 0's,
> > assembly, procedure, OO, and Services to
> implement
> > BPM. This is my preference, one may implement
> BPM
> > using C and skip OO and SO. I think that skip
> some
> > of
> > the levels of abstruction may be quick to
> develop
> > but
> > miss future advantage such as reusability or
> > agility
> > or ability to change. For example if we build
> > service
> > using COM objects or Java beans, we could reuse
> > them
> > to implement new services instead doing
> everything
> > from scratch.
> >
> > Jerry
> >
> > --- Todd Biske <[EMAIL PROTECTED]> wrote:
> >
> > > As always, I separate out the technical issues
> > from
> > > the non-technical
> > > ones. From a non-technical perspective, I
> don't
> > > think you'll get the
> > > full benefits of SOA unless you're also
> thinking
> > > about business
> > > processes. From a business standpoint, they
> are
> > at
> > > worst
> > > complementary, and in my opinion, should be
> > treated
> > > as one in the
> > > same. We hear a lot about BPM being the
> business
> > > thing, and SOA
> > > being the IT thing, and I think that's an
> > artificial
> > > separation.
> > >
> > > As for whether or not a process engine is
> needed,
> > I
> > > don't think any
> > > piece of technology is a "must." If an
> > organization
> > > doesn't have a
> > > BPEL engine, what's the alternative? Probably
> > > writing Java or C#
> > > code. Why would it make sense to use a BPEL
> > engine
> > > instead of
> > > writing code? The tools that I've seen all
> > leverage
> > > graphical
> > > designer, which theoretically could be far
> more
> > > efficient for
> > > building certain things than writing code.
> That
> > > comes with a
> > > flexibility penalty, however, in that there's
> > going
> > > to be some logic
> > > that just isn't well suited for it. If you
> find
> > > yourself writing
> > > custom actions in Java, you should asking
> whether
> > or
> > > not the whole
> > > thing should be in Java. If the custom action
> > has
> > > broad
> > > applicability, such as a custom integration
> > adapter,
> > > then it may not
> > > be such a bad thing, but if it's only used by
> > this
> > > process, you've
> > > probably just negated the time-to-develop
> > benefit.
> > >
> > > Another reason touted for leveraging BPEL is
> time
> > to
> > > change.
> > > Theoretically, if it's faster to do
> development,
> > > it's faster to
> > > change it. There's two questions to ask here:
> 1)
> > > Will the process
> > > change? If the process changes infrequently,
> > then
> > > it really doesn't
> > > matter. 2) What type of changes occur? The
> > change
> > > may not even be
>
=== message truncated ===
---------------------------------
Ahhh...imagining that irresistible "new car" smell?
Check outnew cars at Yahoo! Autos.
