IBM and ILOG – Thoughts on Jerry Cuomo’s WebSphere Top 10

Copyright © 2009 James Taylor. Visit the original article at IBM and ILOG – Thoughts on Jerry Cuomo’s WebSphere Top 10.Jerry Cuomo has been talking about WebSphere in 2009 and he published his top 10 list on his blog  WebSphere: Into the wild BLUE yonder!.

Business Mash-ups
Business Rules
Middleware-as-a-Service
Rainmaker
Extreme Scale
WAS.NEXT
Restful – Agile
DataPower-lution
POWERful Middleware
Industry-savvy Middleware

He expanded this list […]

Copyright © 2009 James Taylor. Visit the original article at IBM and ILOG – Thoughts on Jerry Cuomo’s WebSphere Top 10.

Jerry Cuomo has been talking about WebSphere in 2009 and he published his top 10 list on his blog  WebSphere: Into the wild BLUE yonder!.

1. Business Mash-ups
2. Business Rules
3. Middleware-as-a-Service
4. Rainmaker
5. Extreme Scale
6. WAS.NEXT
7. Restful – Agile
8. DataPower-lution
9. POWERful Middleware
10. Industry-savvy Middleware

He expanded this list with some additional thoughts in an article on InfoQ. Serveral of these – business mash=ups, business rules, Middleware-as-a-Service and Agile seemed worthy of discussion in a decision management context as part of my IBM-ILOG series.

1. Business Mash-ups
I am glad to seethe WebSphere folks focusing on mash-ups – I think there is a lot of potential in the idea of mashing-up components in the enterprise space. There is a risk, however, as most mash-ups assume dumb systems – they include reports and forms and maps and what have you but they assume both that the systems under the covers are not doing very much and/or that you don’t want to change their behavior. Mashups that include business user rule management as I discussed in this article in my IBM and ILOG series give the business users a single view into a collection of systems that includes “knobs” for them to change the behavior of those systems. A cockpit not just a dashboard.

2. Business Rules
Talking about rules to simplify processes was something else I covered in the earlier article but there’s more to it than that as I will discuss later. Jerry himself talks about

more sophisticated inferencing to be applied to event processing and process orchestration.

which is good but the more important one is this second bit:

We will also focus on managing and governing business rules using means consistent with our SOA management story

This is where there is some really interesting potential – combining the rule repository that contains the rules for decisons with the SOA repository that contains the decision service that represents those rules when deployed. Think how useful it would be to be able to not just find an available decision service using the SOA repository but then to be able to see how it actually worked by reaching into the rule repository. If someone wanted to know the difference between two decision services then the rules implementing them could be compared at a detailed level, thanks to the declarative nature of business rules. Impact analysis could ripple from the rules being changed to the decisions that used those rules to the decision services that implement those decisions to the processes and systems that use the decision service so that a business user (in their mash-up environment, remember) could see what changing those rules would do in business process terms. And so on, the potential is huge.

3. Middleware-as-a-Service
Hopefully Jerry is also thinking about Decisions as a Service. The ability to run a distributed company by making the critical business decisions that control that business available through the cloud is a really interesting one. The emergence of decisions in the cloud is one of my predictions for 2009.

7. Restful-Agile
It always amazes me that Agile practitioners have not adopted business rules lock, stock and barrell. I wrote an article on Agile and rules (also on InfoQ) some time ago and showed how business rules support all 4 key tenets:

• Tenet 1: Individuals and interactions over processes and tools
  One of the key interactions is between developers and domain experts. The use of agile rules facilitates this conversation.
• Tenet 2: Working software over comprehensive documentation
  Business rules can deliver working software that is easier for domain experts to read and manipulate making it more “self-documenting” and lessening the pressure for documentation.
• Tenet 3: Customer collaboration over contract negotiation
  The fact that both developers and domain experts can read and understand business rules allows true collaboration over the implementation of business logic.
• Tenet 4: Responding to change over following a plan
  Business rules deliver business agility by making the actual code you write easier to change both during the project, and after it.

I am looking forward to seeing what IBM has to say on these and other topics at DIALOG – I’ll be there and blogging.

Link to original post