Sharepoint and Enterprise 2.0: The good, the bad, and the ugly

Sharepoint and Enterprise 2.0: The good, the bad, and the ugly | Enterprise Web 2.0 | ZDNet.com

Depending on which numbers you look at these days, about a third of all companies right now are using Enterprise 2.0-style tools to enable collaboration and management of their knowledge. This is in stark contrast to just three years ago when the only tools most workers could count on for communicating with others and sharing knowledge was e-mail, the phone, and if they were lucky, an instant messaging or content management application.

It increasingly appears there is no such thing as Enterprise 2.0-in-a-boxToday’s worker landscape is a surprisingly different place with the rising use of Web 2.0 applications such as blogs and wikis and other applications. Use of public social networks like LinkedIn and Facebook are practically commonplace these days, even if not quite ubiquitous (a good percentage of companies still block access to these in fact).

And the Enterprise 2.0 landscape continues to change: The increasingly popular Twitter service has become almost trendy to use in some business circles, though it currently predominates in PR and marketing for the moment. This has given rise to a new generation of enterprise-class social messaging applications such as Yammer and Signals are used behind the firewall these days, though these are not reaching even double-digit percentages of adoption yet. Mobile devices especially have become rich multi-channel collaboration consoles for communicating in just about any way you prefer including voice, e-mail, SMS, chat, Web, social messaging, and pretty much anything else for which you can find an installable application. There seem to be countless choices when it comes to communication and collaborating in today’s workplace.

But when it comes to Enterprise 2.0 in particular — and you can read my most detailed explanation of exactly what the concepts of Enterprise 2.0 are here — the software solution that most organizations seem to reach for today in an almost knee-jerk reaction is Microsoft Sharepoint. In fact, last summer Forrester predicted that Sharepoint would “steamroll” the Enterprise 2.0 market despite “taking heat from some observers about SharePoint’s wiki, blog and social networking functionality.“

These concerns about SharePoint’s ability to be an effective Enterprise 2.0 platform is one I hear echoed a lot with practitioners I talk to. In spite of this, I correspondingly hear that SharePoint is in fact what most organizations are planning on using when it comes to 2.0-style collaboration and knowledge management. Why the apparent disconnect between the perceived suitability (which we’ll dissect in a moment) and actual use? Part of it is SharePoint’s stunning penetration in the software business. The recent adoption statistics for SharePoint should be sobering for anyone planning to provide competing tools:

• 55% of organizations have implemented or are considering implementing SharePoint (Global Intranet Trends 2009 report – 227 participant organizations)
• 46% of those companies using social media on the intranet are using
  SharePoint(Intranet 2.0 Global Survey – 430+ participant organizations)
• Only 47% of organizations have a defined governance model (Intranet 2.0 Global Survey)
• 70% use at the department level; only 38% use it at the enterprise level (AIIM)

In other words, SharePoint is already in most organizations today: Leading Enterprise Web 2.0 firm Jive Software’s CEO Dave Hirsch has gone on record in the past saying that “around 80 percent of our customers have SharePoint”. In the most recent authoritative number I could find, an estimated 85 million end-user licenses of SharePoint were in customers’ hands over a year ago and that number is likely a good bit higher today. This paints a fairly clear picture of a workflow and document management market leader that is highly entrenched, already paid for in many cases, and most likely to make the top of the short list of any Enterprise 2.0 initiative.

Microsoft SharePoint — often referred to these days as MOSS, for Microsoft Office SharePoint Server — is certainly one of the most respected and widely used platforms of its kind. It has a truly extensive set of capabilities which Microsoft typically categorizes into five major groups: Portal, search, content management, workflow, and business intelligence. Like most popular CMS and community platforms these days, SharePoint also has open architecture that ensures that almost anything that is perceived as missing can be supplemented by acquiring one of the many 3rd party addons or by custom development of what is needed. However, all products, especially very complex ones, have their own strengths and weaknesses and this is where the good and not-so-good begin to become an issue.

When Harvard’s Andrew McAfee first identified what was seemingly unique about Enterprise 2.0 compared to traditional collaboration and knowledge management tools he coined a mnemonic known as SLATES. This mnemonic forms a checklist of properties that seemed integral to successful Enterprise 2.0 implementations (based on successful early case studies). I originally covered the properties of SLATES back in 2006 when Enterprise 2.0 first arrived on the scene when I said it had the potential to “free your intranet” and it remains an excellent description of the key elements for successful social software. This was back in the time when I could ask technical audiences as collaborative conferences if they had access to blogs and wikis at work and virtually no one would raise their hand. Now they all do.

Specifically, for this discussion it’s blogs and wikis that remain the focus of Enterprise 2.0, despite there being more advanced types of applications that also qualify. Mostly this is because they are by far the most popular social tools in the enterprise, though social networking is also becoming increasingly important. It’s from this perspective that we’ll look at how SharePoint measures up to the ideal and practice of Enterprise 2.0, which can drive a variety of benefits such as higher worker productivity, improved knowledge retention, cross-functional innovation, and even as a corporate catalyst. That is, if the software you are using actually enables such scenarios in a widespread manner.

I should also be clear that SharePoint can be used to do a lot more than what we usually ascribe to Enterprise 2.0, the latter for which the elevator pitch is freeform, emergent, social collaboration and less the physical document share methodologies (such sharing Word, Excel, PDF, etc. files) it was originally designed for.

For the purposes of the discussion below, I’ll examine where SharePoint is suitable for this particular (though very significant) use case. And if you’re wondering how significant this topic this is, the Enterprise 2.0 story is primarily aimed at knowledge workers engaged in complex, collaborative projects which have had few effective software tools until recently, in other words strategic business activities. Industries like finance, government, civil engineering, transportation, and many others are trend to be top heavy with this kind of worker and are likely the last major bastions of productivity gains in modern economies, if the right solutions can be brought to bear. In other words, Enterprise 2.0 can help some of our most important and most valuable workers do better work while providing more value to the organization as a whole.

As a result of all this, and due the fact that the single most frequently asked question I get about Enterprise 2.0 is if SharePoint is a suitable platform for it (short answer: it definitely depends), I’ve spent the last few weeks taking a hard look at SharePoint the product itself, talked extensively with SharePoint and Enterprise 2.0 practitioners both, and created the resulting analysis. I’m hoping it helps you make useful decisions in your Enterprise 2.0 projects and initiatives.

The issues and challenges of using SharePoint for Enterprise 2.0

1. SharePoint is not a Web 2.0 native. This can be a compliment or an indictment depending on who you talk to. However, it’s very difficult these days to deny that innovation in social and collaborative systems is almost exclusively coming from the consumer Web. The Web has been far and away the most successful in creating powerful network effects and as the source of the world’s largest and most vibrant social systems. SharePoint was designed before we had learned many of the modern social computing lessons and though has powerful capabilities, the platform overall is excessively complex and has relatively weak support for the most common Enterprise 2.0 application types, particularly blogs and wikis, but also social networking features. SharePoint, at least out of the box, fails the SLATES test. It’s particularly weak around critical capabilities such as encouraging emergence, being freeform enough, and support tagging well (the latter which has proven to be surprisingly important for certain outcomes). For example, one of the more common offerings I saw at CeBIT in Hannover earlier this month was companies selling you the add-ons needed to shore up SharePoint’s collaboration features to have parity with newer, more modern tools. To be fair, the SharePoint community has also been proactive on this topic, and the relatively new SharePoint Community Kit goes a good bit of the way towards resolving many of these issues. A quick tour of its features also highlights just how much is missing from today’s standard SharePoint configuration.
2. The technology landscape of the enterprise environment fits SharePoint well; the business requirements to a lesser extent. While Web 2.0 tools are often unique viral and tend to have much better than average ease-of-use due to the competitive nature of the public network, they don’t transition well automatically into the Enterprise environment where multi-level security, governance, and policy controls are virtually mandatory and which few of the open source (or even commercial) Enterprise 2.0 tools from consumer world support adequately. SharePoint is strong many of these points with excellent Active Directory integration and better support for enterprise technologies. Sharepoint also integrates well with file servers, documents of many types, and traditional corporate databases, though this also reflects an older version of the technology landscape. While today’s enterprise does often not look very much like the Web, at this stage in the game, that’s not necessarily a good thing. Governance and policy capabilities in SharePoint are acceptable, but not best of breed and SharePoint has credible unified search capabilities (which is the “S” in SLATES) and works especially well if SharePoint is the only document management, portal, and knowledge management infrastructure in the organization.
3. The wilds of the open network can be a challenge for Sharepoint. Practitioners I spoke with consistently reported that SharePoint works best with homogeneous environments and not nearly as well when the environment isn’t controlled, especially on the browser-side (see this chart for details) and on mobile devices. This makes opening up SharePoint environments to work with partners, customers, and even the general public, one of the more requested Enterprise 2.0 scenarios in my experience, to be more difficult than with other platforms which were designed to function in highly diverse environments.
4. Self-service capabilities are lacking or not emphasized. One of the important aspects of Enterprise 2.0 is its freeformedness which helps lead to emergent structure and processes. In other words, a blog or wiki can be used for just about any activity by virtue of the ability of the users to aggregate thousands of tiny decisions that affect behavior and content around the work contained within the tools. Traditional enterprise systems, including SharePoint, tend to be more rigid in their ability to be shaped by users and too often force users into pre-determined uses rather than letting the users shape the use of the tools to best fit the work. Many large SharePoint installations consist of hundreds or even thousands of smaller sites, each of which must be made consistent in terms of layout and navigation if centralized administration and governance is to be effective. David Hobbs recently pointed out how rare this is but the 2.0 world has discovered that the more this is handed over to users, the better this works and critically, the better it scales up. The lesson: The more cookie-cutter SharePoint installations are, the easier they are to manage but the more they unnaturally constrain their use and prevent desirable outcomes. Users should be able to create sites within SharePoint, customize them over time to meet the local requirements, and let them evolve and improve through shared contributions. It is, however, by no means impossible to enable this kind of self-service with SharePoint but it does not encourage it nor is it a core design principle for the product.
5. Cost and complexity. One of the consistent messages I heard when speaking to SharePoint practitioners is the product’s complexity and high cost. The diagram at the beginning of this post begins to give a sense of the extent and the depth to the features of the MOSS platform. Invariably, this means highly trained implementors, administrators, and technical support staff are required to deploy and run it, which all add to the total cost of ownership. And SharePoint’s inherent sophistication can also mean slow adoption and low engagement by users. In fact, this is a central lesson in Web 2.0 design, that complexity is the enemy of ease-of-use and adoption; most 2.0 products are almost brutally simple in their user experience. SharePoint is also priced as an enterprise product and can be very expensive (at least compared to most Enterprise 2.0 products) for a large installation. However, many licenses are bundled with corporate purchases and as a result many organizations already have client licenses they are underutilizing.

I should be clear that I am not overtly negative on using SharePoint for Enterprise 2.0 and certainly there are those that are doing it. However, emphasizing the tool first, no matter how ready-at-hand, to create an enterprise-class information management solution is rarely the proper way to go — other than for solely financially expedient reasons — and rarely is that the only criteria. It also increasingly appears there is no such thing as Enterprise 2.0-in-a-box and that organizations need to find tools that best fit their culture and needs to get the best results.

In general, I’m also finding that IT departments, which are usually rather comfortable running a great deal of network infrastructure with Microsoft tools and platforms tend to favor SharePoint while business users tend to like it less and prefer newer more modern tools. This combined with either already active SharePoint installations or unused licenses means that SharePoint is usually a heavy favorite on the IT side, regardless of whether it will be able to provide the desired Enterprise 2.0 outcomes to the business. And we shouldn’t forget that SharePoint isn’t standing still as a product either and Microsoft is certainly working on newer versions that will address some of the issues covered here.

These state of affairs, particularly prevalent in medium to large organizations, is increasingly a significant topic of debate as Enterprise 2.0 adoption has achieved a mainstream tipping point within many organizations this year. I’ve perceived lately that more and more businesses are facing this topic with today’s uncertain economic times as the backdrop, making the financial component of the decision much stronger than it would be otherwise. Buyer beware, however, since these choices will set the stage for how effective your workers will be in the coming years. Years that will likely see many organizations needing to marshaling the very best capabilities of their workers to successfully transform to new market conditions and thrive.

Determining the ROI of Enterprise 2.0

http://blogs.zdnet.com/Hinchcliffe/?p=334

Determining the ROI of Enterprise 2.0 | Enterprise Web 2.0 | ZDNet.com

Despite recent statistics showing that Enterprise 2.0 tools have spread to about a third of businesses globally, there remain ongoing questions being asked in the enterprise software community about the real returns that they provide to businesses that deploy them.Many IT solutions create value only after traveling through an indirect chain of cause and effect. Certainly blogs, wikis, and social networks are popular on public networks, but does that translate to meaningful bottom line value to organizations? In other words, is Enterprise 2.0 truly strategic in the unique way that information technology can so often be?

This is a key question since actual penetration of these tools is almost certainly lower than the one third figure I mention above. Most organizations today, even the ones where the applications are available to employees currently, are not yet exhorting workers to adopt these tools en masse despite a suite of compelling arguments and a growing set of case studies. Even impressive citations such as the recent TransUnion Enterprise 2.0 case study that claims an eye-opening 50x return on investment (using the most basic ROI formula for calculating returns) are not yet initiating widespread inquiry.

Instead, while we’re seeing widespread interest and acceptance of Enterprise 2.0 in the workplace, there is still mostly a wait-and-see attitude amongst IT managers and business leaders at the moment. The reasons for this seem to fall into three general categories:

One is an broad wariness of a new horizontal information technology approach that purports to solve so many problems and will overlap extensively with existing solutions from e-mail and instant messaging to content/document management and knowledge management systems, to name just a few. Other related concerns are feelings that workers already have a lot of software to use today, that the tools already exist in the organization (see my Enterprise 2.0 and SharePoint discussion a few weeks ago), or that the available tools aren’t fully enterprise-ready yet.

A second set of issues is related to corporate culture and its fundamentally hierarchical nature, which seems anathema to the flattened, highly social nature of Web 2.0 in the enterprise. At this point, it’s becoming increasingly clear that in some tightly controlled, top-down organizations, culture is indeed an impediment to the use of emergent, social computing. Fortunately, there is now enough evidence visible in current case studies that many industries can indeed benefit from Enterprise 2.0.

The last issue is one that has bedeviled software and its strategic application to business since the very beginning, namely the accurate predicting of the return on investment of an IT solution. Andrew McAfee, who originally coined Enterprise 2.0, summarized the challenges succinctly a while back in The Case Against the Business Case. The central problem? Assets that are intangible, such as knowledge, social capital, and situated technology — which Enterprise 2.0 is primarily focused on — rarely have direct impact to financial outcomes such as revenues and profits. Its their downstream effects that generate the most value to the business.

There have been a number of good discussions on this topic lately including a detailed exploration of the issue by Hutch Carpenter, where he concludes that “software ROI is only as predictable as the activity for which it is used” and Martin Koser’s discussion on the challenges of coming up with the concepts and measures for “collaborative performance”. Susan Scrupski has also been exploring the ROI of Enterprise 2.0 and in her call for case studies recently highlighted that while we have a good number of them, there is still not enough ROI coverage in a wide set of industries.

However, a key aspect of the ROI issue is that the strategic capabilities represented by Enterprise 2.0 are primarily emergent in nature, instead of carefully aimed at and unleashed at specific problems. Classical technology investments such as assembly lines and industrial automation could be quantified because their most significant effect was direct and measurable. Many IT solutions (think e-mail or service-oriented architecture) are general purpose and tend to be indirect and create value only after traveling through an indirect chain of cause and effect to enable a positive business outcome. The problem with this is that it’s very hard to either measure or predict accurately, especially since IT solutions tend to have longer chains of cause and effect than other technologies. While this often builds up accumulated value by its ability to cascade across a business, it’s very unsatisfying from the traditional perspective of investment in X by spending Y to achieve a predicted return Z.

The net result of this lack of clarity is a hold up on the explicit use of Enterprise 2.0 for strategic benefit by businesses, even as the tools are proliferating, often virally, in many organizations. For now, the tools are often used in a localized or ad hoc fashion, or at very least, without a concerted business-wide effort to systematically capture the perceived business value. This question is important since an accumulating body of knowledge is pointing to potentially dramatic business returns with Enterprise 2.0. If these continue to be borne out, it will affect the competitive and financial positions of the companies that are proactive and therefore their long-term marketplace success. As I outlined recently in my Economics 2.0 session at Web 2.0 Expo last week, Enterprise 2.0 and other new modes of business seem to herald new, much more efficient — and just as significantly, fundamentally different — ways of running our businesses.

What will change the current status quo? A preponderance of case studies in the affirmative? Sustained, first-hand experience of the early benefits convincing senior management? Lack of reports of negative outcomes like data theft and excessive socializing? Yes, it will be all of these, but like the well-known examples of successful emergent systems such as termite colonies, bird flocks, animal herds, business organizations, and now online communities, there are real limits on the ability to direct emergent systems towards focused outcomes. In the end, all one can actually do predictably is enable the possibilities and not prevent them.

Innovation often comes from where you least expect it and harnessing collective intelligence, the core principle of Web 2.0 as well as Enterprise 2.0, is the very art of eliciting value from emergent systems such as the Web and our intranets. That this value is forming the bulk of the networked economy (open source software, social networks, social media sharing, etc.) is one of the signature lessons of the era of open business models and 2.0.

Update: Based on some feedback to this post over the last day, I would like to make it clear that there is little doubt that Enterprise 2.0 delivers ROI today, at least on the collaborative side (the jury still seems to be out on the social networking side). Recently, researchers have even been able to put a real numerical value on social connections. My point is just that it’s difficult to determine where the returns (often the most important ones) will appear when the tools have so many downstream effects. That’s not to say either that Enterprise 2.0 ecosystems can’t be directed to some degree to achieve business objectives. In fact, I believe the the next generation of workers will be experts at achieving their goals by eliciting and then harvesting the knowledge and capabilities they need over the network.

Structure 09: Akamai’s CEO Explains Why the Middle of the Net Is Such a Drag

No doubt something to think about if you are considering SharePoint in the cloud….

 

Structure 09: Akamai’s CEO Explains Why the Middle of the Net Is Such a Drag

6 Key Ingredients for What Is Cloud Computing:

1. Computing accessed via the Internet — not proprietary networks that enterprises have used before.
2. Outsourced and shared infrastructure — without shared you won’t get efficiencies.
3. Scalable resources that you get on-demand.
4. Metered use — only pay for the piece you use.
5. Need a new level of reporting and insight, plus a new level of security.
6. 10 years of history led us here.

Why the Cloud Is Inevitable:

1. Acceptance of web-enabled technologies, from the consumer side inside the enterprise, IM, social networking, etc.
2. Economics of shared infrastructure is better.
3. It’s a faster way to get applications to market.
4. Security has gotten good enough for public Internet and sharing infrastructure.
5. This model is much more efficient and greener. The IT industry is the fastest growing culprit of the carbon footprint problem.

Cloud Computing Enablers:

– virtualization
– infrastructure as a service
– application platform as a service
– software as a service
– we think the piece that is missing here is optimization layer — that’s Akamai

Top CIO Concerns With Cloud Computing:

1. Security
2. Performance
3. Availability
4. Integration
5. Customization

del.icio.us Tags: cloud

Managing Identity in the Cloud

Great podcast on thinking about application security and governance in the cloud…  with a focus on security and monitoring of the layers of the service and application.

Managing Identity in the Cloud ….chief architect for Layer 7 Technologies, Scott Morrison, outlines the challenges that IT organizations will face trying to manage identities across federated clouds of computing.

 

Technorati Tags: governance,cloud

Three Keys to Developing a Collaboration Strategy around SharePoint

If you are thinking about your overall collaboration strategy and how to best leverage SharePoint, there are 3 things you need to understand before you develop your approach: 

1. What a collaboration strategy is.    Collaboration can be both synchronous (real-time) and asynchronous (“offline”).   Synchronous collaboration is your web meetings/conferencing and instant messaging.  With SharePoint you are mostly talking about asynchronous collaboration in which users manipulate time and space to their own advantage with some degree of independence.  Users can work when and where they want without being constrained by the schedules, time zones, or locations of others.

2.  The degree of openness the collaboration strategy will address.  Is it focused on project teams with a limited number of users?   Is focused more on a business process?    Is it more open and community focused?   or is it focused on the individual and collaboration within their social network?     Identifying the degree of openness will help define the scope of your strategy.   I’d also include whether or not the collaboration is globally or regionally or line of business focused.   This will help provide a focus for SharePoint as the technology incorporates several components from social computing to team sites to portals to workflows, etc…

3. Goals and Objectives – what are the business drivers and what do you hope to achieve?   organize and capture knowledge?   attract top talent?  provide a platform for project management?   external collaboration with business partners or clients?  is it more document management focused?   compliance?    executive dashboards?  collaborative business process management such as contract management or regulatory submissions?  

You can then outline your approach for developing your collaboration strategy around SharePoint.  Your approach might include identifying the current state, assembling an advisory panel of stakeholders and their requirements, evaluating SharePoint to determine the fit and gaps, design the high level future state and overall roadmap for implementing the solution.

Identifying the Current State – Take an inventory of the current state of collaboration technology within your organization.  Where does the information live?  What are users collaborating on?  Types of documents and with whom (internal or external people)?  How are people collaborating today?  Fileshares or email?  Externally hosted platforms?   Document management system?   Some combination of technology?    Paint the picture of the current state of collaboration and the technologies involved.   I’d also include costs of those technologies if you can identify them.   It’s likely you’re spending a total of 6 or 7 figures on several technologies depending on the size of your organization.  

Deliverable:  Current State Summary

Stakeholders – Assemble a panel of stakeholders (global in nature if possible) and interview or survey them.   Ask them how they collaborate, what tools they use, what their priorities are, and frustrations/challenges they face.  I’d also inquire about their definition of success if they were to leverage a tool like SharePoint successfully.   Does the stakeholder hope to just stop emailing versions of documents and be more organized?   Or do they foresee cost savings from process improvements with forms/workflows (more of a six sigma approach).  Draft a generic requirements list for SharePoint (including features like calendaring, workflows, secure team space, etc..) and get feedback on it.

Deliverable:  Stakeholder Requirements Summary and a High Level Requirements Table.

Evaluate SharePoint – Once you understand the current state and have spent time on stakeholder requirements, it’s time to look at SharePoint.  What components of SharePoint do you need?   Will SharePoint address requirements out of the box?   Where is room for customization or branding or workflow/forms development?   Does business intelligence fit into the picture pulling data from ERP or CRM or datawarehouse systems?   Look at the features & functionality of SharePoint and develop.   If you don’t know SharePoint well, you’ll need some outside assistance from a technology consultant or your Microsoft Sales Engineer.

Deliverable:  Fit/Gap Analysis.

Future State and Roadmap – Design the future state both at a high level functional/conceptual perspective and technical architecture level around SharePoint.   Try to focus on the ideal state as the vision.   This would include all the components you might need (base architecture like web and database servers as well as BDC, excel services, or forms).   You might already have a SharePoint implementation in place.  However, the current state will tell you if you have all the right components to meet your stakeholder requirements.  The roadmap will provide the game plan to get you from the current state to future state.  Break it up into phases and try to keep it simple if you are first deploying SharePoint.  The first phase should build the baseline infrastructure for future phases.   You can’t build a house without the foundation first.   Subsequent phases can include expanding the deployment.  I’d also focus on 1 particular

Deliverable:  Overall Collaboration Strategy Document including sections for the executive summary, the current state summary, stakeholder summary, requirements, fit/gap analysis, your future state/roadmap, and of course costs and risks.

Depending on the size of your organization developing a collaboration strategy around SharePoint might take anywhere from 10-12 weeks — if you do it right.  Investing in this type of planning will help maximize the ROI of SharePoint and set the foundation for a successful deployment.  In my next series of blog entries, I’ll tackle the topic of SharePoint Governance.   The is a lot more technical information on SharePoint on the web, but not enough on governance — at least not enough comprehensive information.

Follow me on Twitter…

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.

The TCO and ROI of SharePoint

When choosing a team space collaboration technology solution, one should consider both the total cost of ownership (TCO) and the expected return on investment (ROI).   The diagram below shows that a measurable ROI will increase the more structured the context.   In other words, the more structured the context, the easier the ability to measure something which in turn can lead to productivity gains and a higher return on investment. 

 

 

Products like MS SharePoint or Lotus Quickr provide a cost effective solution for basic ad-hoc file sharing and project collaboration.  However, additional licensing, applications, and/or custom development may be required the more structured the context thus increasing the TCO and ongoing maintenance of these applications.   Furthermore, ROI may be difficult to calculate as hard numbers are not always easily identified.  The calculation of ROI might need to be focused to a particular business unit use case(s), business process, and might also consider the following:

• Adoption of Tools: Ensuring users adopt and properly leverage the technology.
• Perceived Benefits: Ensure the link between technology and (perceived) business value is clear.
• Timeframe: Establish a timeframe within a realized return on investment could be achieved.
• Metrics: Attempt to establish both hard and soft metrics in an attempt to measure ROI.