SharePoint in-a-box™ Business Solutions!

Archive for the ‘Concept’ Category

I have been involved in implementing content management technology since 1993. SharePoint has rapidly democratized electronic document management, collaboration, web content management, portal and many other content technology. It is impressive to see the number of blog, website and conference that are focusing on the SharePoint technology.

But the reality is that the SharePoint technology represents only 25% of your project. The implementation of a SharePoint solution consists of the following:

1. SharePoint software; 15%

2. Information architecture; 25%

3. Solution architecture; 25%

4. Infrastructure hardware; 5%

5. Training; 5%

6. Change management and communications strategy. 25%

Point 6 is the one most often neglected. We forget too often that a SharePoint implementation is the introduction of new working way that impact directly your users.

Imagine if I knocked on your door at home, and tell you how you should organize your garage based on my methodology?

You did organize your garage your way for twenty (20) years and I would be surprised that you would agree to change it quickly, even if you think I’m right.

The success of your implementation is intimately connected to the adherence of your user to embrace the usage of your application. Over 30% of your efforts should be devoted to develop a strategy for managing change within your organization. Here are some recommendations that are simple application, but effective:

1. Target your internal customers: Make sure you involve your users early in the needs analysis and seek for cohesion.

2. Communication Plan: A communication plan allowing all impacted users by the implementation will help them to take a step by step approach to accept changes. Users will have the opportunity to share ideas in the cafeteria, coffee break and their respective office allowing them to give feedback to the implementation team. Make sure you have a place to allow feedback from users: Ideas of the week! Proposed improvements! Etc …

3. Training: Training will be an opportunity for interaction between users and potentially bring or suggest improvements to the application. The training team must be intimately related to the implementation team of the application in order to influence the improvements suggested by users.

This is not an exhaustive list, but I wanted to make you aware that the change management when you implement a SharePoint solution is the cornerstone of your success.

The idea of this article came to me with the advent of SharePoint Foundation and SharePoint 2010 which will have a far greater impact on your users compare to SharePoint 2007. The new interface of SharePoint 2010 worried many SharePoint experts, since it requires greater adaptation, especially if you still on Office 2003.

Good day in-a-box, and hope to see you at SharePoint Summit 2010 in Montreal

One of the most lacking feature in SharePoint 2007 is the ability to create relations between lists and items in lists. We have thought long and hard about how to implement this functionality in SharePoint while leaving as small a footprint as possible.

Our first implementation of this functionality was bundled in a product called Sopra and was aimed towards CRM. The product was basically a few webparts, a relationship API and some backend lists to keep the relationship information. With this approach we were able to add our relationship webpart to the editForm.aspx pages of lists and configure it to be able to add items / documents in relationship with the current item.

This approach however came with huge drawbacks for both our development team and the clients. So we decided to review our implementation and came up with the next generation of relationship management – xRM – Anything Relationship Management. Some of you might have heard that buzz word before and that’s because it’s from Microsoft (http://www.xrm.com/).

The basic idea is to not be limited in the relationships we can setup in your business. The relationship management module of our new Alexya™ platform for SharePoint leverages the concept of anything relationship management, but inside SharePoint. Think about it, in SharePoint you can create much more than items and documents in lists. You can create wikis, blogs, documents, lists of data, lists of images, lists of contacts, team sites etc… Why would you limit the relationships to only 1 or 2 of those?

Our new generation xRM is so tightly integrated into SharePoint that the implementation is literally a zero footprint integration. No more webparts to manage and absolutely no loss of out of the box functionalities in the relationship views; now, you actually get added functionalities like the checkbox. The xRM module relationship area is 100% Ajax and all the work you do while using it will never trigger a page refresh, this is a major enhancement for users. Also, the original list forms are preserved and never changed.

The way relationships are created between objects in SharePoint is now centralized in a Silverlight administration interface completely integrated into SharePoint, no external database, no separate server.

If you wish to see it in action you can go on YouTube watch one of our videos: http://www.alcero.com/sharepoint/alexya/demos.htm

As a SharePoint developer, you often have to struggle with certain platform limitations. One of those limitation is the fact that the EditControlBlock (The list item contextual drop down menu) does not support menu items display based on server sided conditions.  For example, you cannot do something like say: only display this menu when the document has a metadata value of “approved” in a specific column.

As a SharePoint product developer, this is a major problem since we have, to date, 11 products that sit on top of SharePoint some of which use this contextual menu in order to display available features to the end-user.

Let’s  take as an example render-It, a document transformation product that allows documents like doc or docx documents to be transformed in another format like pdf, html etc… Everyone will agree that this “rendering” menu item should not be displayed unless the current document meets the requirements for the transformation.  Some people on the web have taken an approach where they modify or override the core.js functions and add their own logic. This was not an option for us since we wanted a “non-intrusive” way of adding our logic to existing functions.

So instead, we used the reflective nature of the JavaScript language to “hook” up to existing core.js functions and modify their parameters in order to add our own menus at run time by making some ajax calls. This preserves the original core.js functions and prevents bugs due to possible upgrades or changes Microsoft might implement in the core.js.

This nifty little trick allows us to make an Ajax call to the server at run-time in order to validate if a specific menu item should be displayed for this specific item in this specific context. It makes the end-user experience much more enjoyable by not having 5-6 menu items that will give you an handled error message after you click on it like ‘this action is not valid for this item”  which is very unpleasant.

The result is a much more intuitive editcontrolblock menu with menu items available only when specific feature requirements are met by the current item, security, type, metadata etc….

At the Microsoft Partner conference in New Orleans, Bill Buxton Principal Researcher at Microsoft mentioned that from product conceptualization to market maturity typically takes around 20 years.  I am happy to report that it did not take us 20 years to develop Alexya and its various components.  I would like to share with you a little history on how the concept around SharePoint in-a-box and Alexya Intranet in-a-box came to life.

In 2006, we were all part of InterDoc, the largest consulting and Integration Company in Canada focused on Documentum, LiveLink, RedDot and Hummingbird.  Ozgen Eryasa and myself where exchanging on the idea of building a product that would encompass information architecture and pre-designed functionality, so that our customers would not have to always start from a blank page.

At that time, and still today, when you buy a Documentum or LiveLink solutions, you must start from scratch and build from a blank page.  This is one of the reasons that the cost delta between implementing these companies’ solutions to SharePoint is quite high.  With my 20 years of experience in Enterprise Content Management, it was not uncommon for me to see companies spending $200,000.00 for 50 users and not get much ROI out their investment. 

So our idea was develop a product that would help bring the cost down by pre-packaging a product on top of existing ECM software.  Documentum and LiveLink were not a viable platform, so we looked at an Open Source company called Alfresco.  With that we found a name: Alexya! Then we started to build an Information Architecture for compliance purposes.   It did not work due to market adherence, and Alfresco was not a development platform.

Then the light came on, when I saw SharePoint 2007 in Miami on February 2007.  I came back to the office and took few months to re-engineer InterDoc to be strictly focused on SharePoint, and started Alcero in August 2007 to focus on developing Alexya, Intranet in-a-box for SharePoint.    We now have five (5) full time developers focused on providing best practice applications for Intranet and Extranet solutions built on SharePoint.

Most of people realize that SharePoint 2007 and SharePoint 2010 provide basic capabilities to manage content in the context of an ECM.  However, Microsoft does not want to be a product company but a software company.  So, if you take SharePoint + Alexya, you will find a rich application and enhanced product functionality to facilitate your deployment of your Intranet or Extranet, and also provide you the capabilities to meet the following requirements:

• Provide the foundation to apply your compliance requirements;
• Facilitate collaboration
• Ease content publishing from multiple formats and locations to multiple formats and locations
• Manage your content life cycle
• Facilitate your technical documentation
• Share and provide a controlled access to your Extranet content to your customers and partners
• Manage your key business process
• And many other key capabilities

 Why should you go with SharePoint and Alexya: TIME, MONEY, MAINTABILITY, AND ROI

Would you buy a database and build an accounting system? An inventory management application?  A billing system?  Why not?

Well, nobody does this anymore and here are some key reasons:

1. Costly
2. Challenge to get the right people to build a product:  will require system analysts, developers, product designers and an Information Architects
3. Cost and time to maintain the product: path, upgrades, migration to a newer version (SharePoint 2010) etc…
4. Time to elaborate Documentation: installation, user guides, etc
5. And the final reason: Is your team SharePoint Certified and are they subject matter experts?  Are they well versed in  the best practices for the elaboration of a product? Is this their core business?

I strongly believe that the market place has not yet realized that SharePoint is not a product, or a business solution, it’s a SOFTWARE.   You do need to evaluate your business needs, the product market place, and then determine the value of buying a product versus developing one yourself.

Microsoft’s objective is to provide the best software platform for collaboration, enterprise content management, search, BI and business processing.  However, they will continue to invest in providing a great development platform for product developers such Alcero to take the plethora of services from SharePoint to build a product, and then let a consulting or integration company like InterDoc to build an end-to-end solution for  your organization.

We also have additional partners : http://www.alcero.com/partners/partners.htm that can support you to take  Alcero products and create a vertical solution for your company.