Yes, you can use AquaLogic without SOA. If you have perience on this. Can you tell the difference between with and without SOA?
Jerry --- Oron Haus <[EMAIL PROTECTED]> wrote: > BPM has been successful. Even with SOA BPM will > fail if the project > is too large and too ambitious. You don't need SOA > to do BPM. SOA, > if executed correctly in an organization, can offer > more 'services' > to consume by activities. There is no reason you > couldn't use > AquaLogic BPM Suite without an SOA. > > Gill Haus > > --- In > [email protected], > Jerry Zhu > <[EMAIL PROTECTED]> wrote: > > > > Thank you, Shashank, for the excellent article. > It > > reflects my view well except a small portion that > is > > SOA being an architecture for BMP. My take on > this > > and in general is that 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 abstraction are ontologicially and > > sementically distinct and are not overlapping in > > representation of reality. > > > > Jerry Zhu > > > > > > > > --- "Shashank D. Jha" <[EMAIL PROTECTED]> wrote: > > > > > Above was quote from article by Ismael Ghalimi > > > available at > > > > > > http://itredux.com/blog/2006/08/13/bpm-is-soas-killer-application/ > > > > > > regards, > > > Shashank D. Jha > > > > > > On 5/5/07, Shashank D. Jha <[EMAIL PROTECTED]> > > > wrote: > > > > > > > > From a business standpoint, a service is too > small > > > a unit to really appeal > > > > to the business side of the house. Its > granularity > > > is too fine. And it's > > > > only when elevated to the level of processes > that > > > business folks usually > > > > start paying attention. Reusing a currency > > > conversion service across > > > > multiple applications, and saving three > man-month > > > of development along the > > > > way, is one thing. Being able to shave three > weeks > > > in the overall > > > > order-to-cash process is another. Guess which > of > > > the two will get the CFO's > > > > attention? > > > > > > > > So you wish that business people to work with > > > lesser abstraction based on > > > > SOA!! And this is a new idea supported by > > > Microsoft, then this has lesser > > > > chances of success. > > > > > > > > BP running on top of SOA infrastructure sounds > > > more realistic vision of > > > > achieving success for both BPM and SOA. Ps > note > > > that SOA is an initiative by > > > > IT not business people. > > > > > > > > regards, > > > > Shashank D. Jha > > > > > > > > > > > > On 5/4/07, Steve Jones <[EMAIL PROTECTED]> > > > wrote: > > > > > > > > > > On 04/05/07, Shashank D. Jha > > > <[EMAIL PROTECTED]<shashank.dj%40gmail.com>> > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am not sure if I have understood the > stated > > > correctly. So what your > > > > > are suggesting here are two things- > > > > > > > > > > > > 1. Business as a set of process is at a > lower > > > level of abstraction > > > > > than business as a set of services? > > > > > > > > > > Yes > > > > > > > > > > > > > > > > > 2. BPM is one of the implementation > approach > > > for SOA? > > > > > > > > > > Yes > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 4/30/07, Steve Jones > > > <[EMAIL PROTECTED]<jones.steveg%40gmail.com>> > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think in part this nicely sums up one > of > > > the challenges that we > > > > > have today, namely that a lot of SOA isn't > > > architecture (which should be > > > > > business focused) its design focused (which > > > would be SOD) around technical > > > > > implementations. There is a sort of a > tiering of > > > elements here which is > > > > > > > > > > > > > > SOD = Web Services and development > > > boundaries > > > > > > > BPM = Cross Web Service processes > > > > > > > > > > > > > > In this view BPM conceptually sits > "above" > > > SOA, and is hugely pushed > > > > > by technology vendors as it fits well with > the > > > stack based thinking (App > > > > > Server/.NET, Development, Web Services, > BPEL) > > > which makes selling products > > > > > easier. This is the traditional IT product > > > oriented way of thinking. > > > > > > > > > > > > > > The other SOA is the architectural one > which > > > views the business as a > > > > > set of services and then takes that view as > a > > > mechanism for the > > > > > re-organisation of IT, projects and > management > > > to become more business > > > > > focused. In this view BPM is an > implementation > > > approach for certain types of > > > > > IT services or is a measurement mechanism > for > > > services ( e.g. Sales). > > > > > This is (to me) the new way of thinking that > SOA > > > allows. This is beginning > > > > > to be seen in vendor's products (e.g. > Microsoft > > > Motion, IBM's CBM) but > > > > > is early days so isn't overly pushed within > the > > > marketing hype yet. > > > > > > > > > > > > > > Steve > > > > > > > > > > > > > > > > > > > > > > > > > > > > > === message truncated ===
