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)

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)

I saw this nice article over on TechRepublic on 10+ things that can send an IT project off the rails. It is a nice summary and it occurs to me that the use of business rules to manage and automate decisions can make a big difference to some of them.

The first one is, of course "#1: Sloppy requirements". As I have noted before, business rules are not requirements and the failure to recognize them as separate things causes some of the problems in requirements definition. The requirements are sloppy because they embed the rules that change and evolve. Using a business rules approach to manage business rules separate from requirements helps keep requirements cleaner and less sloppy (though you can still do a bad job of them, obviously). The use of business rules to manage decisions in this way also helps with "#4: Scope creep" as the rules can evolve and change and get more complex without impacting the main software development project or requirements scope. All of this helps with "#2: Schedule slippage" and "#3: Budget overrun" as one of the prime drivers for these two is the constant flux inherent in business rules. Separating them out and managing them separately helps avoid problems in them.

Two others are worth noting - "#6: Poor documentation" and "#8: Poor communications". The post talks about these in terms of poor project documentation and poor project communications, in which business rules cannot help much, but they are also relevant in a broader sense - if the business participants in the project cannot see from the documentation what is being built and are not communicated with, the project will have problems. The use of business rules to specify decisions means that business users can read and understand the business logic being proposed and even implemented, resulting in better documentation and stronger communication between the two "sides".

BTW I added a new category for posts about requirements as I seem to be writing more of them.

Technorati Tags: business rules, IT project, requirements, scope creep, business agility, TechRepublic

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

Scott Sehlhorst had a nice post today on Business Rules Hidden in Use Cases and, as I have not really talked much about rules and requirements on this blog I thought I would point my ebizQ readers to the post and, indeed, to Scott's blog. Managing the rules of your business like they are requirements is a bad idea - rules are not requirements. Scott's article is great, focusing on rules and use cases, and I blogged once before about this in the context of a presentation I saw - Live form Brainstorm - Business Rules and Requirements Management at the IRS.

If this topic interests you, Scott and I are speaking on this topic at the 10th annual Business Rules Forum - an event that is a great way to find out a lot not only about business rules, business rules technology, decisioning and decision management, how rules and decisions fit in SOA and much more.  Scott and I have a session near the end called "Getting It Right. Rules and Requirements in Software". I am also speaking on "Business Rules, Decision Management and Smarter Systems" with Neil Raden, my co-author on Smart (Enough) Systems. This year's event has speakers on business rules, semantics, data mining, BI 2.0, decision management, SOA and much more. You can see the full list of presenters, and their companies, here. There is a PDF of the schedule posted and you should not forget the tutorials that run before the main conference as they offer great introductory material for those new to the subject.

Readers of the blog can get a $100 discount using this code:7DJTDV. So now you have no excuse not to register for what promises to be an excellent show.

Technorati Tags: business rules, Business Rules Forum, decision management, requirements, rule management, Scott Sehlhorst, Smart (Enough) Systems, smartenoughsystems

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

Michael Hugos had a nice post over on CIO magazine - Six Techniques Lie at the Heart of IT Agility

It is an interesting list. I am not sure I would add to it so much as make some observations:

• JAD
  Managing the rules of your business like they are requirements is a bad idea - rules are not requirements. Using JAD techniques (and others) to develop rules and requirements in parallel is a good one.
• Process Mapping
  One of the key elements in good process design is the effective and systematic identification of decisions that impact that process and the consideration of those as separate opportunities for automation.
• Data Modeling
  As the power of predictive analytics grows, it is no longer enough for programmers to analyze data in traditional ways, they must learn what kind of predictions can be made from the data, what insight can be gained from it, and how that might be used in their application.
• System Prototyping
  Prototyping code is important but so is identifying the pieces of the application  or service that change all the time and creating an environment in which the business users can do the evolving of that component, not IT.
• Object or Service-Oriented design and programming
  Decisions can be a little orthogonal to objects and decision services deserve to be considered as a separate class of service.
• System testing and rollout
  The value of testing is highest when the people who understand the business are engaged in the testing of the business logic and this takes the approaches noted above. Rollout is also the beginning, and not the end, of an application's life and the whole process up to that point needs to remember that this is the case. Change-time is coming.

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

Someone pointed me to this wonderful Joel on Software article - The Iceberg Secret, Revealed. I wanted to post about it mostly because it is VERY funny and well worth a read but partly because some of his points seemed particularly relevant to business rules. In particularly his summary key point:

Customers Don't Know What They Want.
Stop Expecting Customers to Know What They Want

I love it! This is why business rules as an approach is so compelling - the business users don't need to know what they want. Instead, they can figure it out over time or, more specifically, over time once they have a working system (before which they will just be guessing anyway). It also allows a development team following Joel's advice to figure out the kind of thing users want so as to give them control over the specifics. Joel discusses this in terms of the user interface but business rules allows you to do this with the core logic too.

Now Joel goes on to talk about some practical guidance for projects other than the use of business rules but the value of the approach in solving this kind of problem is compelling. Check out the rest of this blog or the requirements section over on my other one for more.

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