Bo is a Principal Consultant for ThreeWill. He has 18 years of full lifecycle software development experience.
Handshake Software Introduction
I recently had the opportunity to get a deep dive on some the products and solutions available from Handshake Software and I thought I would share some insights from that experience. Although I have been involved with SharePoint as a developer and consultant since 2007, I’d never had the opportunity to work with Handshake, and I feel like I’ve really been missing out on a really great suite of products to customize and extend SharePoint. Admittedly, I haven’t worked in the Legal vertical much and that’s where Handshake really has a foothold. Coming at the product with exposure to clients in all sorts of other verticals, I can see lots of use cases where Handshake Software would have really helped. Below I’ll cover just a few of the features that really captured my imagination during my deep dive. I’ll concentrate on the Portals product which is just one of the products available from Handshake.
Line-Of-Business Application Integration
For me personally, this is without a doubt one of my favorite features. There is a Handshake Relationship Framework with pre-defined integrations to many common legal applications and you can configure an integration to just about anything else. I really like that there is a starting point that you can take and customize so that you are already a long way down the road on integrating your LOB systems. This can solve a big challenge many customers have where they have many off-the-shelf systems but want to be able to provide a unified experience for users in a single portal regardless of the back-end system.
In my world today, I’ve typically had two main options to integrate LOB applications each with their own pros and cons.
- Business Connectivity Service (BCS) – While this product has evolved and improved over the different releases of SharePoint, I’ve never felt like it was the easiest to use. From the days of rolling your own metadata to now using SharePoint Designer there are just several areas where you can encounter some pitfalls. Additionally, and probably most key, are the options for how you want to render your external system aren’t the most flexible. Don’t get me wrong I’ve always liked the BCS concept, but I haven’t seen it evolve as much I’d hoped from 2007 until now.
- Custom Development – This is the obvious catch-all when OOTB SharePoint just can’t fit the need. This approach gives you the ability to really create anything the budget allows and you can really tailor a solution to a customers need to get the LOB data and present it in a way that makes sense for the customers need. The downfall is that custom development can be expensive and it going to need someone to maintain and enhance the solution over time.
In a very close second to LOB application integration is the web based Content Designer tool which allows users to build out templates that render as HTML5 inside a Handshake SharePoint web part. I really don’t think I can do this tool justice with my description but the absolute power and flexibility it offers really had me enamored. The way the tool works also really seems to help guide users so that it’s easy to use.
You can use the tool to leverage your LOB application data and define how it is rendered by defining a template (aka skin) for it. The template can really be any UI paradigm that you can think of from a grid to a chart to any sort of template HTML you decide. What I can really appreciate about this is the separation of definition for the integration to an external system from the way (or ways) in which you wish to render that data. I’ll cover this more a little later, but you can obviously define how you use context in your template so that things like user security are enforced. While defining how to render LOB data is one big use case, in Content Designer, the template does not have to leverage data from external systems either; you can define an HTML template for anything you want all in the web based interface.
SharePoint Web Part
Up until this point, the products have all been outside of SharePoint, but where the rubber meets the road (so to speak) is in the SharePoint web part. Notice I’ve said “web part” and not “web parts” which is testament to how flexible Handshake really is. With such a small footprint inside of SharePoint for rendering content, it can really help alleviate migration concerns that stem from a huge footprint of server side code to worry about. But enough about migrations a topic for another day.
The Handshake web part is responsible for acting as the glue on a page. You add the web part to the page and configure it to select things like the skin you’d defined in the Content Designer and what to do with various context inputs like the user, the query string or URL path. You can even establish relationships between multiple instances of the web part on a page to determine things like rendering order. I think the best way to understand how powerful it can be is just to describe some examples I saw of it’s uses.
- Simplifying a taxonomy by having the same SharePoint site and pages rendering differently simply based on a user and/or query string. You have to let that sit for a minute I’m sure, but the implications are really amazing. Taxonomy and site structure are always a challenge to define since they can be organization based, client based, or something else. Using these web parts could allow for the ultimate in flexibility
- Replacing the out-of-the-box navigation by using a SharePoint list which allowed for a more cohesive navigation experience across sites which (as we all know) typically requires custom development if you want it to be cohesive across site collections
- Creating a dashboard experience with grids and charts in a tabbed interface to get a holistic view across LOB systems that is personalized to a user and their role in the organization.
- Enhanced Search experience with additional metadata options and faceting.
- Surfacing documents from other systems in a unified user experience along side other content in the SharePoint portal.
The three features I mentioned above are just a few features that are available in Portals and it’s just one of the suite of products available from Handshake Software. However, they all work together to help create some amazingly powerful SharePoint portals. As a SharePoint Consultant who is always looking for ways to help customers create solutions on SharePoint, I feel like Handshake is something that I can use to provide the best solutions without having to resort to developing an entirely custom solution. If you are interested in learning more, reach out to us or Handshake Software – I’m sure they would be glad to hear from you.