At the beginning of 2017 we decided to introduce a development theme to focus on IT and Business Systems automation. As I was investigating what we needed to do I very quickly realised there was a lot of conflicting terminology so our starting point was to establish clear terminology around which we could anchor our internal conversations. If you are involved in product creation don’t under-estimate just how important this step is to get right, you will be surprised what seems so obvious actually isn’t.
It turned out pretty quickly that we could not really consider automation without also considering Integration, while completely independent concepts, neither is practically deliverable without the other. So, let me start giving you a simple 101 on that terminology and the context within which we interpret it.
INTEGRATION: To connect two separate systems together in a meaningful way that allows one system to instruct the other system to perform a task or a function. For example, if you want your service desk tool to send an e-mail message there needs to be an “integration” between your service desk tool and an email system that can deliver the message.
AUTOMATION: Using an integration to initiate a task or function on another system at any given point in time. In the above integration example, a service desk tool that can send an email message might be described as – “The service desk tool will automatically send an email to the customer when the ticket is resolved.” – the ‘automatically’ being the automation of sending the email.
ORCHESTRATION: Using a workflow to co-ordinate a sequence of automations in accordance with a pre-defined, and possibly contextually dynamic sequence in order to achieve a predictable and repeatable business outcome. An example of this might be to create new user accounts on three decoupled and separate systems, but all orchestrated from one central point of control, triggered as part of a new employee business process.
I was originally thinking about writing up our journey in great detail, but that all gets rather technical so I will refrain from the for now and tell you about the main business problems we as technologists wanted to solve for our customers.
- Pretty much every other system we looked at requires some level of “coding” to achieve integration. Code is what “glues” two disparate systems together in a meaningful way, and while there are some tools that claim to allow you to do this, the truth is they all require you to code in one form or another. We offer a 100% code-free customisable environment, especially in our graphical business process tool which is designed to be used entirely by non-technical people, so adding a simple WebCall node into our BPM (which is what pretty much every other system we looked at does), while would offer a level of integration capability would require the BPM designer to be exposed to some code in order to glue XML to JSON, or transform results from strings to integers and so on. This was not acceptable so while we did create a WebCall node, we did not like it, so our solution needed to avoid raw web calls without making the integration capability too limiting.
- We wanted to allow our customers to integrate with a wide range of other systems without the need to pay for a lot of expensive consultancy. Not to save on the consultancy bill its self, although that’s a nice side effect, it was more in recognition that when you pay for expensive technical expertise you end up being enslaved to their work, not because its bad work but because they are the only one who knows how it works, so when they are not available you are left holding the unwieldy baby. We don’t think that’s a good idea.
- Aside from the programming aspects, the other very difficult thing to handle when integrating systems is “authentication”, while some are as easy as an API key, others require three-phase authentication and message signatures etc. like OAuth1a, not impossible to achieve in code obviously but as a general rule, way beyond the abilities of anyone that is not a proficient programmer and expert in the field. All too often insecure systems are built because poorly hacked implementations of authentication schemes are implemented, or even worse the tool vendor gives you basic tools (like a scripting language) and leave the customer with the problem to solve. Our view is, if it is complicated to do, then we should be looking to implement the complicated stuff under the hood and make it insanely simple for our customers to use.
- We recognise that customers have integration needs for both cloud based systems (Office365, Salesforce, Amazon, Azure, Google etc.) as well as a need to integrate with, and automate their behind-the-firewall systems and applications, so whatever we came up with had to offer a solution here too.
- We recognise that our customers need to integrate with, and automate a wide range of systems and tools, even tools that are competitive to our own solution, so our strategy needed to be open to any other system and not closed or restrictive in any way.
After six months in the works, we launched our strategy and a working set of solutions to our customers in June 2017 and I think we have delivered some really exceptional capability that meets all of the above. We offer, what in my opinion, is the best business process tool in the business. It is comprehensive, insanely powerful, but really simple to use, and in expanding that to include the Orchestration of Automations, I will go as far to say that we think we have done a better job at providing easy to use, code-free integration than pretty much every other comparable system we looked at. Why? We thought differently about the problems we were trying to solve, coming at it from the BPM users point of view. That is of course a bold claim, but one that is so for supported by the initial feedback from our customers. I would of course welcome any feedback both positive or negative, I know how everyone claims how amazing their particular tech is, so I invite you to follow this thread and judge for yourself.
Now I have a lot to cover and if you got this far you are probably quite bored by now, so I am going to bring this post to an end. But just before I do, I have listed the follow-up articles that I am going to write to continue telling this story. As I write each article I will update this document with a link so check back every few days if you are interested in reading more.
