Its 10:35 on a Tuesday morning and you’re queuing for a coffee at that cafe that’s so hot right now. The Barista knows your order and bumps you up the line. He hands you your double shot flat white with a smile and presents the credit card terminal. You tap, it beeps; and you walk out with the cup searing your hand as the plastic top pops off, again.
What has just happened is a technical miracle. I’m talking the cash transaction, not the coffee. Thirty years of I.T development and experimentation has flexed its muscles to move 4 bucks from your account into “Beans, Wraps & More’s” bank account.
When you touched your card to that worn bank terminal, energy waves agitated the RFID chip in your plastic card to make it squawk an encrypted account number to the waiting coffee covered receiver. The data packet rocketed towards the banks mainframe for an account balance but not before being intercepted by a 3rd party application tasked to inspect your cards reputation and that of your baristas bank.
Satisfied you are not moving cash for the Mafia, your transaction shoots past another company’s interface, employed by your bank. They notice you’re a coffee tragic that routinely gasses up the car most Fridays. An offer for a platinum card with gas rebates and a raised credit limit will be in your inbox shortly.
All of this happens in a fraction of a second. It happens because a lot of coin has been spent to connect mainframes, applications and interfaces to turn a credit card tap into coffee in your cup.
What does this have to do with your Tech Pubs/ILS world? A lot if you are writing tenders to go out vendors to respond too. We often see RFP/Q for organisations looking for a solution and all vendors will respond with different prices and solutions based on your requirements. If you put in one or more RFQ requirements to connect your “X” to integrate with your “Y” so it can notify “Z” which will fire a workflow, please grab a coffee and continue to read my blog.
As Product Manager, It’s my job to ensure the R4i Product Suite operates standalone and also as an enterprise system. When customers ask it they can integrate their “A” with R4i’s “B”, it’s time for the “talk”. It’s a talk the will save you money, a failed project, or both.
My customers are amazing. Authoring teams and integrated support crews that perform miracles every day to deliver the impossible. When new programs are started, a list of things that make their days harder seem to drift to the “Integration” tab of the RFQ Excel spreadsheet. They hope that the Geeks can take their issues away. Now we are back to the “talk”.
Having two software products have a chat is only possible if there is a phone line connecting the two. If there is a line, is your switchboard is 12 volt and the other is 110, it’s just static for someone. Finally, do both operators speak the same language? If not, it’s just yelling and hand waving.
Yes this is a simplistic example, so let’s take it to the real world of technical publications. Many Requests For Proposal (RFP) ask for some form of interaction between the Authoring and Illustration teams. This is usually stated as “Solution must provide integration between S1000D authoring tools and the ACB123 Illustration package. Changes to illustrations are to trigger an event in the S1000D Publishing system for author action.”
Sounds simple right, make two products from separate vendors play together to make things easier for authors that are always under a time crush.
The first thing customers should put into their RFQ is on one or more “use case”. A use case is a work scenario of what the end user expects to happen in their perfect outcome. It’s not a technical specification, it’s a vision:
“When a change request is released from engineering, the illustrator will modify the existing drawing. On saving the new graphic the ABC123 CAD package triggers an update to the workflow application. A notification is sent to the authoring team lead with the new illustration name, ready for assignment to an author”.
We now know the outcome you want, but can it be done, can the two application talk and speak the same language? The R4i Product suite includes an Application Programmable Interface, the “API”. If the CAD application also has an API, we are halfway to a coffee conversation.
Vendor API’s can be Java, .Net, PHP, REST, Python and many more. If vendor “A” uses Java, and vendor “B” uses Python, it may take some work to make them “talk”. Should they both use (for example) .NET we can now make the phone call, but can we talk?
Well that depends. At the most basic level, API’s are a collection of pre-built functions that other API’s and end user PC’s can connect to and ask questions and tell the API to do things. The information provided can switch things on or build interfaces such as forms, grids and windows.
Whew! OK, grab a sparkling water and stay with me. If the CAD package’s client can be configured to connect to the R4i CSDB Web API and say “Hello, I’m CAD01, and this image has changed, its file name is XYZ123”, the R4i API messaging API will chat back “Hello CAD01, thanks for the update, I will trigger a workflow here”.
Yes, I know when you put your RFQ together you may think all this API, java thingy stuff is the vendor’s problem to fix. Perhaps, but it could cost you a lot of money and leave you with a one off proprietary application with a short support life, the infamous “middleware” I.T money pits of the 90’s. Making two applications with differing API’s “talk” using one off custom coding sold a lot of Porches during the Dot Com bubble.
Well, our coffee chat is done. When your RFP’s together, build those use cases so we can understand your vision. Tell us the version numbers of the tools you are using that need to “talk” and provide the challenges that you want fixed.
Finally, after you have sent out your tender, go out for a freshly made coffee or tea. When the machine goes BEEP and the hot cup is (again) melting your fingers, enjoy your brew; powered by beans, brains and I.T magic!
Michael Halter
VP Product Development
OneStrand Inc.
