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)

The bloggers here at ebizQ got an interesting question - can one benchmark agility? Joe posted the question on his blog and I heard Sandy Carter of IBM talk about (and blog about) "Key Agility Indicators" - IBM, in turns out, has been trying to establish how to measure agility. I blogged about this before, however, as I don't think IBM is using agility the way I do or the way Joe does. Agility to us, I think, is a measure of responsiveness to change rather than responsiveness to customers or to orders. It is not the time it takes a company to, for instance, restock a product. While that's an interesting thing to measure, it is not agility to me. The time it takes a company to change its reorder approach or a specific product/vendor is, however, a measure of agility. Here are some thoughts on the topic. What do you think?

• I would argue that agility is the time and cost involved in making a change to the way in which a company behaves and not the time or cost involved in it executing that behavior.
• A increase in agility means changing systems, people and processes so that it is cheaper and quicker to go from a current, sub-optimal state to a future, more optimal state.
• Agility is the lag between the first moment when it is theoretically possible for an organization to know it should change its behavior to the moment at which it has successfully done so
• Measuring agility means measuring time to notice that action is required, time to decide what action to take, time to take the action and time to make sure the action has the desired effect.
• Agility would seem to require performance management, event-based architecture, flexible and changeable systems/services and organizational skills

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

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)

October 30, 2007
Policies, procedures, policies and rules - a point of view

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)

September 26, 2007
Wish I was there...

Sandy has been at the Forrester event and posting some great stuff on business process management, business rules and business intelligence. Today I read five posts that you shouldn't miss:

• Forrester Day 1: Automating Business Processes panel
• Forrester Day 1: John Rymer
• Forrester Day 1: Rich Phillips, Maritz Travel
• Forrester Day 2: The three B’s
• Forrester Day 2: Skipping class

She posted the slides for her presentation in the last one and slides 21-24 are particularly excellent. There were a number of points made in these that I wanted to call out:

• Business process management and BPMS products bridge the gap between end-user computing and full on application development. Business rules, used to automate decisions, can also bridge this gap by putting the business in control of decision-making logic in processes, in legacy systems and in enterprise applications
• As John Rymer pointed out, business rules help you build for change so you can deliver systems that respond rapidly and safely to changing business conditions.
• One of the best ways to get control of processes being managed using BPM and developed on an SOA platform is to build decision services that encapsulate and manage the decisions within them.
• One of the great values of considering business rules, business process and business intelligence as a set is that rules-based decisions are a great platform for embedding analytics into process as I discuss in this article
• It is this combination that drives agility, as I have noted when discussing agility as defined by Gartner
Wish I could have been there...

Technorati Tags: business rules, business process, business intelligence, Forrester, business agility, Sandy Kemsley, column2

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

September 24, 2007
Straight Through Processing for real

Sandy Kemsley had a series of interesting posts from the recent Gartner BPM summit. Two caught my eye especially. This one about a Bill Gassman session and this one about a Janelle Hill one. Both of them made me think about straight through processing or "hands free" or "lights out" or whatever you call it. Bill's session talked about reducing the "latency between events and actions" and emphasized business activity monitoring (BAM) as a solution. Janelle meanwhile implied that a focus on effective processes not just efficient ones meant that the focus in business process management (BPM) was no longer on straight through processing (STP) but on collaboration and softer aspect of processes. Both sessions to me pointed out a basic problem with the definition of straight through processing. If you are using BAM to get actions taken in response to events or just using a BPM tool to automate processes, then you are not doing STP for real.

Real STP means no manual intervention for the vast majority of transactions - say 90-95%. It means automated responses to events that should trigger processes or actions. It means handling these transactions as well if not better than a person would, not simply automating it in a "dumb" way. This means people cannot be required to respond to time-critical events and that processes must have access to sophisticated decision-making so that they don't have to refer something to a person or make dangerously over-simplified assumptions about how customers or transactions should be handled. This kind of real STP requires a focus on decision automation and decision management, not just on event or process management.

Janelle identified six types of process, similar to the three types IDC talk about, and these seem to boil down to event centric, people centric (or unstructured) and transactional. There is a role for decision services in all of them. In event-centric ones, a decision service can ensure that the right process is started or right action is taken. In transactional ones, decision services can increase the rate of STP while also improving the quality of decision making and maintaining agility (as defined by Gartner and discussed by me here). In people-centric processes, decision services can guide and direct, refer and route according to complex rules and analytics. Indeed this kind of automated decisioning is at the heart of many kinds of solutions and neglecting it while consider BAM or BPM is a bad idea.

[Sorry for the pause in blogging, back now]

Technorati Tags: BAM, BPM, business activity monitoring, business process management, Column 2, decision service, Gartner, IDC, Sandy Kemsley, STP, straight through processing, event processing

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

September 05, 2007
Don't just move your chair

I saw this post over on Steve Jones' blog - Want to get closer to your business? Then move your chair. While I agree with his basic premise I think he stops short of what it really takes. Clearly one of the requirements for effective collaboration is a willingness to work on the same problem at the same time (and ideally in the same location). However, if the IT people want to talk about code and the business people want to talk about policies, regulations or pricing strategies, this is going to be a problem. The business people don't read code, and mostly don't want to. The IT people might want to understand the business, but it's not realistic to have them know enough to keep up. What you need is an approach, and some technology, that let's both "sides" talk about the same thing. The technology in question is a business rules management system and the approach is one of automating and managing decisions, using business rules, separate from other aspects of the system.

This approach, and this technology, allows the business and IT to work collaboratively (even on the same rules if they put their chairs close). It also addresses one of the problem with programmers and helps the IT people embrace the changeable, unstable nature of business (as discussed in my business rules café article). It takes some work to engage the business in this process (there are some secrets of business user rule maintenance) but it is worth it. Smarter systems, increased agility, better collaboration. All yours for the taking.

Technorati Tags: BRMS, business agility, business rules, change time, collaboration, decision management, Smart (Enough) Systems, smartenoughsystems

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

September 04, 2007
Business rules, requirements and use cases

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)

July 20, 2007
Composite applications, business processes and decisions

After yesterday's post I guess I was bound to immediately find another reason to blog about decision management in the context of business process management (BPM) and composite applications. Sure enough an article on InfoQ caught my eye - BPM + SOA as a Composite Application Model is Gaining Mindshare. The article had some useful links and a nice summary of the way in which process-centric composite applications, assembled from existing and new services, can be developed using business process management tools. There were three comments that really caught my eye:

• "It has long been recognized that traditional application models are not geared towards changing business processes easily"
  Nor do they allow decisions to be changed easily and real agility requires both process and decision agility.
• "In a J2EE or .Net programming model, processes are hard coded. Charles Simonyi compares this type of coding to an "encryption" process"
  I love this idea - coding as an encryption process! I blogged about not developing write-only code once before and had a comment about Charles previously too.
• "critical pieces of the business process context ... are captured in notes or spreadsheets at best"
  And decision logic is probably not captured at all!

Technorati Tags: agility, BPM, business agility, business process, business rules, decision automation, decision management, decision service

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

July 19, 2007
Support your local sheriff

Russell Keziere wrote an interesting little article this week - BPM Sherriff Rolls Into Town. He took aim both at old-style monolithic applications and at the potential "wild west" of uncontrolled components. I wanted to focus on a couple of key points. First he said

"Monolithic computer applications, which only a software programmer can change, promise to do everything but end up solidifying or creating silos within business departments"

and later he added that

"ERP applications will be with us for years to come"

His suggestion was to use a BPMS as part of the composite application development process and to help IT get control of its own governance processes. While this sounds like an excellent idea, I wanted to return to the idea of using a BPMS to do the composite application assembly needed to truly exploit SOA. If your BPM sheriff is not able to call on effective decision services then you won't really be able to generate true decision services - your process will be easier to change and your services more self-contained, but only a focus on decision making services as a distinct class of services is really going to get it done. Not only do decisions require a different approach, it is important not to over-synchronize them with your processes if you don't want to create a new monolithic process! Over on my other blog I talk about use of decision services for the last decomposition of the application. A focus on decision services also allows you to use decision management to complement ERP and use SOA, BPM with your Enterprise Applications.

Technorati Tags: agility, business agility, business rules, decision management, decision service, service-oriented architecture, SOA, enterprise application

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

July 11, 2007
Decision management at the heart of your digital business

Randy Heffner of Forrester recently wrote A Taxonomy Of Platforms For Your Digital Business (subscription or payment required). I have blogged about the digital business architecture idea before, and about Concurrent Business Engineering, and commented on the need for more than just a BPM suite to deliver agility in response to another Forrester paper. I like where the Forrester folks are going with all this. As the summary of this paper says:

"As a top-level conceptual model for planning the future of your technology and architecture, Digital Business Architecture aligns your planning with a new reality: More and more, the design of your business must be directly reflected in the design of your technology."

Indeed this is a core premise of the book I wrote with Neil Raden recently, Smart (Enough) Systems. If your business is your technology and your technology is not smart enough then neither is your business! Randy's summary goes on to say

"The business goals for each technology domain are the basis for a taxonomy of seven major strategic platforms for digital business: SOA platform, information fabric, interaction platform, Information Workplace, unified communications platform, business service management platform, and business design platform."

This is a nice division - as he notes, any division has its issues, but this one seems pretty good. I think a big part of how an organization designs its business is reflected in how it manages its decisions so a focus on decision management would fit right into the business design platform or business metadata core. Randy goes on to emphasize a number of reasons for a digital business architecture and it seemed to me that a number of these would be enhanced by a focus on decision management:

• Dynamic business applications
• The ability to constantly adapt the decisions within your applications, and thus the applications' behavior, is one of the main outcomes of decision management. Not only does the use of rules as a platform for decisions improve their agility, the separation of decisions (as decision services) allows them to be properly identified and managed and the use of adaptive control makes controlled experimentation and evolution possible.
• The new programming model for digital business
• We know that traditional approaches to building applications, or even services, do not result in the business/IT collaboration we need. Using business rules and separating out the high-change parts of applications and processes as decisions makes a huge difference.
• Strategic platforms for digital business.
• Only a focus on decisions gives you a single place to bring expertise, regulation, policy and data-driven insight to bear on a single problem.

He goes on to discuss rules and analytics a little:

"Along with [the strategic platforms] are six subplatforms for event management, business process management, business rules, analytics, configuration management, and security. The strategic platforms for digital business provide focal points around which you can structure and design the future of your technology base."

So, as you can see, he identifies analytics and rules as sub-platforms that are embedded within one or more of the major platforms. While this is undoubtedly true - many of these platforms should have rules and analytics embedded, I don't think this is the same as using these technologies to deliver the ability to design and manage the operational decisions at the heart of a business. For that you need to make sure that your business design platform allows you to automate, manage and connect operational decisions. Enterprise decision management.

Technorati Tags: adaptive control, agility, business agility, business rules, concurrent business engineering, decision automation, decision management, decision service, digital business architecture, EDM, enterprise decision management, forrester, Neil Raden, predictive analytics, Smart (Enough) Systems, smartenoughsystems, Randy Heffner

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

July 09, 2007
Two good articles on rules and decision management The lead article on Intelligent Enterprise today is one by Barb von Halle - "The Rule Maturity Model: Five Steps to an Agile Enterprise" - well worth a read as an introduction to the stages of adoption of business rules technology. The second is a Q&A with me about the book I just finished with Neil Raden - "Smart Systems Without Rocket Science" - worth a read as a quick introduction to the topic of the book, building smarter systems using business rules and analytics.

Technorati Tags: agility, business agility, business rules, decision automation, decision management, EDM, enterprise decision management, Neil Raden, predictive analytics, Smart (Enough) Systems, smartenoughsystems, Intelligent Enterprise

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

June 12, 2007
Decision technologies and driving agility

Michael Hugos over at CIO magazine had an interesting post today - The System Builder Drives IT Agility. He makes five suggestions on which I thought I would follow-up:

• Understanding business operation - shared understanding presumably despite the different perspectives of business and IT
• Inclusive process - one like concurrent business engineering, for instance
• Tolerate not knowing - both because you need to investigate the issues and because those issues change
• Simple underlying pattens - rule templates, for instance, to empower business users to maintain their own rules
• Simple combinations - for instance, when decisioning is called for use decision services to keep everything clean and packaged

He also referenced this one - The 30-Day Blitz, IT Agility in Action - and I think business rules and decision services are often a very effective way to add value to existing systems quickly and without completely re-writing the systems concerned. Check out this legacy modernization story, for instance, or posts in the legacy modernization category.

Technorati Tags: agility, business rules, change time, CIO, CIO Magazine, decision automation, decision service, Michael Hugos, business agility

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

June 08, 2007
BPM, BPO, BI, CPM, SOA, EDA, CEP, BAM and .... EDM?

Michael Dortch blogged a post over on the BI in Action blog today - BI, BPM, and SOA: Alphabet Soup that's GOOD for You! Inspired by his comments I thought I would see how many TLAs I could get in a title while still writing a coherent post. I managed 9 (yes, I know, BI is not a TLA technically but whatever):

• BPM or Business Process Management is about defining, managing and controlling the business processes that underpin your business
• BPO or Business Process Outsourcing is about contracting with someone else to run one of these business processes for you
• BI or Business Intelligence is about understanding your business by analyzing the data you have
• CPM or Corporate Performance Management (sometimes called Business Performance Management) is about monitoring the results your business is achieving through analyzing the data you collect
• SOA or Service-Oriented Architecture is an approach to building an application architecture from loosely-coupled component services
• EDA or Event-Driven Architecture uses events and the responses systems take to these events as the primary organizing principle of systems
• CEP or Complex Event Processing involves correlating many events, often related to different business processes, and then automating an appropriate response to these events
• BAM or Business Activity Monitoring alerts businesses to problems, issues, goals met or other indicators of how well a process is executing, typically in real-time

So now all I have to do, having ransacked Wikipedia for definitions, is tie all this together

• If you automate a business process with BPM, how do you get straight-through processing if people must make all the decisions?
• If you outsource a process with BPO, how do you keep control of the critical decisions in that process?
• If your BI systems tell you what worked in the past, how do you apply that to decisions you will take in the future?
• If your CPM environment tells you something is going wrong, what decisions can you take to respond?
• If you are using SOA to be more agile, what happens when a service makes decisions that must change often?
• In your EDA, are you just going to tell people to act or are your systems going to take a decision to act in response to an event?
• Once you have correlated your events in your CEP system, how do you decide what should be done?
• When your BAM dashboard tells a manager you have hit a goal, they can change their decisions but how do they change the decisions taken by their systems?

Decisions, decisions, decisions. And that brings us to the 9th TLA - EDM or Enterprise Decision Management. Enterprise decision management, or decision management, is an approach for managing and improving decisions. It involves separating out the operational decisions in your environment, automating them using business rules and predictive analytics, and then managing and adapting them over time to ensure they reflect changing conditions. As you would expect, these are topics I have written about a lot. You might start with this post on decision services as they are key to embedding automated decisions in your application architecture. Regardless of where you stand on SOA and EDA you should check out this post on SOA and EDA and why decisioning complements both and this one on reasons to automate decisions when adopting SOA. I also wrote this article on rules and SOA and this post on being event-driven and decision-centric. There's a fair bit on the blog about the intersection of BPM and BI and I wrote this article on how business rules can be a platform for bringing BI to bear on BPM. I have blogged about why rules are needed in CEP and on how decisioning complements BAM as well as this article on shifting your CPM into action. There some stuff on how rules and decisioning can make BPO work better and some of this is summarized in this post about driving overall agility. There's also a lot more on these topics and others on my other blog, www.edmblog.com, to which you can subscribe here.

Phew. I am worn out by all these acronyms.

Technorati Tags: adaptive control, automated decision making, BAM, BI, BPM, BPO, business process, business process outsourcing, business rules, CEP, decision automation, decision service, EDA, EDM, enterprise decision management, event-driven architecture, predictive analytics, SOA, service-oriented architecture

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

June 05, 2007
Decision Management and Smart (Enough) Systems

<shameless commerce>

As some of you know by now I have been working, with Neil Raden, on a new book. As the files shipped to the printers today I thought I would take the opportunity to shamelessly plug the book here on the blog. The book's premise is that much of today's existing technology has the potential to be "smart enough" to make a big difference to your organization's business and that current business trends are forcing you to build smarter systems. Like this blog, the book discusses how focusing on decisions as distinct opportunities for improvement, you can use established technologies in a new way to solve problems and create competitive advantage.

You can pre-order it here from Prentice Hall (there is even a blog discount coupon code TAYLOR7962) or from amazon.com here (amazon.com has not yet decided what price it will charge).

The book has a companion site too - http://www.smartenoughsystems.com where you can subscribe to news about the book/authors and read the testimonials we got. Over time we will add more useful links to the site.

If you are not yet convinced that you need to read the book, why not try the digital shortcut "Why you Need Smart Enough Systems". You can buy it online from Prentice Hall  for less than $5! If you need to be convinced that you need to use decision management to make your systems smart enough to be useful (or if you have colleagues or customers who don't understand why they should apply the techniques we talk about on the blog), you will find this a good read.

</shameless commerce>

Technorati Tags: adaptive control, business rules, data mining, decision, decision automation, decision service, decision service, EDM, enterprise decision management, optimization, predictive analytics, Smart (Enough) Systems, smartenoughsystems

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 • SOA | Permalink | Comments (0) | TrackBacks (0)

May 30, 2007
Closing the decision loop

My pal Madan asked an interesting question over on the BI in Action blog. He was discussing the problems of "predictable" marketing and asked how to:

"manage post-analytic decision maintenance for smarter decision making. Or in other words how predictive analytic systems can be more self-learning based on their success or failure, and adjust decision strategies accordingly. Without that critical feedback loop it's all really just predicable analytic marketing"

The solution to the problem involves two things - more models and something called "adaptive control". More models first. As companies become more sophisticated users of analytics they will find they can built many models for a prospect or customer. The likelihood that this offer will attract them, the likelihood that they will apply for and activate the offer, the likelihood that they will not pay their bill on time and so on. These models must be traded off against one another - I might mail someone who is low risk even if they are unlikely to accept and not mail someone who is high risk even though they would accept in a heartbeat. Effective use of information collected about how customers and prospects respond to offers can be used to build a wide variety of models. In Madan's case it is not enough that he has a high likelihood to need moving services (one model), he must also have a reasonable likelihood of actually buying such services when offered (another).

Adaptive control is actually the more important concept here. The challenge with decisions is that customers (and others) respond to the decisions you take outside your system. You may or may not get a response that tells you what they are thinking. The problem is that if you make the same decision every time (always sending more mail, say) then you only learn about their reactions to that particular decision. Adaptive control involves setting up your systems to be able to make one of several decisions. One of these is typically the "Champion" or the one you think it most likely to work and the others are "Challengers". A small percentage of your transactions are then routed through the challengers and results tracked. The idea is to learn about reactions to other possible decisions (stopping mailing after the first is ignored or stopping mailing after, say, 5 have been ignored). If one of the challengers does better than the champion then it becomes the new champion and you start testing again with new challengers. You might also find that a subset of those being tested give better results for a given challenger and this would allow you to design a new segmentation approach to make sure the people who fell in that subset get treated that way. You test, you learn, you refine.

So why don't companies do adaptive control more often? Well sometimes it is a question of not being willing to test any customers with what might turn out to be a worse approach (risk avoidance), sometimes it is arrogance (this is the best approach, why would we try something else) and sometimes it is a problem with IT people not realizing that decisions are different. No amount of design, requirements management or investment of any kind will ensure that a decision is optimal forever. Decisions must be made to change easily and often. In this they are unlike most other kinds of "code". Without a mentality that decisions are different you cannot build an adaptive control mindset and without one you will not justify the necessary software, process and data investments. This is why we talk about decision management not just decision automation.

I blogged about adaptive control over on my other blog if you are interested.

How'd I do Madan?

P.S. there are some odd rules in the credit world. Essentially, and don't quote me on this, if you pull someone's credit information as part of a marketing campaign you must offer them credit. Companies try and define a good target segment and then only pull the records for that segment but, having pulled it, my understanding is that you have to get some kind of offer. In other words they may know you are not going to accept but, because you fell in the category they pulled, you have to get one. Or something. That said, Madan's problem is clearly a real one as it occurs even where no such legal issues exist.

Technorati Tags: adaptive control, analytic application, automated decision making, BI, business rules, decision, decision automation, predictive analytics

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

May 22, 2007
Techniques for Agility

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