One solution I have found to be very helpful is to deploy a separate Sharepoint portal with the sole purpose of maintaining administrative information. I like to keep it vanilla so that I can quickly restore it independently from the main portal(s). I find that it is really easy to lock down the portal when you are only going to allow administrators to access it.

I want to also introduce another option. In fact I like to refer to it as the "other upgrade option." The way I describe this is that you install a fresh V3 portal and you recreate manually, then migrate data and content. This allows you an opportunity to first re-think the design of each part of the new portal, instead of automatically inheriting the limited configurations that you have in V2.In some cases, I think that running an upgrade can be a mistake. As you know, performing a software upgrade to V3 doesn't automatically result in a robust V3 environment that suddenly fulfills all of your needs and desires...it just puts your same old portal on new software that happens to be capable of doing more. You still have to due necessary diligence to figure out how you are going to leverage the new functionality to meet business needs. This is a manual process. There are no short cuts. And, in some cases, by upgrading content from V3 to V7 you are actually creating more work for yourself.

Implementing new portal technology is kind of like traveling from point A to point B. Point A represents the portal concept and design that you arrive at after you analyze the business requirements, draw scribbles on the whiteboard, and have some meaningful discussions about the portal you are going to build.A (idea) -----> B (reality)Point B is reality. It is the end product; an actual, tangible Sharepoint 2007 environment configured the best possible way to resemble your concept.And, the V2 portal is simply an outdated Point B.Consider too, that the business requirements that drove the V2 portal probably have become more complex. V2 users may be wanting more sophisticated functionality by now. If time and budgets allow, don't automatically assume the limitations of a V2 portal when the subject of Sharepoint V3 comes up. Implementing V3 may be a great opportunity to re-engineer the portal solution and selecting the "other" upgrade option of redefining and creating your V3 portal from your ideas instead of from your V2 portal may result in a better solution.

Friday, September 29, 2006

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.