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)

p>Valentin Zacharias is conducting an online survey on the development of rule bases and would really appreciate your opinion! The survey is very short and should only require a few minutes to complete. Any additional feedback or comments are also very welcome. If you answer all questions and enter your email address at the end of the survey, you have a chance to win a Canon SD1100 that will be given to one of the participants.

To participate please go to: surveymonkey.com/s.aspx?sm=sZ1_2fndMD1QnCLgWQfR_2bsBw_3d_3d

The goal of the survey is to give an overview of the kind of methods and tools actually used for the development of rule-based systems (with a focus on verification and validation). It also tries to identify some of the challenges facing rule-base development. The results of the survey will be publicly available. Drop him a note or enter your email address at the end of the survey to have them sent to you. The results will also be accessible on the website vzach.de/blog/ and I will likely blog about them too.

<Apologies for cross-posting to all 3 blogs>

Posted by jtaylor in Business Rules | Permalink | Comments (1) | 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)

I am involved in two great decision management shows this year and I wanted to tell you about them.
First up is InterACT, Fair Isaac's show on decision management and analytics, April 27-30. Even if you aren't a Fair Isaac client you should check out this show. It's at the Palace Hotel in lovely San Francisco and is an opportunity to hear Ian Ayres, author of Super Crunchers and attend one of the best analytic symposiums to hear about some leading edge analytic techniques and approaches. There are lots of sessions for Financial Services companies on how to cope with the current banking crisis - sessions on managing highly indebted consumers, risk management, helping the unbanked, the mortgage crisis, better collections strategy and for Insurance companies who can find a whole track on claims, underwriting, customer service and marketing in the new world of insurance.

John Rymer of Forrester, one of my favorite analysts, is speaking on dynamic business applications, a really interesting area and there are a number of sessions on detecting, managing and controlling fraud from internal and external threats. The growing array of regulations - Basel II and others - are covered so you can grow through your response to regulation not collapse under its weight and scoring, of course, will get a thorough working over so you won't be confused about the benefits and limitations of scoring.

I will be there blogging and I want to meet you. I am offering a discount for readers - just enter the discount code SFJT when you register and get the unlimited registration for just $1,345. This is a great deal! You can register here and get more information on the event here. I highly recommend the show and I hope to see you there.

The second show is the all-new Enterprise Decision Management (EDM) Summit of which I am a co-chair (with my business partner and co-author, Neil Raden). This show is running October 26-30 alongside the established Business Rules Forum and will be show casing case studies on using decision management for competitive advantage, how to compete with analytic decision-making, how decision services enhance SOA and much more. Registration is not open yet but you can put yourself on the mailing list here. This is the first large-scale conference with a decision management theme and we are assembling a great set of tutorials (SOA, agile, business rules, data mining, decision management and optimization among others) and speakers. Look for me to blog more about this in the coming months but get on that mailing list now.

Posted by jtaylor in Business Rules • Decision Technologies • Innovation • Predictive Analytics • SOA | Permalink | Comments (0) | 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)

One of the main reasons companies adopt decision management and the associated technologies is to empower business users. Joe posted on this topic recently and it made me think about business empowerment. To empower the business from a systems perspective means putting them in a position to direct how their systems work, how they support the business, how they change. It seems to me that this requires 4 things - information, understanding, control and simulation.

• Information about the business
  Business users who can't get reports, dashboards and visualizations that present information about what is happening, what is working, what is delayed, what is broken are not going to be able to take any control of their systems - they won't know where to start. One of the reasons now is a good time for decision management is that many organizations have now reached this point.
• Understanding of their systems and processes
  Business users must be able to see how their processes run today, what data is stored when and how the systems that support the process work. If the process and business logic are embedded in code then this will not happen. The use of business process technology and of business rules can make all the difference in the world.
• Control of the systems
  If business users cannot change their systems, if they are not the ultimate arbiters of what process runs or what rules are executed to make a particular decision then they cannot be said to be empowered. Control need not mean sole control - the IT department can be involved too - but the way the process and rules are defined must allow the business users to really control things.
• Simulation of proposed changes
  Business users are not going to go through the same kind of formal QA and testing process IT uses so they must be able to simulate the impact of changes in a way that makes sense to them. They must understand what a change will do before they do it.

Posted by jtaylor in Business Agility • Business Rules • Decision Technologies | 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)

Larry Goldberg, an old friend of mine, wrote an article introducing Business Decision Management - another name for what I call Enterprise Decision Management or just plain old Decision Management. He wrote it to explain why the Business Rules Bulletin is changing its name to the Business Decision Management bulletin - a welcome change. Anyway, you can enjoy the article here. Look for another from me on the subject soon and check out the BPM Institute, it's got some great content.

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

Michael Lee over on Bob Glushko's blog posted about an article he saw on UPS going paperless in its international shipping. This is a great example of a rules-driven application. Think about it. There are rules about which paperwork/information is required for which countries in which circumstances. These rules change whenever any of the participant countries decide they should. There are rules about what kinds of contents require which pieces of paperwork for which countries. Larger companies using the service probably have their own rules about billing. Add to all of this the problems of returns (many companies ship from one location but expect returns to go to another, potentially based on the content of the package). Unless these rules are externalized and managed the system would be completely unmanageable.

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

Keith posted an interesting piece today on The knowledge bus and Human Rules Management based on a conversation he had with my old friend Jim Sinur. As usual there were some good thoughts in Keith's piece but I do want to take issue with one of his early statements. Unlike Keith, and perhaps Jim, I don't believe that the focus is going to shift "from server-side application automation to client-side human interaction". I do agree that far more focus is needed on human interactions, especially around supporting collaboration. However, I also believe that more automation of interactions is also inevitable, especially between companies and their customers. Self-service is not going away and customers expect more and more options on the web, on their mobile devices etc. These options cannot always include people so server-side automation of these interactions will be critical. This drives the need to automate decisions and to make it more effective for staff to handle and process exceptions and more complex cases. Thus the interactions that are handled by people are more complex, driving a focus on the interactions and on collaboration, but that's not because server-side automation declines in importance.

I did like a comment later in the post:

Looking forward, it may be that we will see a convergence of Business Rule Management and technology support for knowledge work

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

I was thinking about how you can get a competitive advantage from your data and how well traditional tools for analyzing your data fit.

Let's think about it . First you must act differently to get a competitive advantage. Therefore you cannot just understand something better, you must act more effectively. This means you must make decisions differently and that means applying rules and constraints to the insight you get from your data because the real world imposes regulations, policies and constraints.

If you are going to change the way you act it is not enough to improve your reporting on the past, you must also improve your ability to predict the future. This means using predictive analytics not passive reporting or analysis tools.

Increasingly, for companies of any size, your systems are your business - you cannot do without them. Therefore these predictions and rules must go into your systems - your operational systems. Finally, of course, nothing is static so you must constantly challenge and assess the effectiveness of decisions

Given all this, then, traditional BI tools are not, perhaps, the best way to get competitive advantage. Instead, Enterprise Decision Management (EDM), or Business Decision Management as it is sometimes known, is the approach you need - it's an approach for automating and improving high-volume operational decisions. Focusing on operational decisions, it develops decision services using business rules to automate those decisions, adds analytic insight to these services using predictive analytics and allows for the ongoing improvement of decision-making through adaptive control and optimization.

Prompted, in part, by Nathan Jones' post on Using BI to gain a competitive edge

Posted by jtaylor in Business Intelligence • Business Rules • Decision Technologies • Predictive Analytics | 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)

One of the interesting questions about decision services is the extent to which they should be able to gather their own data. Opinions on this range from a limitation of decision services being that they must be passed all the data they require to one in which even long running requests for data, say those involving a human, can be accommodated. Even if we take the position, as I do, that decision services are fundamentally synchronous, we still have a number of options:

1. Pass all the data available into a decision service and force it to either decide or to pass back some reason why it could not decide (to do with a lack of data, say) so that the calling application can assemble the additional data required and try again.
2. Pass the data available to the decision service but allow it to call external services and/or databases to gather the data it needs to complete the decision. Only synchronous calls are allowed as the service remains synchronous.
3. Pass the data available to the decision service and allow it to call external services and to request additional data from a user interface. The decision is still synchronous in that it continues to run/use a thread until the data is provided through the user interface or the request for a decision is cancelled.
4. Pass the data available to the decision service and allow it to gather the data it needs in any way. While the decision remains synchronous, in that the calling service is waiting for an answer, the decision service may be passivated or otherwise put “on ice” while waiting for the necessary data.

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

Opher Etzion had a nice post today - More thoughts on Rules in the context of Event Processing - in which he discussed different ways in which rules apply to event processing. He identifies 5 different areas in which rules can be used as part of an event processing approach and, in the process, reiterates something I often find I have to explain to people. Just because a product or approach uses "rules" (declarative statements of intent) does not mean that it is all you need to take a rules-based or decision-centric approach. In particular I like the fact that he drew a distinction between routing/transformation/validation/orchestration of events and "Intelligent Event Processing." It is this last that is the realm of enterprise decision management and where a coordinated approach to managing of decisions, typically using both business rules and predictive analytics, really pays off. These decisions are typically business decisions that are not tightly coupled to the specifics of your current systems or low-level events. While a business rules management system might well be useful for managing all the rules involved in event processing, probably it makes more sense to manage those rules tightly coupled to the definitions of events in the event processing environment. Once you get into broader business or enterprise decisions, then you need to think about managing those decisions so that they are not so tied to a particular architecture.
Some other posts you might find useful on this blog:

• Complex Event Processing - not just rules
• Decision management is critical to event driven architecture
• Predictive analytics go deeper
• Business rules, routing rules, event rules

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

I saw this post on Offshore Architects, Legacy maintenance and modernization and it struck me, again, how valuable business rules and a focus on the automation of decisions can be in legacy modernization. By separating out the high-change, highly volatile rules into self-contained decisions you can:

• Reduce the number of changes required to the hard-to-modify legacy code by externalizing the high change pieces as easy-to-change business rules.
• Make the core business logic reusable in your SOA through decision services.
• Ensure that the business know-how relevant to your core logic stays onshore, even if most of the maintenance work is offshore.
• Give those architects who think maintenance is boring something more interesting to do - adopting a rules management system and making the changes to the SDLC to take full advantage of it should be fun enough for the most jaded.
• Make re-platforming and the adopting of business process automation or outsourcing much easier by brining the tough business logic under real control

• Modernizing COBOL with business rules
• Live from Delphi - When Your Business Knowledge Goes East
• Using decision technologies to manage application maintenance
• Business rules and the application knowledge deficit
• Lean application development and maintenance - some thoughts
• Using business rules to renovate old applications
• Here's a way to use business rules to manage offshore development

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

As I consider business rules a form of model-driven architecture, I thought I would share this new LinkedIn Group from Joahn den Haan
http://www.linkedin.com/e/gis/50539/04809C3A2E89
The idea is to form a group of folks interested in MDA on LinkedIn so, if you are interested, go ahead and request membership.

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

I came across an interesting article on Martin Fowler's blicki this week - RepositoryBasedCode. In this article he talks about "the idea that the core definition of a system should be held in a model and edited through projections" and this got me thinking about business rules and whether a typical business rules management system (wiki) would meet his criteria.

• They allow multiple representations of the "code" by projecting business user rule management interfaces (wiki), as well as a declarative "programming" interface
• They allow storage of the rules in a variety of persistent stores such as flat files, databases, XML repositories etc.
• They have an executable format, which may or may not be code but that is generated from the stored format.
• They allow you to manipulate and reason about the rules and their interactions using tools such as execution browsers, interactive viewers of the logical interconnections between rules and query tools for navigating the explicit and implicit relationships
• They can represent rules in graphical formats such as decision trees and decision tables as well as various kinds of reporting and read-only reports

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

Shayne Nelson started an interesting discussion this week with a post titled "Making Software Maintainable - Part I. Shayne talks about the promise of case tools in this context, something with which I also have experience having supported and used various case tools over the years. He has a great comment:

What an industry.... creating products for which the documentation (done at great expense) is generally useless, and sometimes worse than useless, actually misleading or inaccurate. It's no wonder that 85% of all programming effort goes into maintenance. When maintaining code, you're generally working blind

"Programming languages today remain syntactic, abbreviated, and procedural, as opposed to semantic, verbose, and declarative"

The right question, then, is not "How much documentation is enough?" but "How does this language force me to write code that is easy to read, easy and safe to modify and understandable to business users so that they can help?". I have blogged before about the problem with programmers and some habits of effective programmers but the bottom line is this: Using business rules, and a business rules management system, moves your "code" up a level and makes it more accessible, easier to read and understand, and more stable in the face of change. Fix that first and then see how much documentation you need.

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

A contact of mine (Nimish Shah) is currently doing a Masters in Computing in the U.K. His research project deals with software tools used to mange business rules and he is looking for some folks to share their experiences and knowledge in this domain. It takes approximately 8-10 minutes to complete the questionnaire. The results of the survey will be used in his Dissertation and posted to the blog for you to see.
http://www.questionpro.com/akira/TakeSurvey?id=801506
(Cross posted to my three blogs)

Posted by jtaylor in Business Rules | 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)

Yesterday I saw an interesting article over on TechRepublic - Sanity check: The 10 biggest headaches of 2007 for CIOs and IT managers. It was a nice list and a couple of items struck me as being great justifications for taking a more thoughtful approach to decision management and the technologies of decision management. The two headaches in question were "Alignment between IT and business goals" and "Dealing with compliance". In both cases the author took a different perspective to mine which is that alignment and compliance, especially in combination, are great drivers for adopting decision management.
My perspective on these two issues is that, with companies automating more and more business processes, ensuring alignment and compliance means making sure that what is coded into the processes and services being automated is aligned and compliant. The best way I know for doing this is to focus on the decisions in those processes and to automate those decisions using business rules. Why does this work?

• Decisions, business decisions, are one of the most critical areas where the business and IT must be aligned. Focusing on decisions explicitly is key
• Business rules, being declarative and amenable to business user management, ensure that the decision logic can be developed collaboratively by the business and IT. This helps ensure alignment
• Business rules are easier to check for compliance than code both because those who understand the regulations can read the rules (but probably could not read the code) and because it is very easy to tell which rules executed for which transaction and this makes it much easier to show compliance

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

My old friend John Parkinson had a nice post over on CIO Insights today - 5 Challenges to Integrating IT and Business. As usual John makes good points about the challenges of technology in general but four of his five made me think about the challenges and opportunities of decision management technologies in particular:

• No clean slate
  Adopting SOA, BPM or any other new approach always runs a risk of crashing squarely into the realities of a body of legacy systems and technology. One of the most interesting ways I see organizations adopting decision management is in taking the highly volatile pieces of legacy systems - typically decision making pieces - and externalizing them using rules and other techniques. This allows them to be reused in other parts of the business, and they are often valuable widely, while leaving most of the legacy application intact and ensuring that the highly volatile piece is now easier to manage.
• Unrealistic expectations
  While it might not be obvious what decision management technology can do about this, I think it is relevant that by bringing the business more directly into the process of managing and updating information systems it can reduce unrealistic expectations. Business users who are doing their own rule writing and testing will have more of an understanding of the realities of technology.
• Out of synch strategies
  The power of decision management to synchronize the business and IT by bringing both sets of skills to bear on the same business problem. Using business rules to allow business and IT to collaborate is well established and can reduce the gap between the organizations.
• Nothing stays the same
  Agility, agility, agility. One of if not the defining characteristic of decision management technologies is their ability to bring agility to information systems. Making it easier to tell what change is needed and easier to make the change quickly and yet correctly is both essential and a direct benefit of these technologies.

You might enjoy this post on agility and this one on business user / IT collaboration. May you live in interesting times...

Posted by jtaylor in Business Agility • Business Rules • Decision Technologies • Legacy Modernization | Permalink | Comments (1) | TrackBacks (0)

December 07, 2007
What collection of approaches will transform YOUR business?

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.

One notable absence from this list, you will notice, is Business Intelligence. An odd omission, you might think, given that BI is on the top of everyone's list of things to do this year. But BI alone will not transform your business. It should help you understand how and why and perhaps where to transform your business. It can make many of the transformative approaches I list more effective by underpinning them with current, accurate, understood data. What I don't believe it can do is really transform your business.
But what do you think?

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

December 04, 2007
Some thoughts on the fallacies of business process execution

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.

Enjoy

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

November 27, 2007
Decision Service Design

I have been thinking about decision service design a fair bit recently, as you might expect. As part of my research in this area I came across this posting by Brenda Michelson - Introducing: Business-Driven Service Design Method which has a link to the recording of the webinar on this topic she gave with Beth Gold-Bernstein of ebizQ. The approach is well worth listening to, particularly since they focus on how to design services whether you take a business process approach, a business interaction approach, a business event approach or (as they recommend) some combination. The basic steps in their process was nicely outlined in this graphic.
It is pretty clear to me, having listened to their overview, that what I call a Decision Service is a subset of what they refer to as Business Function Services. Decision Services might be considered a pattern for Function Services in their approach. Decision Services typically are stateless, short-lived and used synchronously by other services. They take data in, might request additional data and then return information about a decision. They don't update databases, they don't take action, they just make decisions. So far so good.
While one could just use their approach and then identify the decision services as a subset of the function services, I do think that their approach could be useful adapted to include decision services more explicitly:

• They model decision points in a number of their steps. Making these more explicit earlier, and focusing on the unique requirements of decisions, might be more effective than simply applying a design pattern later.
• While they talk about rules and policies in the context of event processing and process variations, explicitly modeling the decisions driven by these rules and policies will make their use, and the impact they have on services, much more clear.
• They discuss the information required by a service but don't explicitly model why that information is required - what decision is going to be taken with it. Being more explicit about the decision making would make it clearer what information was required.

This is an area where I am clearly going to have to do more thinking but in the meantime check out their webinar and perhaps some of these links:

• Decision Service definition
• Modeling Decisions
• Pragmatic Decision Services
• Decisioning in a loosely coupled process
• Diamonds, decisions and processes

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

November 06, 2007
Decision Management, Decision Services and BPM

The current issue of BPM Strategies magazine has a couple of great articles - one on Business Decision Management (BDM), BPM and SOA and one on Decision Services. You can see the current issue online if you are a subscriber here. If you don't already subscribe I would recommend it. The online community is great, the training is good and the magazine often has some good articles. Larry Goldberg and Barb von Halle do a nice job of mapping decision management to SOA and BPM and Mike Rosen has a nice introduction on Decision Services and business rules. I think both could talk more about analytics and data mining as a complement to business rules in this circumstance but I would recommend them anyway. If you are interested in these topics, and you should be, check out these posts:

• Decision Service definition
• Modeling Decisions
• Pragmatic Decision Services
• Decisioning in a loosely coupled process
• Diamonds, decisions and processes

Interesting articles on similar topics include Larry Goldberg on A SOA-based Business Rules Approach: Decision Services and my two articles for SOA magazine - SOA and business rules and Smart Enough for SOA: Incorporating Enterprise Decision Management into Service Design. If you want to buy the book Barb and Larry mention you can do so here.

Technorati Tags: BPM, BRMS, business process management, business rules, decision management, decision service, enterprise decision management summmit, predictive analytics, SOA, business decision management

Posted by jtaylor in Business Rules • Decision Technologies • Predictive Analytic