Cross-Product Integration: The Only Kind That Matters

0316Nintex-Art_0316Tasks don’t care if you have to use five products to accomplish them. It’s not their job to care. It’s their job to stare at you until you’re done with them. And so many of the tasks we do — the majority, easily — require us to bounce from one piece of software to another before we’re done with them. 


That’s the nature of work, and as long as we want the freedom to choose the best tools for every job, that nature isn’t going to change. We’re always going to work in environments that have multiple tools made by multiple companies, each with its own special something that it does better than someone else. And that, in a nutshell, is why creating the ideal workflow requires integrating across products. 

Tasks don’t care if you have to use five products to accomplish them. It’s not their job to care. It’s their job to stare at you until you’re done with them.

I happen to believe this has always been true. Work has always involved multiple products, and the “ideal workflow” has always transcended the boundaries between products. We just haven’t been able to come very close to this ideal … until now.  

The companies behind the multiple products we use every day, to a certain extent, have been moving toward a technical common ground, and it’s allowed us to achieve cross-product solutions that really make work flow. Let me share one ordinary example — to highlight just how essential cross-product integration really is:  

To start, I enter sales figures into Salesforce. This triggers a quote document, which gets fed to a document library like Office 365, so my peers and other interested parties can edit and alter it. When they’re done, I issue the final document, via DocuSign, to the people who need to sign off on it. When the signatures are all captured, the document is sent to be archived and, at the same time, is linked back to Salesforce so we have an upfront record of it. From there, we may use a document parsing service to actually read the data in the document, and possibly Oracle or SAP to actually carry out the actions prescribed by the data. 

This quote document example is no extraordinary sequence. This is the routine, humdrum lifecycle of a daily, unexceptional little file — and look at the cross-product bonanza it entails. Now imagine — or recall, I should say — what a mess that used to be before it was all automated. It was almost easier to physically deliver a piece of paper to every party than to try to do it all digitally. Today, it’s all buttons and clicks. When each approver is done digitally signing the document, they click “finish signing,” and boom — off it automatically goes to the next location.  

We can thank the cloud for all this business automation and digital innovation. Yes, the Internet made it possible for servers to communicate, but the rise of the cloud really got the ball rolling. By “the cloud” I mean a set of Internet services that are location-independent, dynamically scaling, and — this is the key part — behave according to an emerging set of expectations.  

If you’re a good citizen in Cloud Nation, your service is available by a name, and no one cares where it’s located. In fact, it’s probably distributed across several places. Your URL is more of a name than an address. Moreover, your service is available via HTTP/HTTPS, but you’re serving up both pages and an API based on the REST (representational state transfer) standard. You’re as comfortable being accessed by a browser as you are another software app or service. And the more you make that API useful and understandable, the more popular you become, and a safer bet to customers too. REST isn’t perfect, but it is really useful, and almost everyone who’s anyone uses it — at least out in the cloud. We’ve even been gravitating toward a common way to format data (XML, and especially JavaScript Object Notation (JSON) and OData), making things even easier. 

Pretending for a moment that APIs are sentences, it’s like we’ve all begun using the same words and grammar to express ourselves. When we didn’t have this common language, conversing across products was exceedingly difficult and expensive, and we’d spend all our money on expert translators who knew all the individual languages we needed to communicate in — one for SAP, one for Oracle, and so on. That meant, at least within the enterprise, buying and configuring an enterprise service bus (ESB) product and spending lots of time and money connecting it to our array of server products. Now, with a common language, translation is less of a chore, and we can spend more money on the actual work of integrating products and creating real value. 

And that’s actually the challenging part. What do we do next? It’s up to us now to determine which processes ought to be part of our workflow. It’s up to us — you and me — to identify where we’re being slowed down and what would help us do our jobs better. 

And that’s both wonderful and a little daunting. We tinkered for so long in a paradigm where you could only do so much across products, and we got so clever about working on a canvas that size, that we almost don’t know what to do with the bigger canvas we have now. REST APIs open up all sorts of space for us, but much of that space is still blank. 

Not completely blank, of course. Companies like IFTTT and Zapier are making interesting cross-product solutions for consumer-leaning use cases. My own employer, Nintex, is doing a lot of this kind of work targeted at business and enterprises. But there’s obviously a lot of growth on the way. 

Have you ever contacted a call center and provided your name and account number — only to do the same for the next three people you get routed to? That’s an integration problem. To be fair, that particular problem involves a lot of non-cloud tech and is hard to solve. But other problems have it much easier. There are plenty of redundancies, logjams and roundabouts that we now have the means to make simpler, smoother and swifter. 

I expect to see new solutions permeating any and all inherently collaborative industries before too long. Political campaigns, for example, which manage so many names and numbers and sources across so many channels for so many people who need access. The entertainment industry. Shipping and logistics. 

Workflow doesn’t belong to any particular industry. And now, with APIs available in abundance, it doesn’t even belong to coders and special dev teams. Some specialized knowledge certainly helps; not every single coworker of mine is prepared to roll up their sleeves and create cross-product workflows. But finding people with that under-the-hood knowledge is a lot easier and more affordable than it used to be. And some people I work with every day honestly could do it themselves. 

You’ll find automation/workflow in many software products and services, but much of it is internal (automating that product and that product alone). The most useful scenarios from now on will be cross-product. And without a doubt, these will be the most interesting and inspiring ones as well. 

The nature of work won’t change. But our ability to make it flow certainly has. What will you do with that ability?  

This article originally appeared in the March 2016 issue of Workflow.

Mike Fitzmaurice is the vice president of workflow technology for Nintex.