Please see my comments in-line. Anne Thomas Manes wrote: > +1 Steve. > > Ashraf -- I don't think I could disagree with you more. > While I think BPM and SOA ( or more precisely, process orientation and > service orientation) are complementary, a good architect always > recognizes that all "orientation" mindsets must be used appropriately. > And you should also recognize that these mindsets are based on > analysis and design principles--not on technologies.
> BPEL is > irrelevant to both BPM and SOA. How come?!! *BPMN enables us to draw the representation of a business process, which is then mapped into the executable BPEL code, and executed directly on the SOA platform. * *SOA is about business content, business processes, aligning IT with the business, and optimizing the business processes.* Please correct me if i am wrong. ** > As Steve says, you may decide to > implement a service using BPEL, but you could just as easily do so > using Java, C#, Ruby, or Erlang. Techology selection is a > project-specific decision that occurs very late in a BPM project. > I am sorry I disagree with you. This is a technology point of view. Not from the enterprise point of view. How the Java or other languages can support the human interaction, as for example, if we build a business process ? Please notice that these languages is low-level compared to business processes. Therefore, we sometimes refer to them as ‘*programming-in-the-small’*. *SOA approach to development is sometimes called /programming-in-the-large. /* Composition of services (using BPEL) has been designed for such a purpose. > Key "technologies" that support BPM include Six Sigma and Lean > methodologies, swim lanes, process maps, ARIS, Visio, etc. These are > > the tools business people use to analyze existing processes and > explore/simulate new ways to accomplish their work and achieve their > desired business outcomes. Some aspects of their proceses can be > automated. Others can't. Some aspects of achieving business outcomes > are delivered via better insight -- not through processes. (in which > case adopting a purely process-centric perspective is detrimental) If you speak about flowcharts, it is ok. But business needs more than that, business want to reduce the IT gap time. > After analyzing their processes, business people submit requests to IT > to implement application software to automate certain aspects of the > process. IT people then use a variety of modeling notations to design > solutions, e.g., BPMN or UML. From there, they write/produce code. > Some people attempt to generate code from their models. I have yet to > find anyone who supports that code who still believes in the > model/code roundtripping myth. > I can tell that I reversed engineering Java code when I joined a project at its end stage on 2004, to understand the project and to finalize it and deliver it to their end user. It takes a few weeks and lot of efforts but without that it would take a months. I modified some of the model and forward engineer it to code again, and with little support from the developers, we achieved our goals. I do believe in model/code roundtripping myth and I think there are some believe on it too. It is not just a theory, but we have to open our minds up to new concepts, study them without precluding anything, then we can select the best fits us. I think I learned that from you Anne. All the best Ashraf Galal > Anne > > > > On Sunday, December 13, 2009, Steve Jones <[email protected]> wrote: > >> Lets plan planet fail.... >> >> 2009/12/13 Ashraf Galal <[email protected]>: >> >>> The key technology of SOA is BPEL. >>> >> #FAIL >> >> Even if we say that SOA is a technology thing its really rather hard >> to say that a PROCESS language is THE key technology of SERVICE >> orientation. Its like saying that procedures are the key technology >> of OO. >> >> >>> This language minimizes the semantic gap between the process model and >>> the actual execution code. >>> >> I might let you have this one, its not right (it can reduce it a bit >> in certain cases rather than being a blanket statement) >> >> >>> BPEL enables business processes to be executed directly. >>> >> #FAIL >> >> See "Christmas SOA" which explains why what you execute is rarely what >> the business process is, this is the difference between the perceived >> process and the executed process. BPEL works at the executed level. >> >> >>> Process models, preferably developed in BPMN, can manually, >>> semi-automatically, or automatically be translated into BPEL. >>> >> Not a fail but.... >> >> BPMN can also be translated into Java, C, assembler or many other >> languages. Now its _sometimes_ easier to do it into BPEL but that >> doesn't mean >> >> Also "manually" translated means there are significant gaps. >> >> >>> With BPEL, various activities, called partner links, are performed by >>> services. >>> >> I really think we all know this stuff. Are you Scott Nudds? >> >> >> >>> Therefore, an important aspect is the decomposition of the business >>> process and its mapping to the services. >>> >>> Services are the central artifacts of SOA architecture. We use services >>> to model automated business activities or human tasks. >>> >> #FAIL >> >> Nope, the CAPABILITIES model the activities or tasks, the SERVICES >> provide the mechanism for accessing those capabilities. >> >> >>> SOA enables much tighter integration between business processes and >>> software architecture. Many tools on the market today provide >>> bidirectional lifecycle support. >>> >>> This means that changes made to the model (BPMN) are automatically >>> propagated to implementation (BPEL), and vice versa. >>> >> #FAIL >> >> Ever worked on a project that used these things? You export from BPMN >> then you have to tweak the BPEL and from that point onwards the >> roundtrip is almost always doomed. >> >> >> >>> If we do not use SOA and Services we will end up with a lot of problems >>> because BPMN is designed specifically for SOA. >>> >>> There is nothing perfect, but we have to set up our goals and work to >>> achieve them. >>> >>> Also we have to recognize that SOA changes the traditional development >>> life cycle. instead of analysis, design, implementation and testing, we >>> will have business process modeling using BPMN, composition, testing and >>> monitoring. >>> SOA changes our life and people do not accept change easily. >>> >> #FAIL >> >> What you are talking about is _not_ change its simple the old school >> of "technologies first" implementation which also assumes some form of >> mystical technology stack which has a vendors current hot ticket item >> at the top. In your case you see it as BPEL/BPMN but others would >> look at CEP as being another option for that top stack. >> >> The key piece of SOA is thinking about the services FIRST and then >> thinking about which of the capabilities of those services are BEST >> delivered using processes and which are BEST delivered in other ways. >> >> In this way you look at the business first and don't assume the technologies. >> >> >> >>> All the best >>> >>> >> Planet #FAIL population: >> >> >>> Ashraf Galal >>> >> Cheers >> >> Steve >> >> >>> >>> >>> cordau wrote: >>> >>>> Ashraf, >>>> >>>> >>>>> With these two technologies, plus some additional ones, SOA provides: >>>>> >>>>> - A language—BPEL—for direct execution of business processes >>>>> >>>>> - Round-trip mapping between the process models in BPMN, and their >>>>> executable representation in BPEL >>>>> >>>>> With this, SOA considerably reduces the semantic gap between the >>>>> business processes and application systems. >>>>> >>>>> BPMN enables us to draw the representation of a business process, which >>>>> is then mapped into the executable BPEL code, and executed directly on >>>>> the SOA platform. >>>>> >>>> You should know that not all BPMN processes are mappable to standard >>>> BPEL (let alone being able to roundtrip). See >>>> http://www.brsilver.com/wordpress/2009/11/19/bpmn-vs-bpel-are-we-still-debating-this/ >>>> <http://www.brsilver.com/wordpress/2009/11/19/bpmn-vs-bpel-are-we-still-debating-this/> >>>> for details. >>>> >>>> Active Endpoints, a BPMN and BPEL tools vendor, had to introduce a >>>> proprietary extension to BPEL in order to support some BPMN processes. >>>> See >>>> http://www.activevos.com/indepth/f_technicalNotes/aa_ExtendingBPEL/ExtendingBPELWithLoopingTransitions.pdf. >>>> <http://www.activevos.com/indepth/f_technicalNotes/aa_ExtendingBPEL/ExtendingBPELWithLoopingTransitions.pdf.> >>>> >>>> >>>> >>> >>> ------------------------------------ >>> >>> Yahoo! Groups Links >>> >>> >>> >>> >>> >> ------------------------------------ >> >> Yahoo! Groups Links >> >> >> >> >> > > > ------------------------------------ > > Yahoo! Groups Links > > > > > ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: [email protected] [email protected] <*> To unsubscribe from this group, send an email to: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
