Sharepoint revelation: it can leverage SOA, it can be a composite application

What happens when business users are demanding a single user interface? What happens when they want their data to be truly integrated and relational? What happens when all the other applications fall short?

The answer is to bring together data and functionality from other systems and create one single composite application.

Microsoft Sharepoint is a great architecture to leverage for this purpose. It offers an excellent portal and web part infrastructure. A solid authentication and security model can easily be achieved. It is easy to recover Sharepoint web applications. Sharepoint is scalable. Customizable look & feel and navigation...its there. In short, Sharepoint addresses all the aspects of web application overhead that may currently prevent you from being able to focus on and deliver those things that the business units are demanding.

Sharepoint is robust, but often times businesses require functionality that out of box web parts cannot achieve because these web parts tend to function at the "surface." In other words, unlike an off the shelf software application such as a CRM system which may store user data in a relational database, the back end data model for Sharepoint user data is relatively flat. Sure, you can create web parts to view external data from the other systems, but a lot of times business units want more than that. They want their portal to "be" the other application. This tends to be the line in the sand where many Sharepoint implementations stop. However, this boundary represents a new frontier for some. This is where you start thinking about how you can build a composite application using Sharepoint.

Building a composite application is all about breaking down functional components and being able to use them independently. For example, the act of adding a new contact record to a crm system. This is a simple, but vital action. Do you need an entire CRM application to do this? Who says you need to be in the CRM system to create contact records? Break down the programming and logic behind the act of creating a contact record, package this as a web part, and deploy it to Sharepoint. In this example you would keep your CRM system in place and extend the existing data and functionality to a Sharepoint web application by way of web parts.

On a broader scale, take a look at the various business applications in your environment and make a list of the functional components that each one is comprised of. Imagine what it would be like to have all this functionality in one single UI. The bulk of the effort to achieve this in Sharepoint is making each functional component available independently from its native software application and creating web parts for each of these components. Once you have done that you can use them througout the Sharepoint web application.

The ROI for a project such as this will be high in situations where you are buying user licenses and maintenance for your other business applications and when the users are only actually using a portion of the functionality that is being purchased. This is where a composite application project has some real value.