What makes Process Automation Complex?

This week we hit a very significant milestone in the development of our new Interaction Process Automation product where the product officially went from team builds into our standard systest builds. We are very close to releasing a beta and we are finally starting to see that light at the end of the tunnel which is GA.    The project hasn’t been without challenges so I thought I’d share what has made developing a Business Process Automation product so fun and challenging.  This is a developers viewpoint at what makes these products complex and it might arm you with some good questions to ask when comparing products.


If your server goes down for maintenance or your primary drive controller bites the dust, what happens to your data?  In many environments there is some sort of DB redundancy, persistent message queuing, or other strategy used to ensure your data is preserved  so when the system is brought back on line your data is safe and sound or at least recoverable.  In addition, we deal with live phone calls so we’re no strangers to having to keep audio going even under tough environmental conditions.  But with BPA we aren’t just talking alternate routing for audio or data integrity.  This is program execution.  A BPA process can last week’s even months and states are highly transient.   What that process was doing when it was interrupted is pretty important.  It could have been calling out to a web service, handler, or updating a database.  It could be in the middle of a complex calculation or in the middle of a nested loop.   What’s worse is that when the IT intern trips over the power cord you aren’t exactly given ample notice that you’ll be shutting down or switching to a backup server.   Persisting the state of a process such that it can be restored or taken over by a backup at any point in it’s execution was very challenging to say the least.  Moving beyond those challenges made hitting that milestone even more rewarding.


In a good BPA process your data scheme can be anything from a few strings and integers to very complex data types neither of which we have the luxury of knowing about beforehand.  Nevertheless you certainly want us to log the data for you, offer reports, allow simple search methods for finding your processes based on this "unknown" data.   You want to be able to send this data in and out of 3rd party systems via web services and, oh by the way, you might decide to change your data scheme for a particular process at some point in the future even while you still have existing processes running.    I suppose you’ll even want to be able to quickly search through millions of records to find this data too.    These requirements all play an interesting role when designing the database schema, writing the algorithms that will allow you to search for and report on your processes as well as implementing the designer which ultimately allows you to express what data matters to you most and how you intend to use it.


Some may say usability is in the eye of the beholder and I’m no stranger to the arguments and opinions over what is easy and intuitive.  Nevertheless, there is a level of usability that is undeniable.  The IPhone or IPod immediately comes to my mind.  Some of Google’s products like Maps no doubt made an impact at least on me and several of my coworkers when it was first released.   I will not even attempt to compare our products with those, but to be fair; the realm of functionality in a BPA product goes well beyond that of a simple mapping program or mobile device.  The most important thing is that whatever process you create, it has to be simple for your end users.  Second , day to day administration must not be cumbersome and finally you need not employ someone with a PhD to design the automated process.   For us we already spent a good amount of time on our end user interfaces and single point of administration was something we just grew up with here at Interactive Intelligence.  It is that final requirement that I believe was so challenging.  Processes need to be able to do almost anything:  evaluate expressions, contain program logic and integrate to other back end systems all of which are completely unknown entities to the developer of the BPA designer.   Things like pulling back the WSDL from a web service and presenting it in a simple way allowing users to bind complex data and collections to it takes a great deal of commitment and attention to detail.    Simply manipulating Date/Times can be a nightmare for IT engineers if you aren’t careful how you present information on time zones and parsing of date/time elements.   There are dozens of examples where what happens under the covers is much more messy than what needs to be presented to the end user.   Keeping our eye on the ball with respect to these things is something only a developer that programs these user interfaces will ever fully appreciate.

I’m sure every vendor finds their challenges in different areas, one thing you didn’t see me mention in this post is intelligent queuing of work based on user skills, utilization, and availability.  I said nothing about real time monitoring or recording.  That’s because as a communication company we are very good at those things and have been applying them to multiple media types for years.   The reason they were not mentioned isn’t because they are easy, but because we’ve largely already done this work which we simply leveraged in our BPA implementation. 

–Todd Zerbe