Posts tagged ‘migration’

July 2, 2009

SharePoint and Connectors


Follow me on Twitter…

If you have SharePoint, I don’t see any reason why an organization would have a connector between MOSS and Lotus Quickr/connections or eRoom/CenterStage or Oracle’s Beehive. They are all really competitors to each other. My recommendation to any client is to standardize on 1 platform from 1 vendor (where possible) for the following reasons:

1. If you don’t standardize, it’s almost like an organization having multiple email systems — it just doesn’t make sense.

2. It also doesn’t make sense from a cost perspective — as you’d be paying for multiple licenses for the same people.

3. Learning curve – multiple systems means learning how to do the same stuff in different web interfaces. It’s confusing.

4. The big challenge is information governance or information management — and that’s why you want to standardize on 1 platform from 1 vendor.

However, the reality is that many organizations have different lines of businesses, business needs, budgets, and politics — and you wind up with multiple silos of information. There is a trend to consolidate/standardize because of SharePoint. Microsoft as you know has the largest community of developers and there are so many SharePoint tools (built on top of SharePoint) that make it easier to administer or migrate data to SharePoint or manage workflows, etc….   IBM/Lotus, Oracle, and EMC all need to do more to compete with Microsoft and expand/open up their developer community to gain adoption (at least in my opinion).

So if you’re comparing SharePoint against competitors and you are thinking about opportunities for connectors/integration, first understand what the SharePoint “eco-system” includes. Microsoft has the pie-chart which I’m sure you’ve seen.

 Untitled

                          Pie chart courtesy if Microsoft

I tend to view SharePoint as follows — and my diagram below allows you to compare the competition better and see where there might be potential for integration/connectors:

clip_image004

· Communication: Oracle(beehive), Microsoft(SharePoint/exchange/live communications), IBM(notes/websphere) all have technology that address Communication — with portals, instant messaging, email, enterprise messaging and unified communications. EMC has no technology for communications.

· Collaboration: Oracle (beehive), Microsoft (SharePoint), IBM(quickr), and EMC (eroom/centerstage) all have technology that address collaboration. You can even include Alfresco, Opentext, and others smaller traditional content management players all who have collaborative features now.

· Community: all the web 2.0 stuff — social computing, blogs, wikis, communities, profiles/expertise location, social networking, etc.. Again, Oracle, Microsoft (SharePoint), IBM (connections), and EMC (centerstage) all have technology that address web 2.0. You might even include smaller players like Jive Software.

· Content: This is your traditional content management and records management. Oracle, Microsoft (Content Svr/SharePoint), IBM(filenet), EMC(documentum), OpenText, Alfresco, etc…

Vendors like Microsoft, IBM, and Oracle all have solutions that address all 4 Cs in the diagram — but they don’t address all 4 Cs very well. SharePoint doesn’t address content or records management well and SharePoint web 2.0 functionality is okay out of the box — you really need to customize it. IBM/Lotus Connections is good for social computing/web 2.0 — but Quickr is poor for team collaboration (in my opinion). EMC addresses 3 out of 4 Cs very very well with CenterStage and Documentum. As for Oracle, from what I’ve seen of beehive it looks impressive and the integration with Oracle ERP/CRM systems might drive sales for beehive — but I don’t know what Beehive costs or how Oracle will foster user adoption of beehive.

The bottom line is that no matter where the digital information lives (in an email, or blog, or team space, or instant message, etc…) — at the end of the day, it all needs to become an official corporate record. And that is where the biggest business driver lies for a connector/integration — e-discovery and records management. This challenge is the same in every client I’ve worked with in both the private and public/government sectors. EMC’s new product SourceOne focuses on email and records archiving (with or w/o Documentum for retention policies). EMC also has their own “SharePoint connector” for Documentum. In the IBM eco-system — the integration between Quickr/connections and Filenet will become tighter over time. I’m not familiar with integration between SharePoint and Filenet (but I’m sure it exists if you Google it). Opentext has made many recent announcements about their integration with SharePoint.

Beyond records management, other business drivers for connectors might be very “business process” specific. For example, in Pharma, they have Documentum used as a “validated” environment for regulatory submissions and digital signatures. Or maybe contract management where all the sales is done on SharePoint and then the contract is pushed to a more robust content management system sitting in Legal. Or perhaps you collaborate on content in SharePoint and need to “publish” to a more robust and structured web content management system outside of SharePoint. The only other place I could see a connector/integration is with portals. If a company uses IBM websphere portal and decides to use CenterStage/Documentum for community/collaboration/content management. Lastly, there’s the ability to search across any and all silos of information — which presents an opportunity for connectors. And EMC has a product for that and so does IBM.

So when you think of connectors for SharePoint — think in terms of solutions or business processes: global search, regulatory submissions, contract management, mortgage applications, portal integration, and of course records management and e-discovery.    Also, make sure you understand the one problem with any connector is that you are connecting 2 different systems with 2 different object models and potentially 2 different UIs and 2 different memberships/security structures.  

The fact is that SharePoint can effectively eliminate the need for any of this type of integration (because it has features for global search, portals, workflows, web publishing etc…).    Again, SharePoint may just not scale enough or be robust enough for large organizations who have relied on traditional search/document/content/records management systems for heavy lifting.  However, over time Microsoft will improve as they have in the past with MS Office, MS SQL Server and almost all the products they release. Microsoft may not always be the best at first, but they are so focused on gaining 80% marketshare over time.  (Of course whether MSFT can overtake ipod or rimm is questionable and remains to be seen…I’m not sure I could live w/o my ipod or blackberry).

 

Follow me on Twitter…
Advertisements
June 22, 2009

Considerations for Migrating eRoom to SharePoint


I wanted to talk about some considerations for anyone who is deciding to migrate eRoom over to SharePoint.    I’ve been working with eRoom for 10 years now and still think it’s the best and most secure team collaboration tool out there.   However, I’m excited about SharePoint these days as the strong Microsoft developer community continues to build cool stuff to really enhance SharePoint and make it sing.    Of course SharePoint is really a platform that does a whole lot more than just the “team collaboration” that eRoom focuses on.   eRoom is simply the “secure team sites” / collaboration component of the larger SharePoint ecosystem.   How you deal with team sites in SharePoint may be dependent on the larger SharePoint logical design.  And for those who are migrating to SharePoint, you have to think about 3 things:

1. Logical Design – what does an eRoom community map to in SharePoint?  an eRoom facility?  an eRoom itself?

2. Scalability – Physically, eRoom packages content into rooms within facility SQL databases, files stored separately.  SharePoint’s different and how will it handle all that eRoom content within its content databases?

3. Migration of Data – do you want just files or files with all eRoom content?

eRoom to SharePoint is not like comparing apples to apples.   As a general rule, communities in eRoom might equate to a Site Collection in SharePoint and each eRoom might equate to a subsite.   I recommend to create a unique site collection in SharePoint just to administer your secure team workspaces.   You might want to create separate site collections for internal eRooms and external ones.  The Site Collection might have a defined member list and all subsites can then filter members as needed from the larger site collection.    While the majority of eRooms will follow the mapping I just described, there will be cases where one eRoom might equate to a site collection — and that would depend on the use of that eRoom, how large is it, structure and security.   eRoom Site Reports will easily help you identify those really large team workspaces so you can determine how to deal with them in SharePoint.

For the “My eRooms” home page, I’d recommend using My Sites where each individual person can see his/her team sites.   But you’ll need MOSS for My Sites.   If you opt for WSS only, you’ll have to think about something which provides that “portal” view for an individual user listing all their secure team workspaces.   Either way, I still prefer 1 URL to goto that lists all my secure team workspaces no matter where they exist in SharePoint — and I want to see it in a My Sites and a Portal view.

The SharePoint architecture is similar to eRoom in that there is a “logical” side and a “physical” side (or virtual side these days).   The eRoom site logically is a collection of servers, members, communities, and individual eRooms.   The logical side of SharePoint (apps, site collections, sites, etc..) all need to map to the physical (servers, content databases, etc..).    Depending on the scale of your eRoom environment, this is probably the most difficult thing to do in SharePoint.   In some cases, you might have create 1 Site Collection per eRoom or per eRoom Facility – which can make it harder to administer.   What was easy to adminster within the overall eRoom environment becomes harder in SharePoint.  Fortunately there are many good tools out there to help admin SharePoint across sites and site collections.   

Once you figure out the logical and physical design and how eRoom maps to SharePoint, you need to think about migrating data.   I’d recommend you look at a leveraging a migration tool — and there are not many commercially available.   AvePoint seems like a good bet for most.   The word on the Tsunami tool is that it’s too expensive and not worth it.   You can also contact me as I know of a cheaper tool which may work just as well 😉     Save yourself the developer effort as coding this could take many many weeks if not months.    And you don’t have to migrate all of eRoom at once, you can run parallel and migrate over time.   Lastly, test, test, test, and test the migration.

May 18, 2008

Some economics to consider


eRoom’s days are numbered.  I remain a fan but I’m realistic.  Why?  Simple economics.   Sharepoint Services is free — and customers are looking to reduce costs today wherever possible.  And switching off of eRoom will save money in the short run.   The return on investment to hire some consultant or 2 to migrate off of eRoom will be recouped in a year as companies save the maintenance/support they used to pay EMC.  

Now MOSS will cost them down the road and it’s unsure if these eRoom customers actually consider the total cost of ownership and how Sharepoint might affect that over time.   The reality is that Sharepoint is untested in a large deployment — and no one really knows what type of mess it might create down the road.  You just might be migrating one mess of eroom, documentum, notes, fileshares to an even bigger consolidated mess in sharepoint —  that is if its deployment and growth are not managed properly.  

And keep in mind that it’s not easy to do migrate off a platform like eRoom…as eRoom in most organizations as mission critical an application as email.   The switching costs are high.  Even a small installation with 1 eRoom server and a few hundred rooms and a few hundred gb of data is not a trivial migration.   Imagine 7 servers or 20 servers and terabytes of data.   Sure you can write some code that dumps data out of eRoom and puts it into Sharepoint.   However, the project planning and change management planning that needs to go into this does takes many months if not longer and is a significant investment.   I think the point here is simple economics. 

I think EMC shouldn’t forget why thousands of customers use eRoom today and grew eRoom so quickly in their organization….it’s called user adoption as eRoom was easier to setup,  easy to install, easy to use (compared to the alternatives) — which made it a very economical application with a solid ROI.   And customers paid for that convenience (with licensing costs).  However, today customers no longer have to pay for the same convenience as Microsoft gives WSS away and offers a comparative collaboration and content management alternative.   And you’ve got other web 2.0 competitors jumping on the bandwagon making it a more competitive landscape now.  So you have to look at simple economics if you want to compete.  

Anyway, one word of caution for anyone thinking of migrating to Sharepoint….eRoom and Documentum have been battle tested for many years — and Sharepoint has not been tested.   And as someone who has spent years traveling the globe making this technology work over the last decade, troubleshooted headache after headache after headache — it is NOT easy to scale and manage any collaboration & content management application.   Sure, sharepoint has tight integration with office and WSS is free and there are some very positive feature of the application as a whole.   HOWEVER…I leave you with this final thought….

Collaboration & content management technology has become and will continue to become mission criticial for managing projects and streamlining and running your business processes.   Economics is really important to consider….   But so is reliability and scalability.   Think about it – can you live without email today?   Yes and no…but if email is down, it’s a headache for a CIO to hear the user complaints.   So if I’m a CIO — do you want to trust your mission critical business processes to something that has not been tested and proven????    If it goes down….if it doesn’t quite work right….or doesn’t scale right…. do you want to trust your business on it?    So seriously think about that as you think about saving costs in the short run.   Take baby steps if you are going to migrate…. think about context, make sure you are close your users, and get the right advice.  Be skeptical of the cool demos, song and dance, and marketing before you make an investment in this type of technology – no matter what platform you choose.