Skip to content

{ Category Archives } ·conferences

Pimping Your Fish at DemoCamp Toronto 25

After we heard from Gurbaksh Chahal, the rest of DemoCamp proceeded as usual. We were in the Ted Rogers School of Management, part of Ryerson University, in a really great lecture hall space that seats a few hundred people; it seemed like most of the seats were filled that night.

First up was Albert Lai of Kontagent. Albert demoed at the first DemoCamp and has appeared at at least one other. He seems to get a bit of a pass from the organizers: this time, as with the last time that I saw him, he had no actual demo – which is typically a requirement – but a lot of slides talking about social games.

After that, it was mostly Facebook night at DemoCamp: four of the five demos that followed were Facebook applications.

Next up was Mark Zohar of Scenecaster, showing the My 3D Cards application on Facebook. It uses the 3D foundation that they’ve built for enterprise projects, and used it to to take Facebook content and other rich content (video, photos, external links) to create a 3D rich media greeting card, displayed in a 3D application running in the browser using a custom Flash viewer. The idea was to show an immersive, engaging presentation of content for a specific purpose. The second app that he showed was Causes, which creates 3D content posted to your Facebook wall related to charitable causes. For causes such as Red Cross and WWF, it shows an “I donated” card with your picture, links to video about the cause, and a link to the donation site. They’re also working on an app for virtual gifts, using animated 3D, supporting multimedia and user-triggered animation; in the future, they’ll be looking at branded virtual gifts, too. In addition to their own apps, they’re syndicating their apps to other developers for other vertical applications; the first of these being developed is a 3D yearbook. These will be premium offerings, directly monetized within Facebook. They have a team of 5-6 dedicated people, using AWS, EC2 and S3 cloud-based content, composited at the client.

The demo that gave me this post’s title was by Greg Thomson of Tall Tree Games, showing their Fish World Facebook app: you can buy, raise and feed fish in a tank. (The friend I was there with turned to me and said “hey, my son plays with that!”) The focus of the demo was on monetization, a key subject for Facebook app developers: in this case, tanks are monetized through a variety of purchases, including fish, themes (including seasonal and holiday themes), plants, music and food. It uses two currencies: Facebook internal “coins” and fishbucks, which are actual purchased currency, at 5 fishbucks per $1. They find that they need to release new content a couple of times per week in order to maximize consumption; this is often done by creating a need (e.g., tank gathers algae, friends can steal fish), then selling a solution (e.g., algae-eater, security fish). They’re using analytics for targeting specific audiences, and in spite of my friend’s comment about how her son (who is under 10) plays with this, Thomson said that their primary demographic (75%) is women 20-35 years old. Huh?

Greg Balajewicz of Realm of Empires was up next, showing their massively multiplayer online strategy game on Facebook: you start with a village, build it up, recruit troops and so on. Everyone in the game is an actual person, with the game ongoing 24×7, and you can collaborate with others to plan battles and other campaigns. They have about 80k monthly active people in the game, 20k active daily, and although the game is free, they monetize with premium features that save you time in the game (e.g., a larger map view), but don’t explicitly advance your position in the game. They also have a standalone app, currently not monetized although they might offer a premium feature like this within the game, that allows any player to get a world view of all villages. They’ve done this with a small team and the three founders, with most people working remotely from each other and communicating using Skype. The game is targeted at men aged 25+; it can be played effectively in as little as 15 minutes per day. About 60% of their current players are in the US, 30% in other western countries, and a significant southeast Asia population at 7%.

Oz Solomon of Social Gaming Studios showed us their two seasonal apps: My Year in Status, and My Year in Photos. My Year in Status allows you to capture your year through your status: select a style, add a caption, and it generates a (text) collage of your status updates from 2009; you can customize and publish it to your news feed. My Year in Photos picks 16 photos from your 2009  photos (you can choose others if desired), then generates a photo collage for your news feed and photo album. Unlike the other apps, which are looking for steadier, constant growth, the seasonal apps had to spring into action for only a short period over the year end. They had 11M people use the app in a three-week period, with over 45 collages generated every second; it was the 3rd fastest-growing Facebook app for the week of Dec 21st after being covered by the mainstream media. About 80% of the users are women. They started work on the app on November 13th, launched it four weeks later, then had to do three server upgrades in a week to keep it up and running: they are using their own dedicated servers rather than cloud infrastructure. They found that seasonal apps are good for capturing viral streaks, but it’s best to build them on frameworks and code that you’ve developed for stable apps (such as their existing Status Shuffle app) in order to allow for fast development. Also, you can typically reuse these apps the following year, with some minimal-cost tweaking to keep them fresh. One interesting thing that he pointed out is that for the My Year in Status app, they fixed their #1 complaint, which was the lack of ability to choose which statuses were used, and found that although it reduced complaints by 80%, it only increased conversion rates by 2%: keep in mind that your most vocal detractors may not be that important to your bottom line.

Last up was Roy Pereira of ShinyAds.com, with the only non-Facebook app of the night. ShinyAds is a self-service advertising platform for web publishers that passes through more of the ad revenue to the publisher than other ad platforms such as Google AdSense. It’s not an ad network, but a tool for the web publishers to interact directly with advertisers. Advertisers can create their own advertising banner using a wizard-like interface: add or create a banner image, set the ad budget, set the click-through destination URL, set start and end dates, and target by geography. Once the ad is approved by the publisher, it’s inserted into the publisher’s ad server, or can use the ShinyAds ad server. Payments are made automatically to the publisher based on actual metrics, with the publisher interface includes a view of metrics and analytics.

All in all, a great DemoCamp, and the venue was excellent. I had stopped attending after a few disastrous nights in too-small venues (usually pubs) with crappy AV and wifi, but this has me back as a convert.

Gurbaksh Chahal at DemoCamp 25

DemoCamp Toronto #25 was held last week, with the usual array of demos and an extra special keynote: Gurbaksh Chahal, the highly-successful serial entrepreneur currently engaged in GWallet, an online payment system. Previously, he sold his first company at the age of 18 for $40M, then built BlueLithium to a point where it was acquired by Yahoo for $300M, and there were a lot of eager people in the audience to hear how they could get replicate that sort of success. Some of them were carrying along copies of his book, The Dream, hoping for an autograph.

He had a great set of points that I tried to capture; with each of these, he included examples from his own life that made them relevant:

  • The idea is only 1%, the rest is execution.
  • Don’t get too attached to your ideas. Sometimes that idea that you start a company with is just a starter idea, it’s not the one that you want to take to completion.
  • The biggest ($) deals happen when a company is bought rather than sold; that is, the buyer seeks out the relatively scarce resource and offers based on the perceived value of that scarcity, rather than the seller putting themselves up for sale.
  • Hire only rock stars, pay them well, and let them share in the ultimate rewards. Expect long hours, hard work and brilliance from them.
  • Never leave yourself vulnerable; consider everyone replaceable.
  • Don’t expect charity or favors, especially your first time around.
  • Never raise money when you need it: get traction first and wait for the money to come to you.
  • Bring in venture capital even if you have the means to self-fund, since that brings other ideas and governance.
  • In budgeting and spending, understand the difference between need and necessity. Money is finite, spend like every dollar is your last. People will only be impressed by your performance, don’t worry about the fancy trappings.
  • Every entrepreneur needs confidence (or the appearance of it). In any meeting, focus the conversation on the purpose of that moment.
  • Relationships are everything in life and the business world. Never burn a bridge. They’re not buying a product, they’re buying you.
  • There are only 5 key decisions that you need to make in order to make or break your company – make them wisely. His example at BlueLithium: hiring dream team, acquiring AdRevolver, raising 11.5M, opening up Europe a year after the US, selling to Yahoo at the right time for 300M although board didn’t want to sell. Knowing which are the key decisions requires instinct.
  • Surround yourself with people who want to see you successful and who are hungry. You don’t want to reward people who don’t contribute: you need people who will take a risk with you, and get rewarded for it.
  • Embrace rejection. Everything happens for a reason, it makes you stronger.
  • Make decisions, even if they may be wrong.
  • Always negotiate from a position of strength. Perception is reality: show people what they want to see, and tell them what they want to hear. Believe in yourself and sell the dream: no product or sales pitch is perfect.
  • Grow a thick skin. People will question your ability to succeed.
  • Do the work. Keep your eye on the tiger. Fight like Hell, defy the odds. It’s worth it. Never compromise your morals.

The gate receipts from that night’s DemoCamp, usually put towards some food or drink for the attendees, were donated to support efforts in Haiti following the earthquake. All of us put in $2,580; Gurbaksh, who had promised to match that, ended up tossing in another $10,000.

Lean Six Sigma and Process Improvement conference, Toronto

In a nice break from the past two years as a road warrior, I’ve only been on one trip since November. Even better, some conferences are coming to Toronto so that I don’t even need to travel (although not sure that February up here is a big draw if you don’t already live here).

This month, IQPC is hosting a Lean Six Sigma and process improvement conference on February 22-24 at the Westin Harbour Castle, with a focus on achieving a sustainable and transparent Lean Six Sigma and process improvement culture:

    • Increase Organizational Synergies by Applying LSS and Process Re-engineering to Consolidation and Organizational Restructuring
    • Maximize Benefits and Savings of Process Improvement Projects by Identifying and Implementing Low Cost Solutions
    • Bring the Quality of Your Products to a New Level of Efficiency by Applying Innovative Methodologies, such as Triz, to Your Transactional Processes and Engage Your Customers in Transactional Projects
    • Maximize the Efficiency of Internal and External Benchmarking by Expanding the Use of Dashboards

My readers can get 20% off the “All Access” price by using the code LSSCCol2 when you register here.

Disclosure: IQPC is providing me with a free pass to the show.

Tagged ,

BPM 2010 Call for Papers: Research, Education and Industry

I’ve previously extolled the benefits of attending the annual international research conference on BPM, and for those of you in North America who just weren’t ready to shell out for a trip to Europe, you’re in luck: it’s coming to Stevens Institute in New Jersey in September. Although this has always been an academic research conference, rife with papers full of statistical analysis, this year the organizers are creating an industry track for practitioners to discuss the adoption and use of BPM:

The industry track will provide practitioners with the opportunity to present insight gained through BPM projects. We are particularly interested in case studies from the perspective of user organizations. While contributions from consultants and vendors are appreciated, pure product demonstrations, method tutorials, or vendor showcases will not be accepted in the industry track. All contributions to the industry track have to describe experiences with BPM methods and/or technologies from the viewpoint of the adopting organization.

This is not the usual conference PowerPoint deck: you have to actually write a paper. If you want to present in the industry track, you must submit an abstract by February 15th.

If you’re submitting a paper for the regular research tracks, the paper (not just an abstract) is due by March 14th. You can also submit a paper in the new education track, specifically about education and training methods for the BPM professional, also due by March 14th.

Even if you’re not giving a paper, I highly recommend that BPM vendors send along someone from their design/engineering team. This conference shows BPM research that (in some cases) indicates where product functionality could go in the future; best to get in there and see it first hand.

Launching #BPMcamp

Mashup Camp boardAlmost four years ago, I wrote a post about how we needed a BPM unconference. Today, Scott Francis of BP3 announced that they’re organizing one, although it’s focused on Lombardi customers and products. As I said on my comment on his post:

I believe that there is a place for a vendor-independent BPM camp, but using a single vendor’s clients to kick things off is a promising start to test the format. The biggest challenges, I believe, will be encouraging people who are accustomed to being spoon-fed at typical conferences to create and facilitate their own sessions, as well as get the corporate approval necessary for attending an unconference.

I’ve attended a lot of unconferences over the past few years, and the format can really work well if the right framework is in place and attendees are willing to participate [note that by “unconference”, I mean the self-organizing type that use something like Open Space as an organizational framework, not the fake unconferences that are actually pre-scheduled webinars].

I’m very excited to see what happens with this; the time could be right for unconferences to make an impact on the enterprise.

21st Century Government with BPM and BRM #brf

Bill Craig, a consultant with Service Alberta, discussed their journey with process and rules to create agile, business-controlled automation for land titles (and, in the future, other service areas such as motor vehicle licensing) in the province of Alberta. They take an enterprise architecture approach, and like to show alignment and traceability through the different levels of business and technology architecture. They used a number of mainframe-based legacy applications, and this project was driven initially by legacy renewal – mostly rewriting the legacy code on new platforms, but still with a lot of code – but quickly turned to the use of model-driven development for both processes and rules in order to greatly reduce the amount of code (which just creates new legacy code) and to put more control in the hands of the business.

They see 21st century government as having the following characteristics:

  • customer service focus
  • business centric
  • aligned
  • agile
  • assurance
  • management and controlled
  • architected (enterprise and solution)
  • focused on knowledge capture and retention
  • collaborative and integrative
  • managed business rules and business processes

BPM and BRM have been the two biggest technology contributors to their transformation, with BRM the leader because of the number of rules that they have dealing with land titles; they’ve also introduced SOA, BI, BAM, EA, KM and open standards.

In spite of their desire to be agile, it seems like they’re using quite a waterfall-style design; this is the government, however, so that’s probably inevitable. They ended up with Corticon for rules and Global 360 for process, fully integrated so that the rules were called from tasks in their processes (which for some reason required the purchase of an existing “Corticon Integration Task” component from Global 360 – not sure why this isn’t done with web services). He got way down in the weeds with technical details – although relevant to the project, not so much to this audience – then crammed a description of the actual business usage into two minutes.

One interesting point: he said that they tried doing automated rules extraction from their mainframe applications to load into Corticon, but the automated extraction found mostly navigation rules rather than business rules, so they gave up on it. It would be interesting to know what sort of systems that automated rule extraction works well on, since this would be a huge help with similar legacy modernization initiatives.

Smarter Systems for Uncertain Times #brf

I facilitated a breakfast session this morning discussing BPM in the cloud, which was a lot of fun, and now I’m in the keynote listening to James Taylor on the role of decision management in agile, smarter systems. Much of this is based on his book, Smart (Enough) Systems, which I reviewed shortly after its release.

Our systems need to be smarter because we live in a time of constant, rapid change – regulations change; competition changes due to globalization; business models and methods change – and businesses need to respond to this change or risk losing their competitive edge. It’s not just enough to be a smarter organization, however: you have to have smarter systems because of the volume and complexity of the events that drive businesses today, the need to respond in real time, and the complex network of delivery systems by which products and services are delivered to customers.

Smarter systems have four characteristics:

  • They’re action-oriented, making decisions and taking action on your behalf instead of just presenting information and waiting for you to decide what to do.
  • They’re flexible, allowing corrections and changes to be made by business people in a short period of time.
  • They’re forward-looking, being able to use historic events and data to predict likely events in the future, and respond to them proactively.
  • They learn, based on testing combinations of business decisions and actions in order to detect patterns and determine the optimal parameters (for example, testing pricing models to maximize revenue).

Decision management is an approach – not a technology stack – that allows you to add decisioning to your current systems in order to make them smarter. You also need to consider the management discipline around this, that will allow systems to not just become smarter, but begin to make decisions and take actions without human intervention.

James had a number of great examples of smarter systems in practice, and wrapped up with the key to smarter systems: have a management focus on decisions, find the decisions that make a difference to your business, externalize those decisions from other systems, and put the processes in place to automate those decisions and their actions.

Business Rules and Business Events: Where CEP Helps Decisions #brf

To finish off the second day of Business Rules Forum, Paul Vincent of TIBCO spoke about events and event-driven architecture as a useful way of dealing with business rules. TIBCO is best known for their messaging bus (although some of us know it more for the BPM side), and events are obviously one of the things that can be carried by the bus, or generated from other messages on the bus. The three major analysts who presented here this week – Jim Sinur of Gartner, Mike Gualtieri of Forrester, and Steve Hendrick of IDC – all stressed the importance of events and CEP; in fact, Gualtieri stated that CEP is the future of business rules in his breakfast roundtable this morning.

Going back to the basics of business rules, rules can be restrictions, guidelines, computations, inferences, timings and triggers; the last two are where events start to come into play. Rules are defined through terms and facts; some facts may be events, and rules enforced as events occur. Business rules drive process definitions and the decisions made within business processes, and mapping between rules, processes and decisions is easiest done from an event perspective. Events are key to business rule evaluation and enforcement, where events are triggers for both processes and the rules that determine the decisions within those processes: an event triggers a process, which in turn calls a decision service; or an event triggers a change to a rule, which in turn changes the decisions returned to a process. In fact, there’s a fine line between business processes and event processing if you consider how an event might impact an in-flight event-triggered process, and Paul declared that BPM is really just a constrained case of CEP.

Having taken over the world of BPM, he moved on to BRM, and showed how CEP systems are better for managing automated rules (when all you have is a CEP system, everything looks like an event, I suppose :) ) since all decisions are event-driven, and CEP systems monitor simple events and decisions to identify patterns in real time by combining rules, events and real-time data in the same system to allow organizations to react intelligently to business events. He walked through an example architecture for real-time event processing (which happens to be TIBCO’s CEP architecture): a distributed CEP framework including an event bus and data grid, plus rule maintenance and execution, and real-time analytics. This allows historic patterns to be detected in real time (which sounds like a contradiction), while providing the decision management interfaces, rule agents and real-time dashboards. Rather than having a listener application feeding a rules engine, events are fed directly to the event processing engine in an event-driven architecture. He walked through other aspects, such as rule definition and decision services, showing how EDA provides a simpler and more powerful environment than standard BRMS and SOA.

Business rules are used in sense and respond, track and trace, and situation awareness CEP applications; business users (or at least business analysts) need to be able to understand and model events independent of any particular infrastructure. I completely agree with this, since I find that business analysts focused on process are woefully unaware of how to identify and model events and how those events impact their business processes.

Comprehensive Decision Management: Leveraging Business Process, Case Management and CEP #brf

Steve Zisk of Pegasystems discussed decision management with a perspective on the combination of BPMS and BRMS (as you might expect from someone from Pega, whose product is a BPMS built on a BRMS): considering where change occurs and has to be managed, how rules and process interact, and what types of rules belong in which system.

In many cases, rules are integrated with process through loose integration: a process makes a call to a rules engine and passes over the information required to make a decision, and the rules engine sends back the decision or any resulting error conditions. This loose coupling makes for good separation of rules and process, and treats the rules engine as a black box from the point of view of the process, but doesn’t allow you to see how rules may interact. It also makes it difficult when the parameters that drive rules change: there may be a new parameter that has to be collected at the UI level, held within process instance parameters and passed through to the rules engine, not just a change to the rules. Pega believes that you have to have rules infused into the process in order to make process and rules work together, and to be completely agile.

Looking at an event-driven architecture, you can consider three classes of events: business, external and systems. We’re concerned primarily with business events here, since those are the ones that have to be displayed to a user, used to derive recommendations to display to a user, or used by users in order to make business decisions. Systems that need to involved human decisions with many complex events need to have a tighter integration between events, processes and rules.

Case management is about more than just collections of information: a case is the coordination of multiple units of work towards a concrete objective to meet a business need of an external customer, an internal customer, a partner or another agency. Cases respond to and generate events, both human events (such as phone calls) and automated events (such as followup reminders or fraud detection alerts).

Steve covered a number of case studies and use cases discussing the interaction between rules, processes and events, highlighting the need for close integration between these, as well as the need for rules versioning.

Business Rules Governance and Management #brf

Eric Charpentier, an independent rules consultant who has also been blogging from BRF, gave a presentation on business rules governance and management. He makes a distinction between governance and management, although that is primarily in the level: governance deals with the higher-level issues of establishing leadership, organizational structures, communication and processes, whereas management is tied to the operational issues of creating rules and the day-to-day operational issues. He proposes a number of ingredients for rules management and governance:

  • Leadership and stakeholders, including identifying stakeholders, classifying them by attitude, power and interest, and identifying roles, responsibilities and skills
  • Communication plans for each stakeholder type
  • Identifying types of rules, particularly around complexity and dependencies
  • Understanding the lifecycle of rules within your organization, which shows the process of creating, reviewing, testing, deploying and retiring rules, and the roles associated with each step in that process
  • Rule management processes, with details on rule discovery, authoring and other management tasks, right down to rule retirement
  • Execution monitoring and failure management
  • Change management, including security and access control over different types of changes
  • Building a rules center of excellence; interestingly, Jim Sinur recommended a joint BRM-BPM CoE in his presentation this morning, although I’m not sure that I completely agree with that since the efforts are often quite disjoint within organizations (or maybe Jim’s point is to force them closer together)

Eric obviously has a huge amount of knowledge on organizing rules projects, but he also proved his practical experience at this by discussing two case studies where he is involved as a facilitator, rule author, rule administrator and developer: one in a Canadian government project, and the other with Accovia, a travel technology provider.

The government project is a multi-year renewal project where legacy AS/400 systems are being converted to service-oriented architecture, and rules were identified as a key technology. In order to gain an early win, they extracted rules from the legacy system and put them in a BRMS, exposed them as web services and then call them from the legacy system. In the future, they’ll be able to built new systems that call those same rules, now that they’re properly externalized from the applications. They’re using a fairly simple rule lifecycle (develop, test, deploy) that combines authoring and change management because they have a small team, but have specific timelines for some rules that change on an annual basis. They have processes (or procedures) for deployment, execution monitoring, failure management, testing and validation, and simulation, although they have no rule retirement process because of the current nature of their rules. The simulation, a new process, takes the data from the previous year and runs it through new potential rules in order to understand the different impact on their costs; this then allows assessment of the new rules, and the appropriate policy set that in turn selects the rules for production.

The Accovia project is focused on their off-the-shelf software product, where they are embedding rules as a key component of the software. They have some rules that are internal to the software, and others where they allow the client to customize the rules; this means that the typical rules project roles are split between Accovia and their clients. The clients won’t be able to change the basic rules models, so the challenges are around creating the environment that allows the clients to make changes that are meaningful to them, but are also resilient to upgrades in the core product. They haven’t solved all of these problems yet, but have identified six possible rule lifecycles that need to be managed.

Some key lessons learned about rules governance and management as a wrapup: this takes time, and needs good stakeholder analysis. You may also need to do some research and consult your technical team in order to understand all of the issues that might be involved. Very comprehensive presentation.

BRMS at a Crossroads #brf

Steve Hendrick of IDC gave the morning keynote with predictions for the next five years of business rules management systems. He sees BRMS as being at a crossroads, currently being used as passive decisioning systems with limited scope, but with changes coming in visibility, open source, decision management platforms and cloud services.

He took a look at the state of the BRMS market: in 2008, license and maintenance revenue (but not services) was $285M, representing 10.5% growth; significant in its own right, but just a rounding error in the general software market that is about 1000 times that size. He plotted out the growth rate versus total revenue for the top 10 BRMS vendors; no one is in the top right, IBM (ILOG), CA and FICO are in the lower right with high revenues but low growth, Pegasystems, SAP (Yasu rebranded as NetWeaver BRM), Object Connections, Oracle, ESI and Corticon are in the top left with lower revenues but higher growth, and IDS Scheer (?) is in the bottom left.

Forecasting growth of the BRMS market is based on a number of factors: drivers include market momentum, business awareness driven mostly by business process focus, changes in worldwide IT spending, and GRC initiatives, whereas the shift to open source and cloud services have a neutral impact on the growth. He put forward their forecast scenarios for now through 2013: the expected growth will rise from 5% in 2009 to just over 10% by 2013. The downside growth scenario is closer to 6% in 2013, while the upside is 15%.

Many of the large ISVs such as IBM and SAP have just started in the BRMS space through recent acquisitions, but IBM tops his list of leading BRMS vendors because of the ILOG acquisition; FICO, Oracle and Red Hat are also on that list. He also lists the BPMS vendors with a strong legacy in BRMS, including CA (?), Pegasystems and TICBO. Open source vendors such as Red Hat are starting to gain a foothold – 5-10% of installed base – and are a significant threat to some of the large players (with equally large price tags) in the pure play BRMS space. Decision services and decision tables, which are the focus of much of the BRMS market today, can be easily commoditized, making it easier for many organizations to consider open source alternatives, although there are differences in the authoring and validation/verification functionality.

He spoke about moving towards a decision management platform, which includes looking at the relationships between rules and analytics: data can be used to inform rules definitions, as well as for decision refinement. CEP is an integral part of a decision management platform, with some overlapping functionality with a BRMS, but some complementary functions as well. He puts all of this together – data preparation, BRMS, decision refinement, CEP and state – into a core state machine, with links to an event server for receiving inbound events and a process server for initiating actions based on decisions, blending together an event, decision and process architecture. The benefits of this type of architecture:

  • Sense and respond provides granular support for all activities
  • Feedback allows immediate corrections to reduce risk
  • Decision models become complex but processes become simple
  • Model-driven with implicit impact analysts and change management
  • GRC and consistency are derivative benefits
  • Scalable and cloud-ready

This last point led to a discussion about decision management platforms as cloud services to handle scalability issues as well as reduce costs; aside from the usual fears about data security, this seems like a good fit.

His recommendations to vendors over the next five years:

  • Add analytics to complement the BRMS functionality
  • Bring BRMS, CEP, BPM, analytics and EDA together into a decision management platform
  • Watch out for the penetration of open source solutions
  • Cloud DMP services cater to the unpredictable resource requirements and scalability

Recommendations for user organizations:

  • Understand the value that analytics brings to BRMS, and ensure that you have the right people to manage this
  • Commit to leveraging real-time events and activities as part of your business processes and decisions
  • Watch the BRMS, CEP, BPM and analytics markets over the next 12 months to understand the changing landscape of products and capabilities

A good look forward, and some sound recommendations.

Business Rules Management: The Misunderstood Partner to Process #brf

The title of Jim Sinur’s breakfast session this morning is based on the “lack of respect” that rules have as a key component in business processes: as he pointed out, it’s very difficult to explain to a business executive what business rules do and their value (something to which I can personally attest). I’ve been talking about the value of externalizing rules from processes for a number of years, and Jim and I are definitely on the same page here. He has some numbers to back this up: a rules management system can expect to show an IRR of 15%, and in some industries that are very rules-intensive, it can be much higher.

Rules are everywhere: embodied in multiple systems, as well as in manual procedures and within employee’s heads; it goes without saying that there can be inconsistent versions of what should be the same rule in different places, leading to inconsistent business processes and outcomes. Extracting the rules out of the systems – and with more difficulty, from people’s heads – and managing them in a common rules system allows those rules to become more transparent (everyone can see what the rules are) and agile (a rule change can be made in one place but may impact multiple business processes and scenarios). Or as he said, rules are much easier to manage when they are managed. :)

Not all rules, however, are business rules and therefore are a fit for externalization: the best fit are those that truly have a business focus and have some degree of volatility, such as regulatory compliance rules or the rules that you use for underwriting; those with a poor fit for BRMS are system rules that might be better left in code. Once the business rules have been identified, the next challenge is to figure out which of these should actually be managed directly by the business. IT will tell you that allowing the business to change any rule without a full regression testing is dangerous; they’re wrong, of course, since your initial testing of rules should test the envelope within which the business can make rule changes. However, Jim’s suggestion is to have business and IT each state which rules that they want to manage, and just deal with those that claimed by both, by examining the impact of the changing rules within that area of overlap. Basically, if a change to a rule can’t result in any system meltdown or violation of business practices, there’s usually not a good reason not to allow the business to manage it directly.

As with the Gartner definition of BPM, BRM is defined as both a management discipline as well as the tools and technology: just as we have to get organizations to think in a process-centric manner in order to implement effective BPM systems, organizations have to think about rules management as a first-class member of their analysis and management tools. Compared to BPM, however, BRM is further back in the hype cycle: just approaching the peak of inflated expectations, whereas BPA is far out in the plateau of productivity and BPMS is dipping into the trough of disillusionment. Jim predicts that BRM will become important (especially in the context of BPM) in 5-10 years, unless some catastrophic event or legislation causes this to accelerate; this is expected to show high benefit, although not necessarily transformational as BPM is expected to be.

There’s been a lot of acquisition in the rules space, and the number of significant players has dropped from 40+ to about 15 in the past few years. There’s still quite a bit of variability in BRM offerings, however, ranging from the simple routing and branching available within BPMS, to inference engines where rules are fired based on terms and facts either through forward-chaining or backward-chaining, to event-based engines that fire based on the correlation of business and system events. Really, however, the first case is a BPMS, the second is a typical BRMS, and the third is complex event processing, but these boundaries are starting to shift. Rules technology is being seen in BPMS and CEP, but also within application development environments and packaged applications.

He did an overview of BRMS technology, starting with business rule representation: there’s a whole spectrum of rule representation, ranging from proto-natural languages through to the (as yet non-existent) natural language rules. In order to be considered a BRMS (as opposed to just a BRE), a product needs to include a rules repository, modeling and simulation, monitoring and analysis, management and administration, templates, and an integrated development environment, all centered around the rule execution engine.

Combining rules and process is really the sweet spot for both sides: allowing business rules to be externalized from processes so that they can be reused across processes (and other applications), and changed as required by the business, even for in-flight processes. Rules can be used as constraints for unstructured processes, where you don’t need to know ahead of time exactly what the process will look like, but the goals must be achieved – and validated by the rules – before the process instance is completed. The simple routing rules that exist within some BPMS just isn’t sufficient for this, and most BPM vendors are starting to realize that they either need to build their own BRMS or learn to integrate well with some of the full-featured BRMS.

He wrapped up with some key takeaways and recommendations: focus on real business rules; learn how BRM can become part of your management practices as well as technology portfolio; marry BPM and BRM, potentially within the same CoE; and see rules and processes as metadata-driven assets.

Collecting, Connecting and Correcting the BPM Dots #brf

Roger Burlton, who organized the BPM track here, gave a presentation this afternoon on process discovery techniques that fit well with Kathy Long’s previous presentation on process notations. He looked at different levels of BPM (and therefore of models): enterprise, business process, and implementation. Most of the BPM models done at the enterprise level are for the purposes of enterprise architecture and high-level strategy; those at the business process level may be for documentation and optimization whether or not the processes are ever automated; and those at the implementation level are primarily for automation purposes. Some of the collect-connect-correct techniques can be reused across these levels, allowing for easier alignment between the different levels:

  • Collect:
    • Agree on our intent – get the same motivation
    • Find out who cares
    • Discover the truth
    • Measure real performance
  • Connect:
    • Draw pictures and communicate
    • Question why
  • Correct:
    • Make it better
    • Check it out
    • Get to yes
    • Launch and learn
    • Deal with worries

He went through each of these in detail, pointing out what information that you need to gather at each point, and how this applies at each of the levels. Great presentation, tons of information, although I captured very little of it here due to end-of-day blogger burnout.

That’s it for the first day of Business Rules Forum; I’ll be here the next two days as well. Tomorrow, I can just sit in on presentations, but Thursday I’m back to work by facilitating a peer-to-peer workshop on BPM in the cloud over breakfast, and sit on a panel on emerging trends at the end of the day.

Process Notations #brf

The pool at the Bellagio was a big draw, but I’ve kept on track for this afternoon’s presentations, starting with Kathy Long on process notations. She spoke about the necessity of documenting processes, as well as the levels to which documents should be documented. Documenting the current process should only be done down to a certain level; below that, it’s more likely to be an indeterminate or changeable set of tasks that aren’t even correct.

She proposes a much simpler, higher-level process model that’s a lot like IDEF0, but she uses Input, Guides, Outputs and Enablers instead:

  • Input: something that is consumed by or transformed by an activity/process
  • Guide: something that determines why, how or when an activity/process occurs but is not consumed
  • Output: something that is produced by or results from an activity/process
  • Enabler: something (person, facility, system, tools, equipment, asset or other resource) utilized to perform the activity/process

She looked at some of the problems with other modeling formats; for example, BPMN is easy to learn and communicate and shows cross-functional processes and roles, but multiple process involvement is difficult to model, and it’s hard to follow decision threads: they end up more as system flows than actual business process models.

She touched on a lot of points for making process models accurate and relevant, such as levels of decomposition, and not modeling events and rules as activities; these are things that tend to happen in BPMN swimlane diagrams, but not in IGOE models. A lot of this, in fact, is about making the distinction between events and activities; there’s some confusion about this in the audience, too, although most often what is shown as an activity (box) on a swimlane diagram should actually just be a line between activities, e.g., instead of adding an activity called “send to Accounting”, you should just have a line from the previous activity to the new activity in the Accounting swimlane. Her BPMN is a bit rusty, perhaps, because an event would not be modeled as an activity, it would be modeled as an activity; instead, she shows a customer example where she used a stoplight icon to indicate an event, although there is an event icon available in BPMN.

Regardless of the notation, however, there are things that you need to consider:

  • Understand why you’re modeling processes: documentation, understanding, communication, process optimization.
  • Simplify the models by removing events and decisions
  • Understand the goals in order to set the focus – and determine the critical path – for the process

I’m not sure that I agree with all of what she states about modeling; much of the fault that she finds with BPMN is not about BPMN, but about bad instances of BPMN or bad tools. She has one really valid point, however: most process models created today are just wallpaper, not something that is actually useful for process documentation and optimization.

This is the third year that I’ve heard her speak at BRF, and the message hasn’t changed much from last year or the year before, including the core examples, so it could use a refresh. Also, I think that she needs to get a bit more updated on some of the technology that touches on process models: she sees the business doing process modeling, then handing it over to IT for implementation (which doesn’t really account for model-driven development), and speaks only fleetingly of “workflow” systems. I realize that many process models are never slated for automation, but more and more are, and the process modeling needs to account for that.

BPM, Collaboration and Social Networking #brf

Although social software and BPM is an underlying theme in a lot of the presentations that I give, today at the Business Rules Forum is the first time that I’ve been able to focus exclusively on that topic in a presentation for more than 3 years. Here’s the slides, and a list of the references that I used:

References:

There are many other references in this field; feel free to add your favorites in the comments section.

The Decision Dilemma #brf

The Business Rules Forum has started here in Las Vegas, and I’m here all week giving a presentation in the BPM track, facilitating a workshop and sitting on a panel. James Taylor and Eric Charpentier are also here presenting and blogging, with a focus more purely on rules and decision management; you will want to check out their blogs as well since we’ll likely all be at different sessions. I’m really impressed with what this conference has grown into: attendance is fairly low, as it has been at every conference that I’ve attended this year due to the economy, but there is a great roster of speakers and five concurrent tracks of breakout sessions including the new BPM track. As I’ve been blogging about for a while (as has James), process and rules belong together; this conference is the opportunity to learn about both as well as their overlap.

We kicked off with a welcome from Gladys Lam, followed by a keynote from Jim Sinur on making better decisions in the face of uncertainty. One thing that’s happened during the economic meltdown is that a great deal of uncertainty has been introduced into not just financial markets, but many aspects of how we do business. The result is that business processes need to be more dynamic, and need to be able to respond to emerging patterns rather than the status quo. At the Appian conference last week, Jim spoke about some of their new research on pattern-based strategies, and that’s the heart of what he’s talking about today.

One of the effects of increased connectivity on business is that it speeds the impact of change: as soon as something changes in how business works in one part of the world, it’s everywhere. This makes instability – driven by that change – the normal state rather than an exception. Although he focused on dynamic processes at the Appian conference, here he focused more the role of rules in dealing with uncertainty, which I think is a valid point since rules and decision management are much of what allow processes to dynamically shift to accommodate changing conditions; although perhaps it is more accurate to consider the role of complex event processing as well. I am, however, left with the impression that Gartner is spinning pattern-based strategy onto pretty much every technology and special interest group.

The discussion about pattern-based strategies was the same as last week (and the same, I take it, as at the recent Gartnet IT Expo where this was introduced), covering the cycle of seek, model and adapt, as well as the four disciplines of pattern seeking, performance-driven culture, optempo advantage and transparency.

There’s lots of Twitter activity about the conference, and it’s especially interesting to see reactions from other analysts such as Mike Gualtieri of Forrester.

BPM Customer Panel #appianforum

The first day of Appian Forum ended with a panel of Appian customers – Archstone, AGF, Enterprise Rent-A-Car and Mercer Outsourcing – hosted by Clay Richardson of Forrester. Clay started with a question about which BPM project to do first: instead of the old “start small, think big, act fast” mantra, many organizations are choosing to start with a bigger project where they’re experiencing a lot of pain. Not, however, the organizations represented on the panel: they all indicated that they either started with a smaller project, or started with a big one and regretted it. I think that the key is balance: select a big enough project to be meaningful and use an iterative approach so that you don’t get swamped by it.

The discussion continued on to include data integrity/cleansing and return on investment, and the audience chimed in with questions on testing BPM applications to ensure correctness (getting a working system in front of the users earlier for validation and testing helps, as do frequent releases), production support (often done by original project team, which cuts into time for new development and CoE activities, but ideally project team is second line of support and leverages shared services support for underlying server and network infrastructure) and business change management/buy-in (requires communication, participation and vision). I think that my presentation on BPM centers of excellence that immediately preceded this had an impact: a couple of the questions directly referenced what I was talking about, particularly in the last question on process asset reusability across projects (difficult unless there is a CoE that manages an asset repository or otherwise governs reusability).

My job here is done: tomorrow is a more in-depth day for customer product training, so I’m headed back to Toronto tonight.

Benenden Healthcare Society BPM case study #appianforum

Ian Grant of Benenden Healthcare Society, a UK not-for-profit, user-pay healthcare provider with almost a million members. They had a need to improve their business agility, and identified that they needed a new case management system as well as better auditability of the decisions made within processes. They reengineered their processes first, then had their three short-listed vendors build out those processes to see how quickly (and well) it could be done; Appian was the unanimous choice of the selection panel.

They created Service Management System (SMS) to document and manage all interactions with members. Typically, when a member calls in, the service rep accesses all previous case data for this member, gathers some information about what is wrong with the member in layman’s terms – so that the service rep doesn’t have to be a clinical expert – then the rules and processes built into SMS present the services available to that member, and generates the necessary paperwork and follow-on processes. When they go live (soon), they expect to reduce their service rep training time from months to three weeks, and improve their customer satisfaction rating from 95% to 99%. They’ve created some lightly-customized user interfaces that allow for fast information gathering and problem resolution.

During implementation, they completely ignored the current state, and only considered the to-be processes and functionality. Although they had a waterfall requirements process up front with formal signoff, they moved into a more iterative prototype development cycle (although one that seems to have taken a year, so not so agile).

They’ve already achieved two million GBP in savings through renegotiations with their service providers based on their expected future-state process, as well as seeing some improvements across all processes. This is fairly common, since the act of examining and reengineering a business process almost always has the effect of improving it since many of the inefficiencies will be exposed and resolved even before any technology is brought to bear on the processes.

They have involved 85% of the entire user base in some way in the creation of the new system, which has resulted in a high degree of user buy-in since they developed the requirements themselves. They’ve already identified their requirements for the next phase, and are creating the development plan now to deliver that by the end of next year.

I’m left with the impression that there is still a lot of waterfall methodology at Benenden; whether that hinders their efforts will be seen once they’ve rolled out the first version.

Lean Process Improvement Revisited #appianforum

As with Jim Sinur, my schedule is overlapping with that of Clay Richardson of Forrester several times this month. This morning, I heard some new material from Jim, but Clay had much the same presentation that I saw him give at the Forrester Business Technology Forum a couple of weeks ago so I don’t have a lot to add here, although it’s worth reviewing the original post since he had a good presentation on the implications of Lean principles on BPM.

He did have a new bloated-lean-anemic case study about the Territory Insurance Office based on Tom Higgins’ presentation at the BTF; hopefully we’ll see a paper from Clay on this soon.

Appian 6 Release #appianforum

Malcolm Ross was up next to give us an update on Appian 6, being released in GA this week. I had a briefing a few weeks back, so I’ll include my notes from that here for a more complete view.

Appian 6 application marketplaceTheir claim is that Appian 6 is the fastest way to deploy process applications through rapid design and collaboration, rapid deployment, rapid process improvement cycles; they claim that they can complete a production pilot before the big BPM vendors can install their product (I think that they could have the pilot complete before the big guys could sign a contract, but that’s another story). In a nice illustration, one of the Appian tech guys installed and configured Appian 6 on another screen while Malcolm was giving his 30-minute presentation, including deploying an application with process models, forms, rules and reports.

They have some unique technology differentiators to support their speed claims: an integrated portal for creating composite applications and zero-code model-driven design for implementation speed; in-memory architecture for execution speed; easy import and export of applications between Appian systems and the Appian Forum online community using a marketplace paradigm; and seamless migration between their SaaS and on-premise solutions for scalability or changing requirements. To support that, they have a services team and methodology with a CMM-like maturity model built in, including a center of excellence for sharing best practices.

Appian 6 composite app including the ubiquitous Google mapThere have been a number of improvements to the end user interface: intuitive URLs for navigating directly to specific applications, collaborative discussion forums, and realtime user presence. As we heard earlier, the UI has been simplified with tabs across the top to access different applications and areas; in general, there is a lot more glue to pull together the components into complete applications. The portal allows for mashups to be created not just of Appian components and applications, but of other widgets using JSR168 and WSRP, and an application can include different composite interfaces for different roles: in my previous briefing, I saw an application that included different user interfaces for a loan representative, IT staff member, and IT manager, displaying the same data in a different manner depending on the role. Controls to edit the dashboard and create ad hoc reports can be exposed to specific user roles so that they can modify their own working environment; other roles are limited to what the application designer provides to them. The key thing about a composite application built in this environment is that it is task-driven: the process is baked right into the application.

One of the things that I like about this release is the ease of packaging, deploying and exchanging applications. An entire application, including all of its components such as processes and rules, can be exported at XML; this can be managed in a source code control system, or imported into another Appian system while maintaining unique IDs for the components across all systems. This allows applications to be easily moved to and from the Appian Forum marketplace, an on-premise Appian system and a SaaS Appian instance.