Hi Marc,
Exactly, BPM/SOA integration is much more than a technical challenge and it does indeed require consistent governance. Which in turn requires good integrated tooling J And so naturally, in an Eclipse TLP we can focus on this challenge.
Perhaps during a future meeting (Eclipse CON Europe/US) we could discuss these things face to face and also raise the point about a potential change in name...
Cheers,
Adrian.
From: Marc Dutoo [mailto:marc.dutoo@xxxxxxxxxxx]
Sent: mardi 5 juillet 2011 12:40
To: SOA PMC mailing list
Cc: Mos, Adrian
Subject: Re: [soa-pmc] Separate BPM and SOA.
Hi Mickael, Adrian
Interesting discussion indeed...
Mickael, you say "BPM and SOA are different things. [...] For BPM, SOA simply means that your BPM engine and tools will be able to consume services". As you can guess, I readily agree :)
Adrian, you say that "BPM and SOA should be integrated". I also am of the opinion that BPM is SOA's killer app, or to say it differently : SOA services are to be consumed (i.e. injected, aggregated, mashuped, orchestrated...) as much as possible, and there is no way more powerful and closer to business needs than BPM.
But I also think that the key point of a good integration of BPM and SOA is not technical, but rather on consistent governance and management on both sides of processes and services, which is to say on making BPM a good SOA citizen.
All of that leads me to think that the SOA TLP is about "managed & integrated service oriented architectures" rather than merely about services. Of course, I'm not partial (*) in thinking that governance (versioning, dependencies management & compatibility of service providers & consumers...) should have a bigger part in the SOA TLP, but think about it, I may be right...
Regards,
Marc
(*) http://www.slideshare.net/mdutoo/eclipse-democamp-eclipse-to-easysoa-core
Le 05/07/2011 11:17, Mos, Adrian a écrit :
Hi Mickael,
Thank you for your message, this is an interesting point and worth to be discussed.
I agree that SOA and BPM are different things, and I think this is something most people would agree with. There are 2 points in your email:
The name of the Eclipse SOA TLP (it indicates SOA but it also contains BPM stuff)
Whether or not SOA and BPM should be integrated in the same Eclipse project.
I’ll start with the name: yes, maybe SOA is a bit confusing because it can be seen as limiting. There are several reasons why we got to this name, but I agree there is a case to perhaps change it to something that symbolises more than just SOA.
On your second point though, I am of the opinion that SOA and BPM should be integrated, and in fact this is perceived as one of the main challenges today in the field. Companies need to have a strong SOA base and a strong BPM methodology and these two MUST be integrated. You can obviously have one without the other but this brings a lot of limitations. This is in fact perceived in the commercial offers of many large players, where they try to integrate the two paradigms as well as possible. Sure, for small companies using (for now) one of the 2 (either some SOA runtime or some BPM engine), this is not a problem, they can still ‘choose’ because in many SOA or BPM offerings there is some degree of hybridization that brings ‘enough’ capabilities for limited environments. However, large enterprises that have important investments in both SOA and BPM (or in one of them but with plans to tackle the other as well), it is important that the two be very well integrated.
So yes, they should be in the same top-level project because this facilitates integration (both conceptual and practical). Again, on the question of name of the TLP, this is something that the PMC should probably re-consider at some point.
Cheers,
Adrian.
Hi all,
I have started reading the soa-pmc mailing-list a very few weeks ago, but I've followed what happens in the BPM and SOA landscape at Eclipse for the last few years.
I have some experience on both SOA and BPM, and I'd like to start a debate here that I hope will lead to conclusions that will make easier for people to consume BPM and/or SOA.
In my opinion, this is a confusing idea to have one top-level SOA project that provides pure-BPM things. BPM and SOA are different things, either in term of goal, expectations, and technologies. People can use BPM without SOA, people can use SOA without BPM.
Of course there are some integrations that are possible, but the coupling is not strong enough to merge SOA and BPM at Eclipse. Having BPM components in the SOA projects make people believe that BPM is part of a SOA. That's wrong.
For BPM, SOA simply means that your BPM engine and tools will be able to consume services. Your BPM can also read data in Databases, then you have the same coupling between BPM and SOA@Eclipse than between BPM and DataTools. DataTools does not contain BPM stuff.
BPM is wide, SOA is even wider, but there is no strong coupling between both. Integrations are possible, but not necessary. Maybe it would be more relevant to have a BPM top-level project at Eclipse independently of SOA, and some projects that would provide some interactions, on top of both BPM and SOA.
That are my 2 cents.
_______________________________________________
soa-pmc mailing list
soa-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/soa-pmc