Will BPM be the Savior of SOA?

My friendly Software AG representative recently gave me a copy of the "BPM Basics for Dummies". This was an interesting little book pitched at the Executive level. It would not help an IT person to get started with any particular product set but would help them understand what all the fuss was about.

BPM (see note below) has been with us since at least the 1980s. It used to a paper process of writing up the process and then getting a team of programmers to build it, then implementing it on usually a big computer that could handle it and then have the computer operators monitoring it.

In the 1990s Business Process Reengineering (BPR) was an approach which changed an organizational process. It involved process diagrams, IT change and business change.

The excitement with BPM is that some of the leg work involved in actually building systems can be removed if the components of the business process are already established. In this case the components are Web Services enabled through an SOA.

What interests me about this is that some of the concepts behind BPM are a lot easier to explain to the business than SOA. You can get out the Lego blocks and explain the benefits of agility until you are blue in the face but you are still only talking in analogies and expecting the business to take a leap of faith. If you show the business a diagram of one of their business processes and then tell the business the cost of changing that business process then that makes sense in terms the business understands. Of course there is a significant investment in infrastructure, tools and services to establish before you get to that point. It is this significant investment that the IT executive wants to sell. If you are pushing a plan to buy infrastructure, tools and establish services then the plan will make more business sense if the objective is BPM rather than SOA.

I think Software AG understands this and that is why they are giving out "BPM Basics for Dummies" and not "SOA Basics for Dummies". I think the business will get behind BPM before they will embrace SOA. We may see more push for BPM to business executives and SOA may take a back seat. The IT department however knows it needs SOA to get BPM to work. That is just how it meets the business goal of BPM.

Note:

BPM stands for Business Process Management, but you would excused for thinking it stood for Business Process Modeling. The "Management" implies that we are doing a lot more than mapping out the processes. The "Management" moves beyond documenting the processes to making them happen and monitoring their effectiveness.

This is not to be confused with BPMN (Business Process Modeling Notation) where the "M" stands for "Modeling". BPMN however can move beyond an aesthetic model to an operational system by converting it to BPEL.

References:

http://www.ebizq.net/hot_topics/bpm/

http://www.bpmn.org/Documents/Mapping%20BPMN%20to%20BPEL%20Example.pdf

http://en.wikipedia.org/wiki/Business_process_reengineering

Kiran Garimella, Michael Lees and Bruce Williams, "BPM Basics for Dummies (Software AG Special Edition)", Wiley Publishing Inc. 2008.

Business Requirements: More than a Pretty Face

In the his opinion piece for ComputerWorld, Michael Hugos tries to give us a quick-fix for the complicated world of software development. A couple of good rebuttals of this "CIO at Large" have already appeared on the internet. In particular Bran Selic of the UML task force exposes the lack of Hugos's lack of UML knowledge.

Like Moliere's Monsieur Jourdain, who spoke prose all his life without knowing it, Hugos may be surprised to discover that four of his five diagram types are either valid UML diagrams or can be mapped directly to corresponding UML diagrams, with one important difference: UML diagrams are composed of elements that have a standard semantics associated with them.

"Five Diagrams Beat a Victorian Novel" is a catchy title and we can all relate to a good diagram being easier to absorb than thousands of words. We should encourage meaningful illustratons but there are many parts of our templates that are not amenable to the simple diagram. We need to talk about objectives, risks, non-functional requirements, costs etc. – these are easier to express in words.

Hugos is advocating a warterfall development methodology and not advocating anything new with his 5 diagrams.

The first diagram is a data flow diagram which was developed by Edward Yourdon and then improved by Gane & Sarson in the 1980s. Gane & Sarson added sources and sinks which evolved to be the actors in use-case diagrams and swim-lanes in swim-lane diagrams. The swim-lane diagram is a special case of the UML Activity Diagram. I prefer to see the swim-lane diagrams to the old Yourdon data flow diagram. The old DFDs certainly still have value but I believe the new diagrams are more expressive and better accepted.

The logical data model is good sense and developers have been using these for years. I would hope that any serious business analysis involved a logical data model and that this was based on an enterprise information model.

Hugos writes about a "System Technical Architecture" which is similar to a UML Deployment Diagram. This is not usually the role of the BA and sometimes not even the role of the software developer. The systems architect will often be responsible for what part of the application runs on what hardware and therefore this deployment diagram.

Hugos write about an Object Model which is the equivalent of a UML Class Diagram. It is the role of the programmer or systems analyst to develop these. Again I have no problem with this diagram being included in a solution design.

Storyboarding is a technique that has been around for a while and has been adopted by the XP (extreme programming) agile programming technique. Use cases attempt to portray the same information.

The use of screen mock-ups helps show the user some tangible picture of what the application might look like and is an alternative to prototyping the user interface. There is a good IBM article on this.

There is little question that use cases have a bigger impact on software engineering than storyboards. Use cases are the origin and basis for a well-defined object model that not only manages the functionality and business rules of a system, but also serves more than one HCI [Human Computer Interface]

The Business Analyst(BA) develops requirements for two audiences. It is the BA's call whether to do screen mock-ups or storyboards. If the BA wants to develop these to convey to the user what the solution might look like then this should be commended. However, a BA still needs to develop the use cases for the developers to understand the logic behind the user interface.

I got a difficult email this week. It went something like "I have just found something new. Apparently five diagrams can replace our long business requirement documents. Please investigate and see if we can get rid of RUP". This is what prompted me to prepare this posting. In general I believe diagrams are goodness but we need words to be precise. Hugos would like to regress to a simpler time. UML is a standard and we use well-accepted standards to make our life simpler. We should not be slaves to our methodologies. Develop screen-shots or storyboards or prototypes if they will help the users understand their requirements. We need to remember that the developer will benefit by seeing a use-case in a format that he or she is comfortable with and expresses what happens behind the user interface.

References:

Two responses to the Hugos article:

Letter: UML Shifts Specs to User's Point of View
Bob Jones, October 15, 2007 (Computerworld)
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=304960

Opinion: Five Diagrams Redux
Bran Selic, an IBM distinguished engineer at IBM Canada, is co-chairman of the UML 2 task force in the OMG
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9043002&source=rss_topic73

The IBM article on Storyboarding

Form feeds function: The role of storyboards in requirements elicitation
http://www.ibm.com/developerworks/rational/library/dec05/krebs/index.html