Archive

Archive for the ‘SOA’ Category

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.

Service Reuse

June 3, 2010 2 comments

Reuse is a topic which confuses a lot of people. Main reason for confusion is inability to understand the difference between component-based and service-oriented architectures. These have fundamentally different ways of reuse.

In component-based architecture, the idea is writing components with generic interfaces which can be used in different scenarios. So instead of implementing functions over and over, create a generic/abstract interface and reuse the function in different places. This works in different levels such as simple libraries (log4j, log4net, spring, etc), it works in large frameworks (drools, jpmn, workflow foundation, wcf, lucene, etc.) and also in infrastructure level (database servers, distributed caches etc). The idea is all same: generic stable interface, high configurability. Although this approach works very well with infrastructural components (doesn’t deliver business value directly), unfortunately, experience of the industry shows that it doesn’t work well with implementation of business processes (usually called as “business logic” in the language of this architecture style).

In service oriented architecture, reuse has a completely different meaning. Reuse of services is about existing consumers using newer version of the service. Reuse of services is “forwards” (existing consumers using new service versions) not “backwards” (new consumers using existing services). It’s not about how to implement generic services which doesn’t need to change for new consumers, it’s about how to implement services which can be extended without disturbing (upgrading) existing consumers. Therefore service compatibility and contract versioning are key concepts in service oriented architecture.

A weak understanding of services ends up with, for example, efforts to define generic service contracts. Because it’s practically not possible to know the unknown these efforts are just wasted. Usually this becomes guess-work, future-predicting. David Chappell says “Creating services that can be reused requires predicting the future…” and concludes that SOA doesn’t work. It’s very clear that he doesn’t understand the concepts of service-orientation. Similarly when Juval Lowy is excited about the capabilities of WCF and advertises the concepts “every object as a service”, same mindset presents itself. It’s not difficult to guess why WCF still doesn’t have contract-first web service development.

I noticed an InfoQ presentation “Expressing Service Capabilities Uniformly” which explains reusability as “multiple services implements same contract”. Funny that change of service contract is stated as a problem, and in the “cons” list you can find the difficulty of  change management. Of course, he doesn’t mention a word about versioning or compatibility. With his architecture style business process is reduced to “moving data from service to service” and REST is the savior. Same story over and over again…

Long story short, there are lot’s of people around who doesn’t understand service-orientation but claim it doesn’t work. Reuse is just one example. More to come…

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 […]