Wednesday, November 30, 2005
Recent Thoughts on BPM
Late Monday night, a VP at work (Hi John) who is highly technical and doesn't practice Management by Magazine got me fired up on the topic of BPM and I figured I would share my thoughts publicly on this subject...
There is no shortage of vendors who believe they have "solutions" to our problems and constantly blow up my phone. Some would argue that BPM in 2005 is analogous to the CASE tools in the early 90's, object-oriented programming in the late 90's and so on. While they aren't using the term "silver bullet" in their chock-a-block eye candy powerpoint presentations, their sales pitches sure make it feel this way.
The timeless phrase of a fool with a tool is still a fool applies even more to the BPM space than other hype cycles of the past. BPM or any other individual approach cannot nor should be counted on the resolve enterprise level challenges. The problem of course is bigger than management by magazine or hype created by industry analysts and can be summarized into two different problem spaces. The first is lack of real enterprise architecture and the second the lack of cultural change within the corridors of most enterprises.
Let's deal with the second point first. Simply, an enterprise cannot deal with significant problems it faces and hope to solve them at the same level of thinking that was used with the problem was first created. The practice of doing more of the same is fundamental to the problem space of why enterprises never really get aligned.
A well-respected blogger, David Lithicum advises enterprises that the main thing to look at is how enterprise applications can gain the most value from each other. The thinking can then be classified against two primary patterns. The first is information-oriented and the other is service-oriented. Service-oriented can be thought of as a hybrid of behavior and information whereas information-oriented deals with simple information.
In both cases, you need to look at transformation, routing and flow control to account for the differences in application semantics. At the same time, you have to understand how behavior is known and exposed outside the applications and how information is bound to that behavior. You should also look at security to make sure you're extending and mediating the different security models of these systems.
BPM doesn't really help capture semantics, bridging of security models or other hard problems and in many cases simply becomes a mechanism for chaining together sub-optimally designed services. BPM definetely doesn't help one deal with cultural change which is required in order to not reinvent the problems of the past.
IT executives have been assigned with conceiving ideas that will drive an enterprises towards increased profitability, reduced cost and industry leadership. The pressure on executives to deliver innovation (will blog on this topic next week) is increasing. Many IT executives simply aren't capable of real innovation which leads to a plethora of half-baked hairbrained ideas. Of course, enterprise culture discourages folks from questioning this fact...
This week, I blogged on the notion of enterprise architecture and courage and now have realized that there is a better term that should be used. Going forward I will refer to it as intelligent disobedience.
This is where the concept of intelligent disobedience comes into play. Intelligent disobedience is a trait clearly illustrated by guide dogs for the blind: At an intersection, based on traffic sounds and a general sense of safety, the blind person initiates the move to cross the street, giving a signal to the dog. If traffic is blocking the crosswalk, however, the guide dog will disobey the move-forward command. In guide-dog training lingo, intelligent disobedience is the dog's response when it senses that the path ahead is dangerous. It disobeys even though the owner wants to proceed.
I was reading the blog of Phil Gilbert who is CTO of Lombardi Software and his recommendation of a Chief Process Officer and wonder why he is encouraging yet another ivory tower role be created within the enterprise. Curious if he doesn't think that this is already covered by folks who practice real enterprise architecture? If I were a vendor though, I too would encourage creation of such a role as it makes it a lot easier for me to identify whom to sell to...
The one blogger that I think is onto something is Bruce Silver who has observed the important distiction between workflow architecture and service oriented orchestration architecture (SOOA - Gartner, make this a new hype acronym). I love the following phrase:
Maybe folks in these enterprises that have drank the BPM kool-aid will be well served by reading Craig Schiff's blog on Smart Companies, foolish choices? And while they are reading blogs, they would be equally well-served to understand how Vendor Frameworks exploit gaps in BPEL. Maybe we could ask the folks at Gartner and/or the Burton Group to produce a report on exactly how vendors do this in painful detail?
Speaking of analysts, I haven't figured out why Fuego isn't showing up more in quadrants. Are they not paying analysts enough money? There is a lot of hype in the marketplace surrounding the combination of BPM and Six Sigma. What comes to mind for me is yet another opportunity for insultancies to come in and recommend useless strategy along with the analysts further oversimplifying the problem causing more enterprises to get it wrong, only that they don't know it yet.
It seems to me that Fuego is onto something that others haven't jumped on. Recently, in eWeek they talked about usage of Neural Nets in their BPM product. A neural network works through a decision activity capability that lets users define a set of variables that can be analyzed for process improvement. Feels like this is a better approach that Six Sigma. Wonder if this can be modeled in BPEL? The notion of cognitive modeling is powerful and should be studied by enterprise architects everywhere.
This blog entry is getting kinda long so I figured I will wrap it up with one last rant. Vendors absolutely, positively do not call me and tell me about your interoperability tests and how portable BPEL is as I really don't care. It would be more interesting for us to understand what BPEL doesn't do so that I can understand when and how I will be locked into your tool. After all, I don't want to be a fool...
| | View blog reactionsThere is no shortage of vendors who believe they have "solutions" to our problems and constantly blow up my phone. Some would argue that BPM in 2005 is analogous to the CASE tools in the early 90's, object-oriented programming in the late 90's and so on. While they aren't using the term "silver bullet" in their chock-a-block eye candy powerpoint presentations, their sales pitches sure make it feel this way.
The timeless phrase of a fool with a tool is still a fool applies even more to the BPM space than other hype cycles of the past. BPM or any other individual approach cannot nor should be counted on the resolve enterprise level challenges. The problem of course is bigger than management by magazine or hype created by industry analysts and can be summarized into two different problem spaces. The first is lack of real enterprise architecture and the second the lack of cultural change within the corridors of most enterprises.
Let's deal with the second point first. Simply, an enterprise cannot deal with significant problems it faces and hope to solve them at the same level of thinking that was used with the problem was first created. The practice of doing more of the same is fundamental to the problem space of why enterprises never really get aligned.
A well-respected blogger, David Lithicum advises enterprises that the main thing to look at is how enterprise applications can gain the most value from each other. The thinking can then be classified against two primary patterns. The first is information-oriented and the other is service-oriented. Service-oriented can be thought of as a hybrid of behavior and information whereas information-oriented deals with simple information.
In both cases, you need to look at transformation, routing and flow control to account for the differences in application semantics. At the same time, you have to understand how behavior is known and exposed outside the applications and how information is bound to that behavior. You should also look at security to make sure you're extending and mediating the different security models of these systems.
BPM doesn't really help capture semantics, bridging of security models or other hard problems and in many cases simply becomes a mechanism for chaining together sub-optimally designed services. BPM definetely doesn't help one deal with cultural change which is required in order to not reinvent the problems of the past.
IT executives have been assigned with conceiving ideas that will drive an enterprises towards increased profitability, reduced cost and industry leadership. The pressure on executives to deliver innovation (will blog on this topic next week) is increasing. Many IT executives simply aren't capable of real innovation which leads to a plethora of half-baked hairbrained ideas. Of course, enterprise culture discourages folks from questioning this fact...
This week, I blogged on the notion of enterprise architecture and courage and now have realized that there is a better term that should be used. Going forward I will refer to it as intelligent disobedience.
This is where the concept of intelligent disobedience comes into play. Intelligent disobedience is a trait clearly illustrated by guide dogs for the blind: At an intersection, based on traffic sounds and a general sense of safety, the blind person initiates the move to cross the street, giving a signal to the dog. If traffic is blocking the crosswalk, however, the guide dog will disobey the move-forward command. In guide-dog training lingo, intelligent disobedience is the dog's response when it senses that the path ahead is dangerous. It disobeys even though the owner wants to proceed.
I was reading the blog of Phil Gilbert who is CTO of Lombardi Software and his recommendation of a Chief Process Officer and wonder why he is encouraging yet another ivory tower role be created within the enterprise. Curious if he doesn't think that this is already covered by folks who practice real enterprise architecture? If I were a vendor though, I too would encourage creation of such a role as it makes it a lot easier for me to identify whom to sell to...
The one blogger that I think is onto something is Bruce Silver who has observed the important distiction between workflow architecture and service oriented orchestration architecture (SOOA - Gartner, make this a new hype acronym). I love the following phrase:
If you went to a workflow conference or trade show, any vendor could show you how to build a workflow in 30 minutes using no programming, just graphical drag-and-drop design. So once you bought the technology, why did it take six to twelve months to design and deploy real-world workflows?
Maybe folks in these enterprises that have drank the BPM kool-aid will be well served by reading Craig Schiff's blog on Smart Companies, foolish choices? And while they are reading blogs, they would be equally well-served to understand how Vendor Frameworks exploit gaps in BPEL. Maybe we could ask the folks at Gartner and/or the Burton Group to produce a report on exactly how vendors do this in painful detail?
Speaking of analysts, I haven't figured out why Fuego isn't showing up more in quadrants. Are they not paying analysts enough money? There is a lot of hype in the marketplace surrounding the combination of BPM and Six Sigma. What comes to mind for me is yet another opportunity for insultancies to come in and recommend useless strategy along with the analysts further oversimplifying the problem causing more enterprises to get it wrong, only that they don't know it yet.
It seems to me that Fuego is onto something that others haven't jumped on. Recently, in eWeek they talked about usage of Neural Nets in their BPM product. A neural network works through a decision activity capability that lets users define a set of variables that can be analyzed for process improvement. Feels like this is a better approach that Six Sigma. Wonder if this can be modeled in BPEL? The notion of cognitive modeling is powerful and should be studied by enterprise architects everywhere.
This blog entry is getting kinda long so I figured I will wrap it up with one last rant. Vendors absolutely, positively do not call me and tell me about your interoperability tests and how portable BPEL is as I really don't care. It would be more interesting for us to understand what BPEL doesn't do so that I can understand when and how I will be locked into your tool. After all, I don't want to be a fool...
