Extensibility: How well do you know Intralinks’ architecture?
2 March 2017
Have you ever wondered how software is created? How gets the ideas to add what types of functionality and what happens along the path to development? I’ve always thought it was 50% original ideas from developers and 50% feedback from users. Unless you’re Steve Jobs, where it was 100% his ideas and no feedback. I like to listen to everyday users, however. Let me tell you a story.
Over the past ten or so years, a new suite of application appeared in the tech industry and become rather popular. These were known as cloud file sharing tools. I won’t name names, but some of them are loaded on your computer, while others came free with your email. A few others were made by students in college who left to found the companies around them. Wherever they came from, they made quick inroads and many large enterprises and major banks started seeing them appear in their networks, blips of activity on their firewall. Sometimes I imagine a radar operator on a naval vessel watching enemy fighters dart over their ship and surrounding water. The banks were quick to block these sites, citing concerns of data leakage. But it quickly became apparent that the use case around these sites were valid, ad-hoc intuitive and quick file sharing.
So, they called us and said, “Intralinks, we kinda need this stuff, whaddaya have?”
We shrugged our shoulders, at the time we didn’t have anything. “ummm.. we’ll get back to you.”
Our Dev teams jumped to action and in a short amount of time produced a product with the same functionality as those other applications (Intralinks VIA Pro) but with enterprise-grade security behind it, setting it apart from those other applications. We called them back shortly after, “ok dudes, now we got you covered.”
Now, I know what you are asking:
‘So, how did the Dev team react so quickly to the request?’
‘How is the security is the same?’
‘Are you sure this is just as secure as the Intralinks I already know and love?’
‘Can I order lunch through it?’
The answer to all these questions (except for the last one) lies in the extensibility of our platform. First, for the uninitiated, extensibility (according to Wikipedia) is a systems design principle where the implementation takes future growth into consideration. It is a systemic measure of the ability to extend a system and the level of effort required to implement the extension. Extensions can be through the addition of new functionality or through modification of existing functionality. The central theme is to provide for change – typically enhancements – while minimizing impact to existing system functions. Which is a fancy way of saying, you can quickly add new applications, new use cases and functionality to an existing software or platform while leaving the existing system as-is.
You see, most modern software applications are built on top of a platform. When you use an application, it does some of the work for you and then communicates back to the mothership (aka the platform) for other parts, like IRM, encryption at rest, metadata, search indexing, etc… A good platform is designed from the ground up to be extensible, so developers can quickly create new applications for their users while maintaining the existing system. This is how VIA Pro came to being. This is also how our new User Interface is being built. We actually have an internal skunkworks which makes prototype applications all the time. Some become new functionality (like the new WebForms application), while others are just fun projects that don't become super practical (eye-tracking tech in ILViewer to automatically blur the document when you are looking away. It was cool, but not super usable).
For you my loyal readers, here is why this is important to you. Imagine you have a new use case, a new application idea or need. Now let’s assume it needs hardcore, enterprise-grade security. And we’ll assume you’re on a limited budget and don’t have a ton of developers sitting in a poorly lit corner of your office eating two day old pizza (we actually have a lot of them), perhaps just a few. How about building your own applications, or modeling your own use cases on the Intralinks platform. Our extensibility was built with our clients and internal developers in mind. The same tools we use to build out stuff is available for you, too.
Would you like to know more? Check out: https://developers.intralinks.com to learn more. Of course, you’ll need to know some basic coding and not be afraid of the term API. If you are, no worries – a lot of us are, too! In that case, grab one of those pizza eating dev dudes, give us a call and let’s discuss what we can build for you.
Now go have some pizza!
Nick McCarthy was a hardened veteran of Intralinks’ advanced support and engineering groups before joining the Presales group as a Sales Engineer. In Presales he focuses on Intralinks applications for Strategic Financial transactions, with a strong interest in Enterprise-level solutioning utilizing Intralinks SaaS platform offerings. Prior to joining Intralinks, Nick worked in many other technology fields and lived in Japan for four years (though his Japanese is a bit rusty these days). He is a native of NYC and has a degree in Computer Science and Information Systems from Pace University.