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
> > the sequencing of the process, it may be some
> > business rule change.
> > If both a Java/C# approach or a BPEL approach can
> > leverage a rules
> > engine, they both may be able to support the
> change.
> > Whether it's
> > code or BPEL, the effort is still a development
> > activity. We're
> > nowhere near the point where some business user
> is
> > modifying BPEL
> > directly, so you're going to go through the IT
> > release process no
> > matter what.
> >
> > The last factor I can think of is management. A
> BPM
> > suite may have
> > better management capabilities for showing
> relevant
> > business
> > information. This is probably a woefully
> > under-leveraged capability,
> > however. How many applications today are
> > instrumented to show
> > relevant business information? It's simply not
> > something IT is used
> > to providing, and so it's probably something that
> > hasn't been
> > requested by the business nor has it been
> advertised
> > by IT.
> >
> > As for my opinion, I've seen a few enterprises
> where
> > a BPEL engine
> > could be justified solely on development
> efficiency
> > alone. It had
> > nothing to do with automated processes, it had
> more
> > to do with
> > availability of pre-defined activities and how
> well
> > the typical
> > programmatic tasks matched those activities. If
> > you're simply doing
> > a lot of data-in / data-out type processing, why
> are
> > you writing a
> > whole bunch of code for it? Of course, you could
> > some of the good
> > code generators out there to obtain very similar
> > efficiencies, so
> > there are multiple paths.
> >
> > The one other thing that I'd add is that when
> > organizations start
> > looking at true BPM, which involves human
> activities
> > and task
> > management, I do think they'll need to bring in
> some
> > specialized
> > technology. I hope the technology has improved
> by
> > then, but I don't
> > think writing a whole bunch of code is well
> suited
> > for that
> > approach. I don't want to be replicating a task
> > management engine in
> > all of my applications.
> >
> > -tb
> >
> >
> >
> > On Apr 25, 2007, at 2:09 PM, Stefan Tilkov wrote:
> >
> > > I was in a panel discussion at a conference
> this
> > week, and was
> > > surprised to notice there's still no consensus
> > about whether or not a
> > > process engine (or rather, support for
> automated
> > BPM) is a "must" for
> > > SOA.
> > >
>
=== message truncated ===
---------------------------------
Ahhh...imagining that irresistible "new car" smell?
Check outnew cars at Yahoo! Autos.
