Archive

Posts Tagged ‘Zachman’

Combining BPM and BRMS

October 8, 2010 Leave a comment

Everyday I see more and more frameworks trying to combine BPM and BRMS. Tom Baeyens posted “Blending Processes And Rules With jBPM” in his blgo some time ago. Yesterday IBM twitted their new site “Combining flexible BPM and business rules for faster ROI“. It’s nice to see more focus on combining both.

IBM say if you have conditions similar to Large number of field employees dedicated to sales, Complex business processes with unacceptable error rates, Lack of business user control over processes and decisions, Increasing regulatory pressure, you probably need to look at combining BPM with BRMS. Here are the questions you can ask to find it out:

  • Are you looking for more control managing decisions within your business processes? Would you like to be able to make changes more quickly?
  • Are you able to personalize pricing, promotions, product offers (etc.)? Would you like to be able to increase personalization?
  • Are you able to effectively manage differences across geographies or sales channels?
  • Are there compliance issues related to this?Are you able to test how a decision change impacts process behavior? Can you simulate decision outcomes before deploying changes?

It’s nice to see there’s a focus on combining BPM and BRMS, and i’m waiting there’ll be focus also on combining entity lifecycles to that. Then we’ll have HOW, WHY and WHAT of Zachman together.

Categories: BPM, BRM Tags: , , , , ,

Top-Down vs Bottom-Up SOA

InfoQ fired the debate again. When I looked at my past, I see myself sometimes on side, sometime on the other side. Almost exact debate exist between centralized vs decentralized.  Same story. Now that I have more structured thoughts, I can share them.

So, the problem here is not SOA should be top-down or bottom-up.  We need to focus on what needs to be bottom-up and what needs to be top-down. My approach is to go with the layers. Take Zachman, when you look at the upper layers (Scope, Business, System) are more top-down, and the lower layers (Operations, Implement, Develop) are more bottom-up. Of course the line is not very clear, in the middle (System, Develop) bot approaches meet each other.

Depending on the area of interest, people choose different side on the discussion. Bill de hÓra argues SOA cannot be top-down because there’s no top, SOA systems are in reality decentralized. Of course, when he’s talking, he’s thinking about web services, applications, RPC protocols, REST etc. All about implementation of services. He’s 100% right. On this level, decentralization is the key. On the other side he’s failing to understand when John Crupi is telling SOA must be business driven, must be top-down, he means we start with vision/mission, strategy/tactics, not by technology. He’s not talking about implementation, but scope, business and system in Zachman. There, to have top-down approach is the key.

So my conclusion is people either cannot express what they’re talking about and assume everyone else is in the same layer or fail to understand there are different layers and there’s no one approach to use in all of them. As I experience everyday, latter is more common.

Business Entity Definition Language from IBM

April 27, 2010 2 comments

Last week IBM published the first part of a Data4BPM series:

Part 1 of this series introduces the concept of business entities as a means of representing the business view of data. It proposes two new standards, the Business Entity Definition Language (BEDL) and BPEL4Data for the holistic design and execution of process with Business Entities.

This is definitely a good move towards embracing the importance of data model in business processes. I see this in the direction of connecting different models with the efforts from Ksenia Wahler in her paper “LinkA framework for integrated process and object life cycle modeling” and Bruce Silver in his articles “Integrating Process and Rules Part 1Part 2“.

As mentioned in the paper, instead of “process-first” or “data-first” approach, a “holistic approach will prove to be most effective. However, I don’t agree that holistic means process plus data. For me holistic would as well include business rules, motivation, etc. That would be modeling all columns of Zachman framework (what, where, how, …) For example “Discovering Business Entities” section is very weak, doesn’t tell one work about business rules. You can also see that state transition rules are fit into a single attribute inside access policies. This clearly tells me, there’s a lot of space for improvement in business rules area.

What I like very much in the paper is the concept of four components of Business Entity types:

  • Lifecycle
  • Information
  • Access Policies
  • Notifications

CRUDE style in access policies (create, read, update, delete, execute state transition) somehow matches REST style which could be applied in this context. Although REST is not an approach I would take for implementing services, data services as such could be a candidate.

The link with BPEL is another point of criticism. JJ made some comments about that in his blog:

Thinking that a “Business Process Whatever Language” needs extensions to deal with Human tasks or Process Data is not just comical, it is ludicrous […]