<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0">
   <channel>
      <title>Building Blocks</title>
      <link>http://blogs.oracle.com/rezashafii/</link>
      <description></description>
      <language>en</language>
      <copyright>Copyright 2008</copyright>
      <lastBuildDate>Tue, 12 Aug 2008 15:26:26 -0800</lastBuildDate>
      <generator>http://www.sixapart.com/movabletype/</generator>
      <docs>http://blogs.law.harvard.edu/tech/rss</docs> 

            <item>
         <title>Links To The Past...</title>
         <description><![CDATA[<p>Since dev2dev articles have been moved to OTN, I thought I should add here a quick reference to the new links of the three articles that I had authored. Here they are along with a quick blurb on their relevancy in the world as we know it today: </p>

<p>
<a href="http://www.oracle.com/technology/pub/articles/dev2arch/2005/03/callback_clients.html">Creating Callback Enabled Clients for Asynchronous Web Services</a>: Even though this article is now over 3 years old (wow, time sure does fly!), it might sill have some useful content. The concepts discussed are fairly protocol neutral specially when it comes to the discussion regarding the creation of stand-alone Java clients for asynchronous web services that provide a callback interface.  
</p>

<p>
<a href="http://www.oracle.com/technology/pub/articles/dev2arch/2006/04/process-testing.html">An Introduction to Business Process Testing using JProcessUnit</a>: Unfortunately the JProcessUnit code-share project, the main subject of this article, got lost in translation during the Oracle transition. In the next few days I will try to see what the best way is for me to somehow make at least the downloads for the project available. If I can do so, I will update this paragraph with the links.
</p>

<p>
<a href="http://www.oracle.com/technology/pub/articles/dev2arch/2008/05/kaizen-bpm-agile.html">Kaizen, BPM, and Agile Methodologies</a>: This is my most recent article and the subject of my <a href="http://blogs.oracle.com/rezashafii/2008/07/bpm_and_agile.html">previous blog</a> entry so I won't babble any more about it.
</p>]]></description>
         <link>http://blogs.oracle.com/rezashafii/2008/08/links_to_the_past.html</link>
         <guid>http://blogs.oracle.com/rezashafii/2008/08/links_to_the_past.html</guid>
        
                  <category domain="http://www.sixapart.com/ns/types#tag">Asynchronous Web Services</category>
                  <category domain="http://www.sixapart.com/ns/types#tag">Dev2Dev</category>
                  <category domain="http://www.sixapart.com/ns/types#tag">JProcessUnit</category>
        
         <pubDate>Tue, 12 Aug 2008 15:26:26 -0800</pubDate>
      </item>
            <item>
         <title>BPM and Agile</title>
         <description><![CDATA[<p>During my work as a consultant I had the opportunity to participate in a number of BPM projects where the process development work started with the business analysts dumping a doorstop sized requirements document on a development team working in agile mode. There was nothing wrong with the document's content per se; in fact they all had a very detailed description of each process involved followed by fancy diagrams. No, the problem wasn't with the document's content or format, but with its underlying assumption which was that its "completion" signified an end to requirement analysis and that all of the processes were completely modeled and ready for implementation.</p>
<p>Things somehow never worked that way: After an iteration or two, the development team inevitably found a number of issues with the processes that were not thought of by the analysts. Also, as some of the processes were implemented and the business analysts had the opportunity to actually "see" them, they invariably found something they didn't quite like and had new ideas for process optimization.</p>
<p>Given that the development team was working in short iterations, they were usually able to adapt to these changes. The issue was on the business analyst's side of the court and the requirement analysis brick that started it all. The changes that were discovered in one process usually impacted many others and therefore rendered much of the process requirement document's content obsolete sending the business analysts back to the drawing board. This led to a vicious circle repeating itself every couple of development iterations.</p>
<p>My experience with this BPM anti-pattern - which closely reflects the same problems that are experienced with waterfall based software development methodologies - along with my bafflement at the realization (during my attendance of the <a href=http://www.gartner.com/it/summits/bpm5/index.jsp>Gartner BPM summit</a> earlier this year) that there was still no significant thinking being done to resolve it, is what led me to write this article: <a href=http://www.oracle.com/technology/pub/articles/a2a/2008/05/kaizen-bpm-agile.html>Kaizen, BPM, and Agile Methodologies</a>. I hope that after reading it you will come to the conclusion that heavy-up-front-modeling BPM projects are not a good idea and that an iterative, incremental, and agile approach is more likely to be effective. I look forward to hearing your feedback.</p>]]></description>
         <link>http://blogs.oracle.com/rezashafii/2008/07/bpm_and_agile.html</link>
         <guid>http://blogs.oracle.com/rezashafii/2008/07/bpm_and_agile.html</guid>
                  <category domain="http://www.sixapart.com/ns/types#category">BPM</category>
        
                  <category domain="http://www.sixapart.com/ns/types#tag">Agile</category>
                  <category domain="http://www.sixapart.com/ns/types#tag">BPM</category>
                  <category domain="http://www.sixapart.com/ns/types#tag">Methodologies</category>
                  <category domain="http://www.sixapart.com/ns/types#tag">Methodology</category>
                  <category domain="http://www.sixapart.com/ns/types#tag">Software Development</category>
        
         <pubDate>Tue, 29 Jul 2008 08:10:48 -0800</pubDate>
      </item>
      
   </channel>
</rss>
