Using a Database Driven Design with IPA

The Database Driven Design is a consideration for every process you automate with IPA. That doesn't mean every process will require a Database Driven Design, but I suspect most will if they're of any size, complexity and/or duration (start to finish elapsed time for the process).

As with many of the Best Practices I'll post here, the concept of a Database Driven Design for your IPA Processes most definitely is not mine. I'm not the creator, merely the conveyor. The concept originated with a couple of guys deploying, maintaining and ever-enhancing a large, highly complex internal process that also has customer facing components at a software vendor with which I am vaguely familiar. I'll simply refer to them as the PRs, short for Punk Rockers. Anything else I call'em would probably too easily identify them and where they're employed, and they're plenty busy as it is.

Much thanks to these gents and their 3rd partner in crime for their willingness to share their lessons learned, which are the foundation of the evolving Best Practices for IPA. Without their insight, the IPA community would collectively have to stumble across applying these concepts the hard way. Thankfully, they've already applied considerable thought to some common problems they already encountered, so we won't have to. We'll find our own challenges along the way, of course...!

The PRs have been working with IPA coming on a couple of years now, and I'll go out on a limb to say they're probably the most experienced with deploying IPA. As a result, mostly over time and through trial and error, they've developed many of the Best Practices that I'll explain in detail as I'm applying them to my own IPA deployments.

So one of the first things I was told by these Jedi Masters of IPA was "Use a database driven design, you will." I nodded slowly as I wrote this down in my trusty old school black cover composition notebook. "Yeeeesss... a database driven design," I mumbled as I double-underlined the words before finally looking up and saying "um, what the heck does that mean exactly?"

"Well," one of them began, "there are several reasons to use a Database Driven Design in IPA..." and a fury of note-taking and questions ensued for the remainder of our session. The concept is as simple as it is powerful, and I'll use my Finance Purchase Order (PO) Request to illustrate.

The first point is having a custom unique identifier for your entire process instance, including as it calls other processes and external systems. The CIC system and IPA will assign a unique process identifier, which we'll call processid or pid for short. For the CIC-initiated, processid is like the callid for the process, a unique, system-generated and assigned number for an IPA process. This is very helpful but it's not really what will benefit us the most as a unique identifier for our overall process because we might call additional processes from our main process.

Here's an overview of the Database Driven Design concept:

1. Each time when a new process instance is launched, it will first go out to a custom database for that process to pull a new unique, Custom Process Identifier (or cpid for short). The cpid will be used throughout any activities associated with this process instance.
2. The process will then immediately update that record for the cpid in the custom database with initial pertinent information, such as the requesting user and initial State. 
3. As the process moves through it's various States, Task, Work Items and any associated Actions, there will be frequent updates to the database for the custom processid for the process.
4. This means, at any time, we or our process can look in the custom database and see where all of our processes are State-wise and also any data associated with it.

Clear as mud, right? Let's move to the example and dive right into the custom database.

The PO Request will have a custom database, or custom db, for storing all of the required process information associated with each individual process run, such as the management approval chain that will be passed Work Items to Approve or Reject the request until the proper approval level has been reached. The custom db will also store dynamic business rules that are created along the way, which will be covered in another post.

Concerning the PO Request, my first Work Item when someone launches the PO Request will give the Requester the opportunity to create a new PO Request, or simply click the link to the Sharepoint page we're setting up for status and reporting purposes. Notice I didn't say anything about hitting the database to assign the cpid yet? The purpose of this first Work Item is to give them a chance to see the status link if they haven't bookmarked it, so we don't burn through PO Request IDs needlessly.

If the Requester has launched the PO Request process to actually request a PO, and if they click Next instead of Cancel, that's the first time we'll hit the database to assign the cpid, which in this case would be referred to as the PO Request ID. The name of the cpid will be determined by the type of process you're creating and language of the business that will use it.

Benefits of a Database Driven Design in IPA:

• Use fewer Global Variables in IPA - leaving more system resources available to CIC. It's always good software development technique to use Global Variables sparingly, regardless of the system or application. With a custom database and a unique custom process id for each instance of your processes, basically all you need to pass around is the cpid, which also means fewer changes to functional calls since the parameters passed will tend to be fewer with adds going into the database instead.
• Re-starter Processes after Re-Publishing - so that active processes can pick up the changes. I'll cover the PRs concept of a Re-starter Process in depth in a later post, the whole goal of which is to allow you to re-publish your process and re-start all of them from scratch. Much like a handler, a process instance lives until it's complete, which is fine for phone calls that usually last no more than an hour or so, but a process instance might last up to weeks or months. Make a change to the process and you can Re-start all of your processes to pick up the changes.
• Custom, Detailed Real-Time and Historic Reporting - that is, if you make data available via any kind of pulling mechanism, such as Sharepoint page or a custom report. We'll cover custom reporting in an upcoming post. One point to consider for now is the out-of-the-box reports for IPA will contain State Labels, outcomes and other info along those lines, but not many deeper details of the processes and their custom data.

Considering Reporting, think of CIC and calls. We can use call detail and Distribution Queue Reports reports to get volume information, IVR reports (assuming we've enabled them and used meaningful labels in the Attendant Profiles...), Recorder and iFeedback. The IPA Standard reports will cover basically the equivalents to call detail and Distribution Queue Reports. Knowing more about what's happening inside of your process requires custom logging and therefore a custom database to get the equivalent data in IPA that roughly correlates to IVR Reporting, a recorded call and iFeedback for calls.

Now one important question to ask might be when wouldn't I use a Database Driven Design? I'm pressed to think of any to be honest. The process would have to be short lived and infrequently used to avoid spending a little time up front to use a custom database. There might be a customer application that does not want a detailed record of in-process data, even though they risk losing a process instance if the system is taken offline before a process completes. I'll update this post if any concrete examples arise.

The IPA Design and Implementation Certification course that I completed at ININ did not use a Database Driven Design for any of the labs, but that's largely because the concept didn't exist when the material was written. The course is going to be re-written and hopefully we can get some of these Best Practices worked into it.

Storage is cheap these days and from a system resource perspective on the CIC server, it's more cost-efficient to have a few more database calls than to store all the data for a process as global variables, especially if there's a lot of data and a lot of concurrent process instances running. I'd expect all of the above to be typical.

For any business making the effort to use IPA to automate a process, they should strongly consider the Database Driven Design! Once again many thanks to the PRs for their valuable input an insight into this IPA Best Practice.

The concept of a Database Driven Design with IPA is a breeze to illustrate or talk through pretty easily but as you can see to write it out is more involved. Comments are especially welcome if there are areas in the article that can be enhanced for clarity.

Happy Processing!

No Such Thing as a Simple Process for IPA

Lately I've been working on an internal process for a client's Finance Department. If there's one thing I've learned so far it's there are small, complex process and larger, complex process.

However, there's no such thing as a simple process. Elegant perhaps. Short, as in referring to the time frame and steps to complete the process? Sure. Just try to avoid the term "simple" if you can, because it tends to imply "easy to scope and implement," which most processes simply aren't.

As-Is Swim Lane

When I was brought into the project, a fairly straightforward To-Be process mapping had been defined. Take a look at the As-Is graphic. It's a pretty straightforward set of approvals though management and ends with the Accounts Payable group. All the detail isn't important at this point, just seeing that the process flows through several different people with some decision points is sufficient for the moment.

Seems simple, right...?At first glace it most certainly does. What we don't see in the As-Is are some of the sneaky little business rules and requirements that came up over time.

To-Be Swim Lane

By the time we got done peeling back the layers of the onion, if you will, the process is still straightforward but it is noticeably a bit more complex when we talk about the To-Be swim lane to implement in IPA:

• Business Rules - as much as possible, are described in a flexible means so they can stay "in the business," which means they're stored and pulled into Work Items in IPA so the business can modify them as needed. No need to involve IT or Operations to make changes. For example, the same Task will be called in the process multiple times, so the management approval chain can be dynamic. All those levels showed up in the first process by Swim Lane. In the To-Be they're collapsed and called in a loop until we're done.
• External Systems - it's nice to imagine your process can be handled completely within IPA but that will probably rarely be the case. It's likely you'll need to move a file from one place to another or have some data database interaction. Lucky you if it can all be done with existing or new web services, but that's probably the exception.
• Complex Logic - if process contains logic that's easy for a human, such as having some approval level amounts by role in your head or on a piece of paper, which happen to change based on department and role (with exceptions of course), it's easy to look at someone's title and department to determine where they fit into those rules. That doesn't always translate easily into a process with IPA, which I'll cover in more detail in an upcoming post.

Suffice to say some or all of the above are going to apply in some way, shape or form. Just be prepared to spend some time with your As-Is process and your To-Be documentation, which should include a To-Be process flow, Screen Mock-Ups for your Work Items and also your Detailed Requirements document, to contain your business rules, system integration(s) and To-Be mapping of the business rules to your IPA Process (the pseudo-code version of the process).

More on all of that to come. For now, just remember there ain't no such thing as a simple process, especially if you want to get it right. Interaction Process Automation can help, but getting it right assumes you do your diligence and eliminate assumption.

Ever fallen into the "oh it'll be simple" mindset? Feel free to drop a comment.

IPA is the Greatest Thing Since Sliced Bread!

Hello Process World! I'm Rick McGlinchey and this is my blog about all things related to Interaction Process Automation IPA from I3 / ININ / Interactive Intelligence, Inc.

I worked for Interactive Intelligence, Inc. for over a decade and did all kinds of stuff before taking a break, then branching out on my own. I still do some work for them, and others, as interesting projects come up. More on my story another time.

So why blog about IPA? The answer is simple: Interaction Process Automation (IPA) is the greatest thing since sliced bread. I'll go so far as to say Chuck Norris is the best thing since IPA (thank Kev)! Yes, those might be an outrageous statements. To put it into slightly more realistic perspective, it's at least the greatest thing since the product initially known as Enterprise Interaction Center (then Customer Interaction Center and EIC and now... back to CIC) and here's why:

• Save Time, Paper and Rework - The obvious one is you can save time (read: money) by automating processes.
• Consistency - For companies that need to deal with compliance, regulation, and other fun stuff like that get a product that allows you to run your process consistently.
• Dynamic Processes - let's your procedure behave more like a guideline (that's ISO:9001-ese), but still with constraints. In other words, you can branch off or change directions with decision points as needed based on user input or other data.

You can read more about the product on the IPA page of ININ's website. There's also a short, 3 video segment of a customer case study on AccuQuote that ININ put up on YouTube. Definitely worth watching.

But that's the obvious stuff.  There's more magic with IPA. In addition to the intent and benefits of the product, I'm jazzed because with IPA we finally get a GUI on top of all of the power of CIC!

Let that sink in a minute... Light bulb still not going on? Read on. First some history if you can tolerate some MindFibre(TM):

I've thought for years it would be huuuge (wink wink, nudge nudge) to have some GUI tools in Interaction Designer, but they never arrived in that manner. Since the 90's there have been API's to create applications. In the bad (I mean really bad) old days, the first and only was using a dinosaur and somewhat unreliable interface known as DDE. Sure it worked, mostly.

Then came the COM API. The Interaction Client wasn't written with it, mind you, so there were some things you could do with it the Client couldn't, and vice versa, and people built some slick applications. Slick, custom applications in C++, VB and the like, which is fine if you have that sort of developer resource available.

Finally ICELib arrived and with it the 3rd party developer API was now the same one used to build the Interaction Client. Since the early part of the last decade we've had Generic Objects available. Support at I3 has been using them for years to use the ACD for routing tickets with skills. So have some notable reference customers. 

Still, ICELib and incorporating generic objects to deliver a solution is pretty involved, relatively speaking.

With IPA, to bust out an antique term, we now get a complete 4GL. Woo hoo!!! Some folks might even consider it KML on top of CIC, but I digress. Now we have GUI. I don't necessarily have to define a business process to automate. Sure I can do that with IPA and it's super-honkin' powerful, don't get me wrong. Anything I build with IPA is a process to be sure. I can ALSO write a variety of applications big and small that require user input and use them to leverage all of the goodies and power of handlers, notifications, databases and web services.

You don't necessarily have to automate a process to get use out of IPA. Imagine a small application that requires user input and functionality of CIC such as placing a call. Now you can do this within CIC without having to build a 3rd party application, and without having to dive into C# or other programming languages. The beauty is it's maintained version to version as you upgrade CIC without having to recompile, adjust for changes in an API, etc. CIC and IPA take care of all of that for you. Brilliant!

Is anyone going to buy CIC just for IPA? Eventually, probably. I hear it's already helping win CIC deals because customers know they'll want to automate processes. The other huuuge opportunity is with existing customers. They already bought CIC. Wanna automate some processes, or build some custom apps with GUI to leverage CIC's communication capabilities? Just activate some licenses and you're off to the races (now complete with a GUI)!

In short, IPA is a kick-ass product with enormous potential. I don't know about you but I'm as geeked about IPA as when I first drank the punch with CIC back in 1997!!!

Feel free to share your thoughts, preferably about IPA if you have a minute.