Issue link: https://epubs.iltanet.org/i/37773
To Build or Not To Build? The clichéd choice of buy versus build takes on fresh relevance in the context of SharePoint portals. SharePoint is a development platform, not a plug-and-play solution. To create your new portal, some “building” and some “buying” are both going to have to occur; the real question to answer is how much of each. You’re going to need connectors to reach the data you want to surface, Web parts to make it accessible, and a framework for creating meaningful relationships among your data, and you’re going to need them all customized and implemented to your specific requirements. You could take an application-centric approach and secure from each of your existing application providers connectors and/or Web parts to serve up the data to SharePoint. This seems logical, as those providers would be well suited to speak to their own data structures. On the other hand, each connector will have a different price model, limitations and specifications to learn, and no individual component will create relationships among different types of data. Employing, for example, the OpenText connector for SharePoint will enable a document-centric view, but won’t facilitate a matter-centric view with non-DMS content without additional development. An alternative is to utilize a single-source SharePoint acceleration platform. This approach streamlines deployment by including all the connectors, Web parts, and other modules you may need, while also providing a framework to form intelligent relationships among the types of data being aggregated. Some IT professionals express concern that committing to a particular acceleration platform will leave them too little flexibility down the road. However, this need not be the case. Not only can your platform facilitate self-managed, ongoing customization without specialized database expertise, it can also open the door to additional components you can choose to add over time for additional functionality. Be sure to weigh the price of a legal SharePoint acceleration platform against the individual licensing and development costs associated with the application-centric approach. Consider also your time to deployment, your available resources and the risk of stasis for a drawn-out development cycle. Finally, be sure you’re comfortable with the people involved and the relationships you’re forming, as you will be relying on them to be current on the integrated products you care about, and, in effect, to do some of the ”building” for you. ILTA 20 Portal Platforms ILTA White Paper Some, like CRM or DMS data, may merely be mapped to the portal using the Business Data Catalog (BDC) in MOSS 2007 or Business Connectivity Services (BCS) in SharePoint 2010. In both cases, some data-mashing may be occurring, with metadata being copied to multiple locations and pointers being implemented to multiple data stores. This can complicate data archiving procedures, as well as litigation holds. Realize also that your new portal may heighten attorney expectations for instant access to information. How will attorneys react when a link goes dead or search results change because the destination files have been archived according to policy? Alternatively, what will be the fallout if an attorney winds up repurposing, for example, historical client data found via the portal if RM policy required that data to be retired? Recommendation: RM-based templates can be implemented to keep your new portal in sync with your existing policies on a matter- specific or more foundational