Showing posts with label bpel. Show all posts
Showing posts with label bpel. Show all posts

Sunday, April 27, 2008

Best of this Week Summary 12 May - 18 May April 2008

Monday, March 24, 2008

Best of this Week Summary 17 March - 24 March 2008

  • What should you use in your SOA project: a BPEL process or an ESB?

  • Part 4 in a series on SOA Design: why and how you should use canonical models in SOA. "The canonical data model defines the structure of an organization's information."

  • SpringSource just released their SpringSource Tool Suite. Notice that it is different from Spring IDE. For example it helps you find common pitfalls and best Spring best-practices violations.

  • Yahoo! has released new performance best practices for building webpages.

  • Ways how you can run Firefox 3 beta 4 and Internet Explorer 8 while still being able to easily switch back to FF2 and IE 7.

  • The new OpenHub spec version 1.1 from the OpenAjax Alliance now also includes IBM's contributed Secure Mashup framework (SMash). SMash provides for secure handling of third-party mashup components. OpenHub can be used by developers to "integrate multiple toolkits within the same Web page while toolkit developers can use it to allow toolkits to talk to other toolkits."

Saturday, June 23, 2007

Business process modeling interviews one-on-one

On page 10 of this whitepaper I read an interesting statement regarding interviewing a customer to figure out what business processes they have (with as ultimate goal integrating different back-end systems to provide an automated business process in an SOA environment).

The process-modeling interviews were done one-on-one, instead of meetings where all involved parties are present. The system integrator's experience showed that otherwise (too) much time would have been spent on educating everybody about the big picture. In such a "grand" meeting, roles would be ranging from frontline-workers to the CIO, for which each would be contributing very different process insights, causing a significant delay.

For me it is quite remarkable, since all the process-modeling I was involved in over the years did involve a more consensus-oriented meeting structure were all relevant parties were put in one room. It does work, but indeed much time is spent on getting everybody on the same page. If time doesn't permit, the one-on-one interviewing technique is definitely a viable option. Still, it might provide less buy-in from the involved parties. Also some process optimization(s) might be missed because everybody still only sees his/her part of the process. And indeed, all involved did conclude that in the future a more participatory style and ongoing committee meetings will be most beneficial, especially in the area of SOA governance and the evolution of the business services layer. The paper also shows that iterative (agile) design/development with involvement of the business analysts from the start is still definitely a good way to go: it's just hard to get everything correct in the first iteration. As an SOA architect, you start constructing business services layers with BPEL, which future business applications can reuse (top-down). Then at almost the same time you start to webservice-enable existing systems (bottom-up). Note the combined effort: it was not implemented pure top-down or pure-bottom up, it was a mix. Here's a link to an elaborate description of the project.

Below is a screenshot of a great diagram in the paper which put sthe above architecture terms SOA, webservices and BPEL in perspective: