Mike Gilpin had an interesting post on the Forrester blog this week - The Four Classical Elements Of The Digital World: Process, Service, Event, and Information. You should take a look at the post - it's an article really - as Mike makes some great points about the interconnectedness of all things in application development. I am particularly interested in this as Mike has invited me to attend the Forrester IT Forum in Las Vegas in a couple of weeks where I will be participating in a few things and blogging about the experience over on the Smart (enough) Systems blog - you can subscribe to get the blog posts from the event as I write them.
To keep you going though, I would make a couple of quick observations around decision management and Mike's ideas. Firstly, considering the digital business architecture he references, one can and should clearly regard the logic of decisions, and the models of analytically derived information, as part of the metadata core. Secondly I see decision services as a subset of all services. Decision services provide decision making to processes, decide how to act on events, and decide using information. In this sense they are the subset of services that, perhaps, most embodies the interconnectedness Mike discusses.
I wrote before on the role of business rules in building a digital business architecture.

Posted by jtaylor in Business Process Management • Decision Technologies • Event Processing • SOA | Permalink | Comments (0) | TrackBacks (0)

George Barlow of Appian had an article this week on How Real Time Analytics Delivers Significantly Better BPM. George and I are clearly strongly aligned on this - what he talks about in the article is exactly the kind of decision making Neil and I discuss in Smart (Enough) Systems - so I won't repeat too much except to highlight a few quotes:

With real-time capability, analytics can actually drive process flow. Analytics can be used to automatically initiate performance-based events and dynamically manage the flow of enterprise processes

Real value comes when the BPM software extends to support actual business data managed by the system

Real-time analytics achieve their true potential and are especially powerful when coupled with an integrated rules engine.

Posted by jtaylor in Business Process Management • Business Rules • Decision Technologies • Predictive Analytics | Permalink | Comments (0) | TrackBacks (0)

My fellow blogger, Sandy Kemsley, is giving a webinar as part of the build up to this year's Business Rules Forum next week. Check out the details here and join Sandy next week.

Posted by jtaylor in Business Process Management • Business Rules | Permalink | Comments (0) | TrackBacks (0)

Human-centric business process management (BPM) has become the product and service differentiator. The topic now captures substantial mindshare and market share in the human-centric BPM space as leading vendors have strengthened their human-centric business processes. The BPM and Workflow Handbook spotlight this year examines challenges in human-driven workflow and its integration across the enterprise.

Download the Digital Edition to read immediately (no shipping charges) or order the Print Edition and download four chapters to start reading immediately. Either way you qualify for 30% pre-launch discount.

Pay only $66.50 with the Pre-Launch 30% discount. Put 2008 in the discount code box on checkout for either the PRINT or DIGITAL Editions.

Contents here: Easy-to-read chapters on Tips and Pitfalls when implementing your first BPM project and Step by Step SOA. Many case studies with important information directly applicable to your own projects.Order the PRINT Edition and get the link to download FOUR important chapters and start reading immediately.

The 2008 BPM and Workflow Handbook, published by Future Strategies Inc., in collaboration with WfMC will be launched April 21st, 2008 at Architecture & Process in Washington DC.

Posted by jtaylor in Business Process Management | Permalink | Comments (0) | TrackBacks (0)

Mike Kavitz had a nice post last week - Business Processes as a competitive advantage - in which he discussed the problems he experienced with US Air. The first of these, that of missing a connection due a delay, he felt could have been fixed by a better organized airline. He should have been flying Continental. In a session at the recent DAMA conference, Stephen Brobst of Teradata talked about a system to handle this exact situation. I blogged about this here and here's what I said about Continental:

Their flight management dashboard tracks near real-time events (every minute) and stores them in data warehouse which then drives a dashboard for a hub showing “red zone” flights - more than 15 minute delay. For each flight showed map of flight arrivals, how long the connections had and how many of the people trying to make each flight were profitable customers v less profitable. Delivered to the director of operations so they could do their best to fix things e.g. by providing a cart to make the connection work. Use of information is critical - timeliness - but also had to make people/organizational changes to ACT on the data.

Posted by jtaylor in Business Process Management • Decision Technologies • SOA | Permalink | Comments (1) | TrackBacks (0)

Jerome had a nice piece over on his blog this week - Software Development Life Cycle for BR-BPEL application - where he discussed the SDLC as it applies when using agile approaches, BPEL to mange business processes, a Business Rules Management System (BRMS) to manage business rules and traditional specifications to manage the rest. It is worth reading and I have two observations.

Firstly he shows far fewer iterations based on changes to the rules only than I think it is realistic. Many of the change iterations for an application built this way would be rules-based rather than specification- or process-based. I am sure he did this just to show the various types of iteration but I worry it is misleading. You should get few iterations based on changed specifications, more based on process changes and most based on rules changes. Every scenario I think about works this way - changes in genuine requirements is slowest, process changes slower and rules changes most frequent.

Secondly, as regular readers know, I believe you need to focus on the decisions (the diamonds) within processes and use business rules to manage those rather than simply talking about the rules within a process. I think Jerome believes this too but it does not really come up in his post.

Remember, by the way, that rules are not requirements and that agility is more complex than just making it easy to change a process definition.

Posted by jtaylor in Business Agility • Business Process Management • Business Rules | Permalink | Comments (0) | TrackBacks (0)

I thought it would be fun to highlight my 20 most popular posts from the last couple of years so here goes:

1. Keeping Predictive Analytics and BI on separate tracks
   
2. If IT wants to alter outcomes, it needs to automate decisions
   
3. Business rules, events and processes
   
4. Getting a competitive advantage from your data
   
5. Achieving Agility - some notes after Gartner
   
6. Introducing business decision management
   
7. Here's a way to put analytic solutions in the driving seat
   
8. Decision Technologies and Active Data Warehousing
   
9. SOA and Business Rules, perfect together
   
10. Business rules, routing rules, event rules
    
11. Decision Services
    
12. Decision management is critical to event driven architecture
    
13. Decision Management - another way to get the business to care about SOA
    
14. Marketing Analytics in a Post-Web 2.0 World
    
15. Little known ways to improve customer experience
    
16. More on rules and event processing
    
17. Business rules, desktops and knowledge buses
    
18. If dashboards are the end game, kill me now...
    
19. COBIT, SOX, compliance and business rules
    
20. Call for Presentations - the new EDM Summit
    

Posted by jtaylor in Business Activity Monitoring • Business Agility • Business Intelligence • Business Process Management • Business Process Outsourcing • Business Rules • Compliance • Decision Technologies • Event Processing • Innovation • Legacy Modernization • Predictive Analytics • Requirements • SOA | Permalink | Comments (0) | TrackBacks (0)

• How are you integrating business rules and analytics?
• How are you adding intelligence to your business processes?
• How are you putting analytics to work in your operational systems?
• How, in other words, are you using Enterprise Decision Management (EDM) to innovate your business? Your colleagues and peers want to know.

We invite you to present at the Enterprise Decision Management (EDM) Summit OCTOBER 26-30, 2008 -- ORLANDO, FL  

Join us this year to share how the technologies and approaches of Enterprise Decision Management (EDM) have helped your organization deliver agility while managing risk, focusing on customers, or demonstrating compliance. Whether you call this Business Decision Management or Customer Decision Management or just Decision Management, we want to hear from you. The EDM Summit brings together managers, practitioners and vendors to talk about what works and to provide attendees with a host of practical ideas they can put to use in their own companies. These practical ideas don’t come from us, they come from you.

Most of all, we want real-life case studies. We want to hear what really happened, what worked and what did not, from the actual people who undertook them. Whether you want to show how you got started or how you have learned from experience, whether you want to talk about technology, people or methodology we want real-life cases. If you are a consultant or vendor, the best way to be accepted is to co-present with someone from your client’s organization. Real experience, not company positioning or marketing buzzwords, is what it takes to be selected.

Particular areas of interest include, but are not limited to ...

• Using decision services with BPM or SOA to put intelligence into composite applications
• Using business rules and analytics or data mining in combination
• Implementing adaptive control and champion/challenger testing
• The impact of the technologies and approaches of EDM on the software development life cycle

 Your presentation ideas are welcome in any of our mainstay topic areas, including ...

• Business Rule Management Systems and Engines
• Data Mining and Predictive Analytics Technologies
• Techniques and Methodologies for Data Mining and Predictive Analytics
• Decision Services, Business Rules and SOA
• Adaptive Control and Optimization
• Managing Decisions in BPM and SOA
• Moving to BI 2.0 / Operational BI
  
• Event-based Decision Management
• Compliance and Risk Management
• Organizational Change

Not on the list? Tell us about your own unique ideas! Top architect at a mainstream software vendor? Creator of a highly innovative product? We will consider your presentation for our Chief Architect's track. Highly selective. 

We Want to Hear from You ...

We welcome presentation ideas from all! Do you have a business success story? Best practices about how to use decision management technology? Significant progress in applying data mining to operational systems? EDM Summit is THE place to present on experience, proven solutions and new innovations in this exciting area. We bring together companies and experts from diverse industries in a unique and exciting venue to share their experiences. Do you know qualified colleagues who would make great Forum speakers? Click here to forward this message to a friend. Invite them to submit their Presentation Abstract for consideration!

CALL FOR PRESENTATIONS SUBMISSION DEADLINE: March 31, 2008  

To submit your presentation idea ...
Step 1. Please read the Speaker Agreement carefully.

Step 2. Complete the Speaker Abstract Submission Form.
Presenters will receive a full complimentary registration to the Business Rules Forum, including the two co-located conferences Enterprise Decision Management (EDM) Summit and Rules Technology Summit as well as to RulesExpo.

Got a question? Please email us at speakerinfo@businessrulesforum.com 

Posted by jtaylor in Business Activity Monitoring • Business Agility • Business Intelligence • Business Process Management • Business Rules • Compliance • Decision Technologies • Event Processing • Predictive Analytics | Permalink | Comments (0) | TrackBacks (0)

My friend Paul Haley (now founder and president of Automata, Inc.) had an interesting post on event processing last week - CEP crossing the chasm into BPM by way of BRMS. Paul made a number of great points including that Business Process Management needs some event processing and that, typically, neither a Business Process Management System nor a Business Rules Management System are typically good at handling events. He also touched on what I consider the standard way in which these various technologies interact:

• Events happen and are detected
• Events are correlated to identify the fact that a more complex event, or a business event, has occurred
• These events cause a decision to be evaluated
• The decision may trigger other events or execute processes to respond to the event
• The whole is recursive with events, processes and decisions all potentially triggering each other

Posted by jtaylor in Business Process Management • Business Rules • Decision Technologies • Event Processing | Permalink | Comments (1) | TrackBacks (0)

My buddy Joe had a great post this week - Give businesspeople a reason to care about SOA; give them BPM. Like Joe I think business people need something business-oriented to get their attention and that describing the benefits of SOA must use business terms and business problems. Interestingly I spent the week at ILOG's DIALOG conference this week (see my posts live from DIALOG here) and lots of the customers I met there were using business rules and SOA together having found that decision services, built with business rules, offered their business users a compelling business value. Not only were rules-based decision services a great way to deliver business agility - services a business user could actually change for themselves - they were also an effective first service as they acted as a bridge between the legacy applications and the SOA-based composite applications being developed. After all it is typically not the whole legacy application that is needed as a service but some core business decision buried within it. Exposing just this decision as a service while also making the service much easier to maintain using business rules is very effective. Combine this with BPM, as Daryl Plummer of Gartner did in his presentation and you are off to the races.

Posted by jtaylor in Business Process Management • Business Rules • Decision Technologies • Legacy Modernization • SOA | Permalink | Comments (0) | TrackBacks (0)

My buddy Joe posted this late last year - Smart-Enough SOA? 'Decision Services' Will Make It So - in which he discusses the power of Decision Services to bring critical, needed "intelligence" to SOA (and thus BPM). I have been looking for a reason to blog about it and along came SOA, EDA, CEP, BPM posted by Kjell-Sverre Jerijærvi. This reminded me not only of Joe's post but also of my ongoing discussion of the power of decision management and decision services to bring order and smarts to the developing event-driven, process-centric, service-oriented IT architecture. Not only do I think that decision management is critical to event driven architecture, I also think it can really help those organizations
using EDA and SOA in combination as discussed by Jack van Hoof. SOA, EDA, BPM and CEP are all Complementary - and need decisions. And don't you forget it.

Posted by jtaylor in Business Process Management • Business Rules • Decision Technologies • SOA | Permalink | Comments (0) | TrackBacks (0)

Following a link from Elizabeth I found a post by Jim Sinur titled "What is the Nature of the BPM/SOA Codependence?". Jim makes some good points about the interdependence of SOA and BPM.

Typically 80% of business activity does not include systems, integration, straight-through processing and transactions (the playground of SOA). The 20% that is highly automated is certainly the most efficient and productive; therefore, the more work an organization can push there, the better.

While BPM does support SOA for system tasks, BPM can live well managing the human-only activities without SOA. But as more rules and processes are leveraged as reusable components, they take on a SOA flavor. In reality they really help each other and the failure of one could impact the success of the other.

Curiously enough, however, one of the most human-centric of process types - case management - also needs good decision management. The automation of what can/should be allowed next is both important in case management and reliant on decision management as I discussed here.

I was also reminded of a post I wrote on delivering agility. SOA cannot deliver agility alone because some services (like decision services) need to change internally and BPM cannot deliver it alone because all too often the process is not what needs to change so much as a decision within the process. Decision management, in conjunction with SOA and BPM, is the missing link.

Posted by jtaylor in Business Process Management • Decision Technologies • SOA | Permalink | Comments (0) | TrackBacks (0)

Some time ago I posted on the topic of removing decisions from business processes (something that also came up yesterday) over on my other blog. I got a reply from Michael zur Muehlen and he made a great point. Many people, he said, talk about the integration of rules and processes when what we really want is the opposite - to extract rules from processes. Keeping rules in decisions and processes separate results in simpler processes and clearer management. This topic has come up repeatedly both on this blog, Sandy Kemsley's blog and my other blog.

Posted by jtaylor in Business Process Management • Business Rules | Permalink | Comments (0) | TrackBacks (0)

Mike Kavitz had an interesting post today - Transforming the business with BPM and SOA - and it made me wonder what collection of approaches you really need to transform a business. While experts, and I can be guilty of this too, like to push their own approach "just do what I say and you will be a success", the reality is that many things contribute to truly transforming a business. Mike correctly identifies a couple of them but I would add a few (using their most common names):

• Business Process Management (BPM)
  Allowing the business to participate and even own, for the first time, the definition of how their information systems support their business is clearly transformative.
• Enterprise Decision Management (EDM)
  Automating and improving the operational decisions within these systems and processes to ensure precision, agility and consistency changes the role of front line staff, turns better data into better actions and thus outcomes, and empowers executives to change the way their organization acts. I think that counts as transformative.
• Complex Event Processing (CEP)
  The ability to move to event-driven approaches instead of process-centric or batch-oriented responses is a key component for a real-time enterprise. Complementing and complemented by BPM and EDM, CEP gets the nod for enabling this change of mindset.
• Corporate Performance Management (CPM)
  You can't manage what you can't measure and performance management is how you measure the success or failure of different process designs, event responses or decision strategies.
• Business Activity Monitoring (BAM)
  Closely related to CPM, BAM is about pushing the results of this monitoring to the people who need to act. Combined with automating responses where possible and managing the processes that handle these responses, BAM can truly make a difference.
• Service Oriented Architecture (SOA)
  Underpinning all of these, a focus on reusable, coherent, composable, well defined services instead of large, monolithic applications.

Posted by jtaylor in Business Activity Monitoring • Business Process Management • Business Rules • Decision Technologies • Event Processing • Predictive Analytics • SOA | Permalink | Comments (1) | TrackBacks (0)

Jean Jacques Dubray has just published an interesting article over on InfoQ called The Seven Fallacies of Business Process Execution. I took the time to read it carefully as I like JJD's perspective (and not just because he liked my book). Anyway, he lays out 7 things he considers fallacies common in discussion of business process execution and I thought I would comment on a few of them.

• Fallacy #1: Business analysts model their processes from a systems' point of view
  An not only do they not model their processes from a systems point of view, they don't think of the rules in the decisions within those processes from a systems point of view either.
• Fallacy #3: Business analysts should be able to create executable solutions from process models
  Not only is this not terribly useful, nor is having business analysts create executable business rules except where some sort of framework has been developed to allow them to work in business terms while executing efficiently in systems terms.
• Fallacy #4: If we add a magical BPMS that create solutions directly from business analysts inputs we would not need to develop any of integration with existing systems nor to change existing systems of record nor to do any QA.
  Clearly a nonsense proposition - you will still need to handle some of these technical and IT-centric tasks for processes and, indeed, for rules. He quotes Marlon Dumas (from Bruce's blog) as saying "You won’t remove the developer from the BPM lifecycle, simply because no business analyst will ever be willing to write something that resembles an XPath expression, or any other expression language." While this is true, plenty of business analysts are quite capable of manipulating business rules in a declarative, expressive, verbose syntax or using template-driven environments. XPath is how a programmer does this, business rules are how analysts can.
• Fallacy #5: Business Process Execution must be centralized
  While I mostly agree with him, I take issue when he says "The information systems are simply here to advance, capture and report the state of these resources and activities" as I think this is old thinking. There is no reason why this information systems cannot also decide how to act - they don't need to be as dumb as they typically are. I did like his Figure 4 as the Implementation of the Job Application Service shows a nice decision service(wiki) Validate Application - as part of the solution.
• Fallacy #7: Bruce Silver concludes his post by saying that "the collaborative implementation paradigm, in which executable design is layered on top of the BPMN model, is the way to go.
  While I am not qualified to participate in this debate over standards, I do think that collaboration is key - business users and analysts must be able to collaborate with IT to define processes and decisions and to allow the business-focused staff to take on more of the work in many updates and changes to processes and decisions over time. Indeed Bruce once posted on how much BPMS vendors could learn from BRMS vendors in this space and I have a wiki entry on how to empower business users.

Posted by jtaylor in Business Process Management • Business Rules • Decision Technologies | Permalink | Comments (0) | TrackBacks (0)

After my post on decision service design, Beth replied with a thoughtful post of her own. Beth raises the question of how many types of decision service there might be. I agree that there are several but there are many patterns within each type for specific decision making scenarios.

• Short-running, stateless, synchronous decision services are one type.
• The longer-running, wait for a human to intervene sometimes kind of decision service Beth identifies is interesting. I am not sure I would model this as a single decision service as it might make more sense to handle the long running pieces with a process while keeping the decision service very focused on trying to make the automated decision. Such a process, where a decision service attempts to take a decision and puts something on someone's worklist when it cannot is, indeed, a classic decision service / process pattern.
• Some models of decision services do not have the decision service requesting more information. Instead they expect the decision service to fail to make a decision and to reply to that effect while identifying the information it lacked. Another service would then fetch that information and call the decision service again. While this makes decision services highly reusable and very portable as well as simple to implement, it can also be a limiting factor to their usefulness.
• When talking to folks working in the event processing space, like my friend Paul who blogs over on the Tibco CEP blog, the management of state in decisions is critical to the event processing approach. Perhaps then there is another kind of decision service, one that is stateful and handling decisions that relate to event processing rather than process execution.
• Moving on to asynchronous execution one gets into classic publish/subscribe processing where a decision service might subscribe to an event, execute in response and then decide what events to publish as a result.

Posted by jtaylor in Business Process Management • Decision Technologies • SOA | Permalink | Comments (0) | TrackBacks (0)

Sandy had a great post this week - Policies, procedures, processes and rules - where she discusses some of the very real challenges in managing new ways of documenting our businesses. If we use business rules and process maps to say what we are going to do, how do we map these to each other or to higher level artifacts? How do we track change and manage it effectively. Like Sandy I fear I have more questions than answers but I wanted to add a couple of thoughts:

• Capturing high-level procedures and policies, along with the goals of our systems, is not the same as using a business rules management system or a business process management system to capture operational details.
• There is a huge value in having the actual process steps and business rules/decisions that execute in a process be visible, manageable and editable by both the business and technical people in an organization. These executable "views" of the business are more real than anything written down ever will be - they execute more repeatably and are more auditable than any manual process could be.
• Automatic conversion of one to the other is much less important than traceability. Focusing on recording which process steps in your BPMS implement which procedure, which rules in your BRMS implement a specific decision that is supposed to be based on a particular policy or law is critical. Only then can you do the kind of impact analysis that is crucial to both compliance and agility. For instance, you can then ask for all the audit logs for process executions based on such-and-such an exception handling policy or all the rule artifacts that implement such-and-such a law. This allows you to find the right pieces, see what they do and change them appropriately.
• Don't forget requirements for your system in all this - they too come in high level and low level forms and must be managed and traced.

One final comment. All of this sounds hard but it is only worth discussing because BPMS and BRMS and related constructs make it so much more practical to lay out how your business operates. You could not do any of this if you (or when you) just wrote code. The fact that the problem has become visible is a GOOD thing!

Technorati Tags: BPM, BRMS, business agility, business process management, business rules, policy, procedure, requirements, Sandy Kemsley, process map

Posted by jtaylor in Business Agility • Business Process Management • Business Rules | Permalink | Comments (0) | TrackBacks (0)

I have been thinking about this for a while, ever since I saw Wayne Allen's post on the same topic. I increasingly find myself thinking that the only real way to do this is to focus on the processes and decisions that the business must execute and tie those directly to the software development process.

In practice this means modeling and implementing processes as Business Processes and modeling and implementing decisions as Decision Services. This in turn almost certainly means using a BPMS to manage the process definitions and a BRMS (Business Rules Management System) to manage the rules in the decisions. Separating out processes and decisions will also allow the business to identify its performance metrics, and measure against those, at a more granular level. For instance, what percentage of transactions should make it through the process without manual intervention or what should be the risk profile of customers to whom we decide to give a loan. This focused measures might otherwise be hidden in overall system objectives.

Of course, the business needs to know what it's goals are for this to work but here's the other reason this combination of BPMS and BRMS works so well. Both kinds of technology allow business users to be more engaged in the definition and maintenance of the system's behavior. Combine that with performance management tools that allow the business to change its metrics and the business can evolve all three as it learns what it wants.

Your business users could, for instance, define a basic process with a simple set of decisions and metrics for both. With the necessary additional plumbing you can build a fairly simple system. As they use it they will see that they need to change the process (add new branches to handle exceptions or subsets of transactions for instance), evolve the rules for the decisions (to make better decisions or handle more of the transactions), and change their definition of success. Instead of all this change driving the developers crazy, the business can make most if not all of these changes themselves.

The post talked about 3 different types of value - New opportunity, Staying open and Cost reduction. It also made the point that opportunity cost - the cost/value of not doing something - can be critical. Managing processes and decisions externally really helps with cost reduction and with staying open while also reducing the opportunity costs by making changes faster to implement. New opportunities might require more change than the business can manage on their own but now the IT folks have the time to think about this as their maintenance burden has gone way down.

Other posts you might enjoy on this topic include:

• Composite Applications
• Dynamic Business Applications
• Business user rule maintenance
• Business Rules Cafe
• Reducing maintenance with business rules
• Business process and business rules for agility

Posted by jtaylor in Business Process Management • Business Rules | Permalink | Comments (1) | TrackBacks (0)

Phil Ayres had a great post today - BPM or ERP - Stand out from the crowd, in which he discusses the value of case management and its ability to help you differentiate. For instance, he asks the question "Does your claims process really differentiate from the competition?". After all you probably use more or less an industry standard process for filing, checking and paying claims. Indeed you might even outsource large chunks of it. Phil's POV is that case management, the unstructured or semi-structured part of handling claims, for instance, is one way to really differentiate yourself. And so it is. But even within a standard process you have a way to build in differentiation while still using standard processes.

Think about it. At several points in the process you must take business decisions as to what to do next. If you take these decisions differently from your competitors (being stricter about which claims to pay quickly or more relaxed about when to send out an adjuster, for instance), then you will seem differentiated to customers. The use of decision services to manage these decision points in a process is thus a great way to differentiate you even if you use a commodity process. I wrote an article on this last year, also - using business rules to resist commoditization of processes.

So don't be fooled into thinking your process is likely to differentiate you most of the time. Case management might, decision services will.

Posted by jtaylor in Business Process Management • Business Rules • Decision Technologies | Permalink | Comments (0) | TrackBacks (0)

Roeland posted a response (Requirements vs Process and Rules) to my recent post that made me realize how important capitalization can be!

Roeland points out that the process definition you need and the decisions and rules you need are all part of the requirements of the system you are trying to deliver. This is, of course, true. What I was trying to get at was that I do not believe that process definitions or decision definitions should be managed like Requirements. Documenting them in Use Cases or Requirements tools is much less efficient than managing them as their own artifacts. Clearly they are requirements, they are just not Requirements.

Posted by jtaylor in Business Process Management • Business Rules • Decision Technologies • Requirements | Permalink | Comments (1) | TrackBacks (0)

Roeland had an interesting post this week on the need for a new approach to requirements and BPM's role in that. He outlined the three classic causes of problems with projects (Lack of User Input, Incomplete Requirements & Specifications, Changing Requirements & Specifications) and discussed how a BPM approach can help with that.
Not only do I agree with him, I would argue that exactly the same rationale drives a need to keep rules out of requirements. Process definitions are not the same as requirements. They change on different schedules, have different regulators/policy setters and involve a different degree of business user involvement at various times. Similarly neither process definitions nor requirements are suitable for capturing the rules behind decisions. All of these, like data, need to be described separately and referenced to each other if you are to build a model of the solution that can be built and then modified over time.
So lay out your process, working with your users and use use cases and other requirements tools to capture requirements while keeping the rules that drive your decisions out of both but linked. If you use a BPMS to manage the process and a BRMS to manage decisions you can even ensure that the flexibility and agility you need will be there.
Scott Sehlhorst wrote a nice piece on separating rules and requirements to which I responded here.

Posted by jtaylor in Business Process Management • Business Rules • Requirements | Permalink | Comments (0) | TrackBacks (0)

Jesper wrote some follow-on questions to my response to his post about Sandy's post. For some reason I can't comment on his blog - the site won't let me login and keeps saying there's an error - so I thought I would post a response here.
First he asked about checking which version of a rule is in place for a given process execution. He says "Does it boil down to rules always having a certain time span of validity? (thus making it easy to correlate a given process instance to the rule version valid at that time)"
The key thing here is that we are talking not about finding the version of a specific rule for a specific process execution but finding the version of the decision used for a specific process execution. A modern business rules management system will provide many ways to do this. Typically multiple rulesets (each with multiple rules) are required for a decision. Individual rules will have effective dates and times (if they are only in force during those periods) as well as versions. As a result, it is possible/easy (depending on the BRMS used) to recreate the exact set of rules used to make a specific decision. This can be done by re-deploying the version of the decision as it was at the time (for analysis). Combined with systematic logging of rule execution this gives you what you need.
Secondly he asks about audit - "how is the end result presented in consolidated audits without doing some custom work to integrate audit information from the two separate systems?"
Here he has a good point. This is indeed an issue. While many companies use decisions in multiple processes and systems, and so want a separate execution audit trail, there is often a need to see a combined one for a process/decision combination. Today this requires some custom coding and this is typically high up the list of integration features for BRMS/BPMS vendors when they are working together.
Jesper, that help?

Posted by jtaylor in Business Process Management • Business Rules | Permalink | Comments (1) | TrackBacks (0)

I saw this post last week by Jesper Joergensen - Can business processes and business rules be too loosely coupled? - in which he discusses one of Sandy's posts from the Forrester conference - Forrester Day 2: The three B’s. Jesper takes issue with Sandy's comment about the value of loosely coupling processes and decisions. Now I agree with Sandy on this so I thought I would address Jesper's points one at a time:

• How do you control where your changes to a business rule apply if it is only loosely coupled to your processes?
  Well you use decisions, and decision services, as I discussed last week. There is a difference between rules-driven decisions, which should be loosely coupled and rules used to control the process, which should not be. The difference is crucial as business decisions are, in fact, completely independent of the processes that use them and so must be loosely coupled while routing rules, for instance, are integral to the process and must not be.
• How do you know after the fact, which rule version was applied during which process execution?
  The same way you know, after the fact, what process version was applied. The decision logs which rules executed just like the process logs what steps were executed. The process should care what version of the decision was executed - the specific rules are relevant to the decision, not to the process.
• I am sure an insurance customer would prefer *not* to have the rules changed in mid-process, say affecting the price of the policy after you have agreed to purchase it.
  Well duh! The agreement to purchase it on the part of the customer would come after the underwriting decision was made. However, if the law changed while the process was waiting for a report, say, then the insurance company had better be sure that the underwriting decision was taken with the rules that were supposed to be in force then, not the ones in force when the process started! Again, the lack of a clear distinction between rules that are part of the process and those that drive business decisions accounts for the disagreement Jesper has.
• And how do I find out during an audit, which version of the pricing rule was applied to which customer on-boarding process?
  See above - by logging it, of course.
• There are two ways to solve this. You can provide an external governance mechanism that restricts certain changes to rules, or manages the correlations of different rule versions with process instances.
  Well you had better do this no matter what! Tightly coupled or not, the rules about how you treat customers, how you enforce regulations etc. had better be properly governed! As for coupling the process version and the decision version, why? The way I take a decision can change even if my process does not and the way I handle a process might change even though my core business decisions do not. I can change the pricing rules I use in my pricing decision without changing my order fulfillment process, for instance.
• Or even better, the BPM and BRE are sufficiently well-integrated to manage this for you.
  Integration is not the answer here. None of his issues would be solved by integration. Proper rule design, a proper logging approach, good governance etc are what's needed and they are needed if you smush your decisions into your processes or manage them properly.

• Decisioning in a loosely coupled process
• SOA, EDA and decisioning
• BPM in 2007 and beyond
• A BPMS is not enough to deliver agility
• Process transformation and decision management
• Business Rules, Business Decisions, Intelligent Processes, Enterprise Decision Management
• Decision Services

Posted by jtaylor in Business Process Management • Business Rules • Decision Technologies | Permalink | Comments (0) | TrackBacks (0)

Keith Swenson over at Go Flow had an interesting post this week - Decisions vs. Business Decisions in a Process. In it he discusses the challenges of decision nodes in BPMN diagrams and makes the great point that:

"In reality, those nodes don’t actually make decisions."

"While rules are very important in relieving us from the tedium of routine case assessments, there will never at time in the future be a point where we can stop adjusting and modifying the rules, and there will always be edge cases for which it will be quicker and more efficient to have a person simply 'decide'”

"Good decisions come from experience … and experience comes from bad decisions."

Technorati Tags: BPMN, business rules, decision service, SOA

Posted by jtaylor in Business Process Management • Decision Technologies • SOA | Permalink | Comments (0) | TrackBacks (0)

Forrester recently published an excellent paper - The Dynamic Business Applications Imperative (John Rymer and Connie Moore) - that you all should buy and read (if you don't have a Forrester subscription it's a steal at $279). This paper defines a Dynamic Business Application as

"A software system that embodies a business process and is built for change, adaptable to business context, and information rich."

"Most business applications are too inflexible to keep pace with the businesses they support."
"...they force IT pros to spend too much budget to keep up with evolving markets, policies, regulations, and business models."

"IT's primary goal during the next five years should be to invent a new generation of enterprise software that adapts to the business and its work and evolve with it."

• Imagine Apps That Evolve With Your Business And Its Work
  
  Apps that evolve with your business must allow business people to change how things are done in those applications - using business rules to manage decisions, for instance - while also applying the data your business collects to improve - using predictive analytic models to inform decision-making, for instance. Many of the requirements for evolution in an application are around evolving decisions, putting decision management at the heart of this strategy, particularly when it comes to building for change (something about which I have blogged before).


• There's Nowhere To Hide: All Business Processes Are Subject To This Trend
  
  Absolutely not. For all that various aspects of these applications have traditionally been used in certain domains, the pressures that drove those domains to be early adopters are now affecting everyone and every process. You will have to take control of the decisions in your information systems and business processes, no matter what.


• Progress To Dynamic Business Applications - Start Your Journey By Resetting IT's Relationship To Businesspeople
  
  This reset can be achieved in the core logic of your systems, not just in the periphery. Using business rules to empower business users to manage the decisions in their applications changes this relationship while also increasing your tolerance for (inevitable) change. I blogged before about something Forrester called Concurrent Business Engineering

• Business Process Management


• Business Intelligence and Performance Management


• Decision Management

"the tools are at hand, and pioneers in service-oriented architecture (SOA), business process management (BPM), and business rules ... have begun showing us the way. The time to start on this journey is now."

Technorati Tags: agile, John Rymer, business rules, decision technology, change time, Connie Moore, decision service, decision m