Glad you found the article useful, Ash.
Reading your response, I saw that two of the links in my original reply
actually pointed to the same URL, by mistake. The BPTrends.com article
introducing HIM that I mentioned can actually be found here
<http://www.bptrends.com/deliver_file.cfm?fileType=publication&fileName=SEVEN%20Harrison-Broninski%20Column%20Nov%202007.pdf>.
My next column for the site will be published in early Jan and directly
addresses the question of SOA/HIM integration.
--
All the best
Keith
http://keith.harrison-broninski.info
ash galal wrote:
Hi Keith
Thank you very much for this great resources. I will
read them and come back to you for questions of
course.
By the way I cited your article "Broninski, Keith.
(2007) Taming the Minotaur: how to integrate
organizational management with the IT backbone. Ebiz -
The Insider's Guide to Business Integration.
[Online] Available from:
<http://www.ebizq.net/blogs/it_directions/archives/2007/02/taming_the_mino.php
<http://www.ebizq.net/blogs/it_directions/archives/2007/02/taming_the_mino.php>
> (Accessed: 12 Feb. 2007)" in my master degree
dissertation because it was the first article
addressed this issue.
The following is what I wrote in the dissertation:
"The problem in our opinion related to the burden we
try to add every day to SOA.
SOA on its own, like BPM, is a technical advance, not
a business advance (Broninski, 2007). We have to
prepare our business to apply SOA in a proper way to
achieve the specified goals.
First, we have to build process architecture to unite
business goals with business processes. Next, apply
human interaction management (HIM) to make best use
of the human in the organization in order to leverage
the skills that any organization has on board. The
organization can gain the dual advantages of
structure (for efficiently) and agility (for
responsiveness). The final step before having SOA in
the picture, use BMP/workflow to improve
organization's
performance to mechanistic work. Finally, (and only at
this point should SOA enters the picture), look at the
processes organization has defined, both human-driven
and mechanistic and ask which of these could make use
of services. By following this approach, you will
end up not only with a true picture of your
organization, but also with a picture that you can use
for immediate practical purposes. The system thus
defined will match your strategy, via process
architecture. It will match your organization
chart, via HIM levels of control. It will lead to true
process-orientation, for both kinds of work
(human-driven and mechanistic). And it will allow you
to optimize as much as possible, via the use of SOA.
(Broninski, 2007)"
I do agree with you. This is the way if we want SOA to
successfully achieve its goal.
All the best
Ash Galal
--- Keith Harrison-Broninski <[EMAIL PROTECTED]
<mailto:tech%40rolemodellers.com>>
wrote:
> Ash
>
> This is the domain of *Human Interaction Management*
> (as opposed to BPM
> which deals with routine, semi- or fully-automated
> work).
>
> 1. There is a general introduction to HIM in this
> column for BP
> Trends
> <http://human-interaction-management.info
<http://human-interaction-management.info>>.
> 2. You can find an overview of HIM at the HIM Web
> site
> <http://human-interaction-management.info
<http://human-interaction-management.info>>.
> 3. Process modelling and enactment software
> supporting HIM is
> available free <http://humanedj.com <http://humanedj.com>>.
>
> --
> All the best
> Keith
>
> http://keith.harrison-broninski.info
<http://keith.harrison-broninski.info>
>
>
>
> ash galal wrote:
>
> > From my background and experience, I found out
> that
> > most of business processes tend to be informal and
> > subjective which is very difficult to quantify.
> > We need to quantify such features of the business
> > processes to enable automatic business processes
> > composition.
> > But this is very challenging, because we need to
> > properly formulate the descriptive and subjective
> > requirements into quantifiable, objective, and
> > machine-readable formats. In addition, the current
> Web
> > services specifications lack the facility to
> define
> > comprehensive relationships among business
> entities,
> > business services, and operations. Without such
> > relationships we will not been able to optimize
> > business process composition. Which I think it is
> out
> > of SOA architecture. It is business architecture
> may
> > be. Any ideas?
> > I noticed also that this part is almost ignored by
> > vendor's reference architecture or white papers
> but
> > only addressed by IBM SOA reference architecture
> to
> > some extent.
> > I think this area needs more researches and I
> think it
> > needs business people, not business analyst, who
> have
> > practical business experience, work hand-on-hand
> with
> > IT architects.
> > I don't think that any W3C or OASIS specifications
> for
> > WS-* can address such area since OASIS SOA
> definition
> > is a technical one.
> > Your comments is highly appreciated
> >
> > Ashraf Galal
> >
> >
>
>
