Copyright © 2008 James Taylor. Visit the original article at Here’s how decision management delivers continuous strategy.
An old colleague of mine, Vaughn Merlin, had a really interesting post this week When Strategy Becomes Continuous. It’s a great post and he makes three key points:
- IT strategy is not the point - it’s all about business strategy.
- Much ’strategy’ effort is not very strategic.
- Strategy formulation and execution are too loosely coupled.
He then quotes Gary Hamel who said “If you want to understand the real strategy, look at what people are doing!”.
It was this last comment that crystalized the link to decision management in my mind. After all, in a modern corporation, it might be almost more appropriate to say “if you want to understand the real strategy, look at what the systems are doing!”. After all, most transactions are handled by systems and, with self-service on the increase, more and more customer interactions are with systems (at least in part).
So that got me thinking. In an era of continuous strategy - where constantly changing and adapting corporate strategy is critical to success - how important is decision management? Critical, clearly. My systems must reflect my strategy and my strategy must change all the time so my systems must be agile. But the kind of changes my systems need to make are changes to decision making - it is the decisions that are implemented in a system that must reflect my strategy.
If we go back to Vaughn’s three points, decision management aligns perfectly. Decision management means putting business people in charge of the behavior of systems (business not IT, point no 1). Decision management focuses effort on the decisions that affect operations (making it strategic, point no 2). And most importantly, decision management ties strategy to execution (point no 3).
Continuous strategy is going to become a competitive reality, decision management is how you can make this work in your information systems. I for one am looking forward to his research on this topic.
ShareThis 
Copyright © 2008 James Taylor. Visit the original article at First Look - Drools 5.0.
When I was in the UK recently I got a chance to have a coffee with Mark Proctor and get a detailed demo of the new Drools release - 5.0.
Mark spent most of the time showing Guvnor, the new web-based business rule management system for Drools. Built with GWT this looks and works great - nothing like a browser application, much more like a real desktop application. Navigating around, open multiple tabs, viewing and editing various assets was all very elegant and responsive. Asset storage uses the Java Content Repository (JSR 170) standard allowing it to use both open source and commercial storage platforms (it ships with JackRabbit, an open source implementation) and ensuring your content is not locked up in a closed proprietary format. Versioning and logging of edits/comments, comments and comparisons and a hierarchical view of the assets being stored were all available making repository navigation easy. A WebDAV interface to the repository is also available allowing remote file storage and access and there is an Eclipse team provider allowing developers to synchronize their development environments with the JCR repository. Authentication is handled through Java Authentication and Authorization Service (JAAS) (so Drools does not require additional authentication beyond what you already use) and roles are defined for users and then used to control the user interface. Import and export of XML packages from the repository rounded out the features I saw. Overall I was impressed with Guvnor and most of what Mark showed me of other features was done from within the browser environment.
5.0 adds a web-based decision table editor as well as a web-based ruleflow viewer that uses GWT Diagrams to show flows (they plan web-based editing of flows in the future, but for now the editing of the flows must be done in Eclipse. The ruleflow editor has been upgraded pretty significantly too into much more of a real decision flow editor or even a workflow editor. The editor is slick and has a nice pallette of features. Splits, joins, for each, subflows, human tasks, timers and an interface allowing you to add you own kinds of nodes make the flow much more extensive than before. DSLs (of which more in a second) can be built allowing DSL nodes to be created in the flow to make it very business user friendly. There are a few oddities around defining the rules for a node and navigating from the ruleflow to the rules but overall I really liked what they have done.
DSLs - domain specific languages - get an upgrade in 5.0. A DSL in Drools is essentially a sentence, written for non-technical consumption, that maps to a condition or action statement for use in a rule. Variables can be defined in the sentence, and then used in the rule statement, allowing the engine to execute the rule based on the DSLs selected, the variables entered and the mappin of the sentence text to rule syntax. For 5.0 the parser has been rewritten and some extensions added, such as use of regex in the templates. More importantly, however, is the integration of DSLs with the rest of the interface. As noted above the flow can use DSL nodes and the guided editor, itself a nice piece of web-based coded, can mix and match DSL statements and pure rules syntax. This allows business users to stick to DSLs, analysts to mix and match DSLs and syntax and programmers to do whatever they like. It does not allow as much customizaion of the interface as some approaches but it certaintly provides a great core.
Scenario testing has been added to Drools 5.0 as it has been to a number of commercial platforms over the last few years. Although it does not support Junit, it has a nice web-based interface that supports some rule verification, coverage, field usage, missing values and other testing. I would like to see JUnit integration - after all rules are only part of an applicaiton and supporting Junit allows all the tests to be run together.
Deployment has also had some improvement with some nice package deployment features and the ability to deploy a very lightweight service that then pulls files, packages, snapshots from the repository as needed to update the local rules being compiled and executed.
Overall this looks like a very strong release, especially with some of the core engine enhancements around temporal reasoning, support for XSDs and delarative type modeling. If the commercial vendors did not think they had a real competition on their hands, Mark and his team will prove them wrong with 5.0. Drools 5.0 is not yet ready for release (they are hoping for a November release) but those of you who like playing with, and contributing to, code that is nearly ready can get it from the downloads page (scroll down). Michael Neale posted Drools 5.0 M2 New and Noteworthy Summary recently and Drools 5.0 M1 - New and Noteworthy before that. You can get periodic updates on the world of Drools from Mark and Michael on their blog.
ShareThis 
Copyright © 2008 James Taylor. Visit the original article at Decision Services, Decision Agents and Event Processing.
I have been doing some presenting on decision services recently - to SAI in Belgium and at the SOA Symposium - and my old friend Paul Vincent posted about a discussion he and I have been having about the relevance of decision services in an event-driven architecture or Complex Event Processing scenario. Paul makes the point that reusing decision services, required for processes or some other element of your architecture, makes perfect sense. However he also notes that
it may not make sense to rely on external (and sometimes relatively high-latency) distributed decision services - especially when the decisions are closely related to the event processing.
I don’t particularly disagree with this. I think that rules and decision-making that are “closely related” to the event processing probably should be part of a “decision agent” that, as Paul goes on to say:
can share many components and ideas – business rules management and business user interface (for business control of the decisions), production rules engine (for efficient execution of declarative rule statements), etc etc.
My rule of thumb for decision services and event processing is similar to the one I have for processes and decisions. If the decision or the rules relates to the process/events and is tightly coupled to them (it will change if they do and vice versa) then it is part of the process/event processing environment. If, on the other hand, the decision would remain the same if the process or events involved were completely altered, then it is a decision that should be managed explicitly. For instance:
- Routing decisions in a call center process are tightly coupled to the process
- The rules for the set of events whose receipt shows that a customer is in trouble are tightly coupled to the events
- The decision that Customer X is an “Important” customer is relevant to both (it may be used in routing and for deciding on the action to take when they get in trouble) but completely independent of both.
Don’t embed business decisions in anything too tightly coupled to events or processes if you can avoid it - manage them as the corporate assets they are.
BTW I have blogged a little about this on my ebizQ blog - here for instance - and I suspect this debate will run and run.
ShareThis 
Copyright © 2008 James Taylor. Visit the original article at Repositories, processes, decisions and more.
Bruce Silver had an interesting article recently on The Next Innovation in BPMS in which he discusses the need for repository capabilities in BPM. Bruce makes the point that "next generation" repositories for process management must not only support process models, they must also support "decision models", business object definitions, performance measurement information and service metadata for deployed services.
Today most of these things are in separate repositories and, frankly, I am not sure this is going to change. For one thing the challenge of a single repository handling everything is great and past experience with "the big repository in the sky" is that it cannot be made to work. Specialization is just too valuable for some of the pieces/people involved. As such one ends up with a federated repository with multiple specific repositories each able to query and link to others.
For this to work I think there are a couple of key features:
- Strong query APIs for all so that one repository can use dynamic queries to access others
- Pre-defined impact analysis so that changes can be analyzed for their impact across all the repositories
- Extensibility so that a repository can be extended to have hooks to another for explicitly linking objects in one to objects in another
- Standards support
- User interface elements suitable for mashup/portal use so that a user can build the view they need
ShareThis 
Copyright © 2008 James Taylor. Visit the original article at Welcome members of SAI!.
I presented at an evening event for SAI, a professional IT organization, in Brussels last night and had a wonderfully attentive and engaged audience - remarkably so considering how late the event was! I promised to post my slides and here they are - a longer version of my decision services presentation.
ShareThis 
Copyright © 2008 James Taylor. Visit the original article at Making BI more decision-centric.
My friend Kurt Schlegel at Gartner has just released a new report - Deliver Business Value With a BICC (BI Competency Center) Focused on Decision Making. In it he “identifies the steps required to evolve business intelligence (BI) beyond reporting measures, to making great decisions”. Like Kurt I believe that “Tying BI to the decision made instead of the measure reported will deliver more tangible business value” and adopting decision management more broadly in an organization can and perhaps should start by bringing the BI folks around to a focus on decisions.
Kurt’s report focuses on how to give existing BI staff and resources a more decision-centric point of view and on the additional approaches / technologies they should consider. The focus of a BICC, even a decision-centric one, is still going to be on manual decisions - those made by people. Getting a top-to-bottom focus on decisions is going to require not only a more decision-centric BI approach but also a focus on the identification, externalization and management of high-volume operational decisions. Whether this means expanding the scope of your BICC or starting something separate will depend on your organization.
ShareThis 
Copyright © 2008 James Taylor. Visit the original article at First Look - SeeWhy.
On my recent trip to Europe I got my first chance for a real look at SeeWhy’s product and their announcement today of SeeWhy Tracks Individual Customers’ Digital Mood seemed like a good reason to blog a little about this interesting product. The latest version helps manage customer experience by analyzing page errors, page load times and abandonment of critical processes for very large numbers of customers simultaneously.
SeeWhy delivers in-memory profiling of event streams. Using sliding time windows, aggregation functions and more they can track very large numbers of profiles in real time. One customer, for instance, tracked 5.5M profiles simultaneously, tracking many tens of millions of transactions in a few months against those profiles. The technology allows the definition of metrics, both individual and aggregate, that are then updated in real-time as events are received. For each profile, or for the overall set of results, the last event received is “time zero” and sliding windows (of 24 hours or 30 days for instance) are managed based on that fact. Averages, maximums and calculations/comparisons for these time windows are tracked and recalculated for all the relevant profiles as events are received. Calculations can be simple (addition or multiplication), more complex (excluding outliers or doing regression analysis) or custom depending on what is required. Actions, consequences, can be defined for these metrics so that systems can respond automatically to thresholds or other metrics.
One feature I found interesting is that updates can be “chained” - the first calculation can be triggered by the receipt of a specific event or transaction while other calculations can be triggered by updates to the first calculation for instance. This allows progressively more complex calculations to be layered and all triggered by a single event with a high performance profile. Definition of this was straightforward and seemed very business-friendly. Comparison of actual to expected and of individual to collective values are easily specified, helping to bring specific patterns to the surface so they can be actioned.
One example SeeWhy used was of fraud detection, specifically of processing the potentially fraudulent transactions found by some other system given those transactions have a relatively high “false positive” rate. The SeeWhy system was able to prioritize the potentially fraudulent transactions for follow-up more effectively so that a team of agents went from finding 14 instances of fraud in 1,000 transactions to finding 14 instances in the first 112 and 124 in the full 1,000. The event analysis helped accurately differentiate the different circumstances that were triggering the original fraud rules. Another was of analyzing initial customer behavior (right after onboarding) to “nudge” customers to try things or do things that will help establish them as “good” customers by detecting that their behavior patterns are trending to less-good.
ShareThis 
Copyright © 2008 James Taylor. Visit the original article at Introducing SOA Design Patterns.
Thomas was back on talking about the catalog of 85 SOA Design Patterns that he is publishing this year - SOA Design Patterns . Design patterns are a field-testing or proven design solution to a common design problem. Some are compound, most are atomic. These SOA Patterns overcome common design challenges for the successful adoption of SOA and range from high-level ones like the boundary of services for an enterprise to very low level ones about contracts etc. The patterns are classified as service inventory, service design, service composition and some compound design patterns. The service design patterns, as a set, represent almost a basic approach or methodology to service design based on the core ideas of separation of concerns.
The patterns have relationships with the design principles and architecture types (discussed here) as well as with each other. One he particularly wanted to highlight was “Domain Inventory”. This pattern addresses the issues that arise with trying to inventory services enterprise-wide such as global data models, organizational issues and governance. The pattern involves establishing domains within the enterprise, typically related to lines of business, and then creating a service inventory within that domain. This approach reduces organizational issues but will require the use of some integration patterns to overcome the differences that will result from domain-specific inventories. While not ideal it does address a big issue without devolving down into very siloed initiatives. Standardizing and governing these domain by domain can be very effective in organizations that struggle with enterprise initiatives.
He also talked about process layer services (non-reusable logic), entity services(based around a business entity) and utility services(technical functionality with no business model). Clearly decision services are a form of entity service (Is this claim valid for instance) while the technical aspects of, say, using a BRMS might be utility services.
He spent some time discussing the set of patterns related to Enterprise Service Buses. This compound pattern consists of a number of patterns identifying the capabilities and features of an ESB such as broker, messaging, event-driven messaging, policy centralization etc. A similar set of patterns relate to Orchestration and this set includes Rules Centralization (highly compatible with Decision Services about which I presented and that Thomas plugged very nicely).
The site for the book also has candidate patterns that did not make the book. These mostly did not have enough real-world proof points (yet).
ShareThis 
Copyright © 2008 James Taylor. Visit the original article at Decision Services - A Pattern for SOA.
I just finished presenting at the SOA Symposium and if you are interested in my presentation you can find it on slideshare.
ShareThis 
Copyright © 2008 James Taylor. Visit the original article at The Business Operations Platform.
The folks from Cordys presented their view of the new business operations platform. Current systems development is in the context of four key game-changing trends:
- Consumerization
Not just technology but can deliver business processes as services using the Internet
- Commoditization
- Virtualization
Not just of hardware but of processes and teams
- Globalization
In this environment, processes are a key competitive advantage - much more than many elements of IT (thanks to commoditization). Challenges include showing a single view of my business, optimizing allocation of scarce resources and flexing operations while remaining compliant. Efficiency stems from predictability but rigidity is a real problem.
Today, most companies have duplication of activities and processes, everything is locked away in old environments and it is difficult to outsource or to manage anything but the basic processes. Reengineering processes created a “to be” vision but implementing and customizing ERP delivered, at best, a compromise between the as-is and to-be visions and did so far too long after the original design was made. The time to innovate IT infrastructure (many years), creates friction with the much more rapidly changing business strategy and organization. To reduce the friction you need a process-centric “business operations platform” that builds on the back-end you already have. The idea of managing change in a layer above the back-end systems is one with which I agree but I think decisions are as important as processes in this respect.
The business operations platform, in their mind, uses a Business Process Management Suite (BPMS) and Business Activity Monitoring (BAM). These consume services for business logic, master data management, business rules and more and are layered over a corporate data backbone. The need to extract business rules (decisions) from processes is critical to keeping processes simple enough to bring business users into this process. In addition, third party web service integration and user-driven mashups are required and the whole thing needs to run reliably and scalably.
Processes, while important, are not the end of the road. Well designed business services that make up a process help eliminate complex processes, keep my processes “skinny” and allow for more reuse. Reuse involves understanding KPIs, service-level agreements and metadata for business services. A business operations platform therefore allows:
- Construction of processes from reusable business services
- Share processes and services internall and externally
- Build and sell services
- Build processes dynamically as needed
- Work in an on demand environment
The final state is one where you:
- Are proactive not reactive
- Have a seamless environment
- Link and share systems and resources
- Have very “skinny” processes
- Manage exceptions dynamically
- Have full visibility and status of the supply and demand chain
ShareThis 
|
