Architecting Social Applications

Architecting Social Applications

Posted by Arun on October 23, 2014 · 10 mins read

I still remember this conversation. It was an office pantry conversation with one of my colleagues  who was also my classmate. I was mentioning to him about an Orkut group for our alma mater. Yes, this happened a long time back, when Orkut was still alive. For those who do not know about Orkut, think of it as a previous lame duck version of Google+ – pun intended . Next day I met him again and asked him why is he not in the group yet. He replied, he had tried to join the group -  after joining Orkut, but it was too difficult and gave up. Fast forward a few years and I was connected with the same friend on Facebook. He was so active on Facebook, that I had to unsubscribe notifications from him, because my newsfeed was crowded with status updates on what he did in the morning, afternoon, evening, night and his thoughts on different current affairs, blah, blah, blah. Since I had unsubscribed from his notifications, in my Facebook newsfeed,  I did not know when he decided to relocate until one of our common friends told me about it. Well, I wrote about this incident not to substantiate how popular Facebook is while other social networking platforms – including Google+ are dying. Instead I wanted to highlight the simplicity and seamlessness that Facebook had, which made my friend to “abuse” it (by pouring status messages and making other’s newsfeed unreadable )

Well, this post not about comparing Social networks. I wrote the above incident to highlight some of the things, Facebook has done extremely well in architecting their application, which I feel can be, and should be considered while you are architecting your application or product

Oh, Social !!!

I don’t have to say this, but you might have already realized that “Social” is The new buzzword in the tech industry. “we are going social”, “we are becoming more social” these are some of the common statements in a press release associated with a new product release or release of a new version. Customers always ask for Social integration in their Line of Business Applications for obvious reasons. Social networks have become another channel, - a powerful one - for your customers to interact with your company, generate leads, market your product etc.. While Social network integration is one of the powerful influence in Application architecture, I feel that this is only one of the different new ideas, Social networks have brought in, which can influence Application Design or architecture.

Social graph

Social Graph is one of the most important components that powers Facebook. In layman’s terms, they have tried to replicate the relationships between you, your friends, movies you watch, celebrities you like, photos you posted, places you visited, milestones in your life and many other things in a system where all these are connected like nodes in a graph. This makes it easy to make interesting correlations, important findings, surprising relationships by traversing this enormous graph. In 2009 I remember reading one of Newsweek articles, in which the author had tried to highlight the power of this social graph. He mentioned that, Facebook has so much data, the power of which they themselves haven’t realized. For e.g. Facebook can predict who will win next US presidential elections, how successful apple’s next iPad release will be etc..

In other words Facebook has made it easy to capture and record your relationships with not only your friends and family members, but also with anything that you do in your life (be it reading a book, meeting a friend, buying a new phone) without you even realizing it.  I believe this is one of the interesting ideas which can be brought to traditional line of business applications or products.

Let us a dig a bit deep into it. Think of any Line of business application that you might have used or use daily. Or if you are a software developer, any application you might have designed and/or developed. More than one people use this application differently, doing different things with it, to achieve different business goals. This group of people interact with each other outside your application, for doing their work or to achieve different business goals or sometimes even a common business goal. They also interact with different entities in the business (some of them might already be represented in the line of business application). Question is, are these interactions – interactions between people and different entities in business – important to the business, so that they have to be captured, recorded and analyzed. By interaction, I don’t mean people chit-chatting about the birthday party they attended yesterday, in office, which I guess they already do this in Facebook or  their favorite Social network. Instead think of a call center agent getting help from his or her colleague, Sales executive wants to keep a close eye on a particular company or client, a teacher’s favorite student etc.. Does any of the applications currently in use in many of the enterprises capture these relationships in the context of the business.

In plain English, when you are working with a line of business application, you treat it as a data entry operation, not surprisingly application also treat you the same way, meaning it captures the data you key in, prints some reports and provides some analysis. It doesn’t care whether the student record you are looking at is of your favorite student’s or your colleague sitting next to you is helping you, when you try to solve a customer’s problem who is on the line. I believe capturing the enterprise social relationships between people and different entities in the business or outside your business can help you make interesting correlations, important findings, surprising relationships, and many more things.

Graph databases

I guess it will be safe to say that 95% applications in the enterprises use some kind of a relational database for persisting data – the other 5 % being COLBOL Mainframe applications. if you are thinking of enabling your application to capture these unconventional relationships, relational database system might not be the wisest choice. Being more specific I would consider using a graph database to capture the social relationships in your enterprise. Speaking of graph databases, consider Neo4j, the most popular and graph database. Though it is based on Java – you have to install java in your machine – Neo4J exposes a first class REST API and has got a .NET SDK as well.

While using a graph database to model your enterprise social graph gives you the ultimate flexibility and power, you should also consider offloading this representation to enterprise social networking product like yammer (if your company already has a subscription). Similar to Facebook, Yammer also exposes a graph API which can be consumed by applications.

UI Libraries

If you are a software developer, I am sure you might have come across many user interface libraries, while developing applications. Most of them internally developed on top of some third party control suite. The arguments for developing UI libraries and developing applications on top of UI libraries are relevant mostly. Consistency and Productivity. Enables developers to develop user interfaces, with consistent look and feel faster. While this consistency is one of the reasons for making every screen look similar, it also contributes to making applications look like a bunch of data entry screens. As a matter of fact, consistency is no longer the user interface design guideline, instead it is intuitiveness. Make your UI intuitive for the user, stop worrying about whether it looks similar to other screens. When you are forced to design your screens within the boundaries of UI libraries, you are certainly not thinking about the person who is going to use and what he/she wants to achieve, other than making sure that data entered is saved.


To conclude, users of your application are people with different kind of social interactions, even within the context of the business your application operates. They expect your application to be aware of this, instead of treating them as data entry operators. I feel, as an architect when you are aware of these expectations and architect applications to capture these social interactions there is a very high chance that you might have architected a true social application.