Best and Worst Practices in BPM and SOA

Posted by Boris Lublinsky on Aug 19, 2009

Sections

Enterprise Architecture

Topics

Business Process Management ,

SOA

 

Peter Woodhull starts his new article "Best and Worst Practices in BPM and SOA", by saying:

As businesses continue to turn to BPM and SOA for increased efficiency and effectiveness of their business processes, many are still missing the mark. There are various approaches that can either make or break an engagement.

Peter discusses some of the best and worst practices in a BPM and SOA implementation. According to him, the following represents worst practices:

Buying software first. According to Peter, the worst mistake is to start a BPM/SOA initiative by evaluating and purchasing software first. The issue is that very few organizations actually know upfront what type of software they need. Adjusting solution to match off-the-shelf software is equivalent to letting someone else run your business.

... most initiatives that start with a product purchase are owned by the IT group and result in bottom-up advocacy and implementation strategy. This causes a disconnect from the strategic goals of the business, because the tendency is to be more focused on the technology than the process or business need.

Discounting organizational change effort. Because most people are change-averse, they don't like change even if it makes their job easier.

If users are properly engaged and provided the opportunity to review, comment upon, validate and help make decisions about the new processes and systems being put into place then they will internalize these changes and accept them.

Trying to "boil the ocean". It is rarely possible to implement a BPM/SOA solution as one massive upgrade or roll out.

BPM and SOA efforts are both inherently evolutionary in that they are best implemented in small, constrained, and frequent capability releases that grow upon each other. Capabilities should be rolled out iteratively in a controlled manner. Processes and services should be independently managed and implemented such that they provide immediate value to their user communities.

Best practices, described by Peter include the following:

It all begins at discovery. Peter considers throwing a technology solution together before there is a clear understanding of the problem as a number one reason for failure.

Accurately defining the processes being managed and documenting the service contracts (WSDL files and data schemas) should be the first and most significant aspect of any implementation initiative. Once an accurate and clearly documented Process Specification (i.e. business requirements) has been validated, signed and approved by your client or partner organization, then and only then should a team begin development and prototyping.

Approach BPM and SOA together as a composite solution. Many people consider BPM and SOA as two independent undertaking, often implemented by different organizations and with different priorities.

BPM and SOA are ,,, strategies and techniques that are utilized to solve some fairly common and ubiquitous problems within business. They also ... [are] well supported by technology platforms. BPM suites are very effective integration tools, especially if there is a need to integrate both humans and computer systems into a consolidated solution. Web services and SOA technologies are great mechanisms to provide code reuse and interoperability between both computer systems/platforms and organizations.

Start with a mission-critical process. As every new approach, SOA BPM needs to be proved in order to obtain management support.

Start with a single mission-critical business process that will recognize identifiable and quantifiable value. Ideally, an organization should select a process that is directly customer focused and does not have an obvious solution... This will result in the implementation being owned by the business group(s) within the organization and not become the responsibility of the Information Technology team.

Peter ends his article by underscoring the complexity and power of SOA and BPM implemented together. He also encourages taking a business, not a technology driven approach to them. Following dos and don’ts as described in his article does not guarantee success, but can decrease the chances of failure.

1. Back to top

   Is a BPM implemenation different than any other application ?

   by Miguel Valdes Faura

   A BPM implementation in an organization is like any other application development, if the specification was not clear the application will fail :-) IMO this is an evidence !
   
   
   
   
   The best way to successfully implement a BPM application is:
   
   - First select a new application required in your organization (a simple one but solving a real day to day issue)
   
   - Then start working on the specification (as I guess you already do with any other application)
   
   - Finally, put your business logic in a process rather than hard code it in your application by leveraging one or more processes
   
   
   
   regards,
   
   
   Miguel Valdes
   
   BonitaSoft Open Source BPM

   Reply

2. Back to top

   Aligning Services with BPM

   by Vijay Narayanan

   In agreement with the recommendation that SOA and BPM efforts should be approached as a composite solution. On a related note, services should be reused in multiple business processes. Additionally, here are key considerations when pursuing SOA initiatives.

   Reply

3. Back to top

   Starting with mission critical process? Or simply prove ROI?

   by Matthieu Hug

   The idea of start(ing) with mission critical process sounds to me very much like prove the return on investment of the BPM+SOA project as quickly as possible.
   
   Of course if you bought a traditionnal BPM suite you'd better target the implementation of a mission critical project :
   1) you invested several hundreds of thousands of dollars in licence, hardware, training, etc... a million maybe?
   2) the first implementation is planned in 6 to 12 months
   3)it will actually be delivered in 18 months at best.
   
   For sure the first project should better prove the whole ROI... Well, this approach may work one day.
   
   Alternatively you can chose a cloud based "BPM as a service" like RunMyProcess (www.runmyprocess.com), avoid hardware issues, avoid deployment, avoid insane licences, avoid even more insane maintenance fees, avoid version upgrades, etc. Since you "pay per use" you can start with a non mission critical process, thus delivering the first, small, benefit within days. With a cost of a few bucks per user per year that's enough to prove a ROI, and this makes the whole, progressive deployment of your BPM+SOA initiative way more secured as it is truly progessive.
   
   Of course the vendor could disappear... But saving your data elsewhere is not an issue a process couldn't solve, right? ;-)
   
   Regards

   Reply

• Older >