Make your SharePoint Projects more successful by using a “Dual” Architecture Approach
By: Bernie Hockswender, VP Marketing & Sales, i-Squared Inc.
Reprinted from the March/April 2009 issue of Infonomics Magazine, published by AIIM, representing the global enterprise content management community. For more information, visit www.infonomicsmag.com or www.aiim.org.
The most often asked question we hear when consulting on a SharePoint project is, “How do we get started?” Our “Best Practice” recommendation is always the same. Start by approaching the project on two separate fronts: a Technical Architecture and an Information Architecture.
There are many reasons why this is a good approach. The biggest is that while both efforts are critical to the success of any SharePoint project, the two require dramatically different timelines, perspective and skill sets.

The IT team is generally very good at managing licensing, server provisioning, network requirements, security administration etc. These are all part of the Technical Architecture required for SharePoint and squarely belong under IT management responsibility.
But mapping the Information Architecture or the “what will we accomplish and how” components are not IT issues. Planning which users and business processes will be impacted, how the site will be governed, who is responsible for content updates, which departments will be most resistant or open to adoption etc., are all issues better analyzed, mapped and managed by assigned business managers who work in conjunction with IT.
IT organizations are woefully understaffed and time constrained to do the in-depth planning, interviewing, process mapping and strategy configuration that a SharePoint “Information Architecture” component requires. Strong planning and communication of business process impact, site governance, taxonomies, metadata, user adoption and maintenance of content will avoid most of the problems found with early implementations of SharePoint. It’s rare that SharePoint problems are technology related.
In most cases where SharePoint projects faltered, SharePoint capability was provided to users without Information structure and a well defined business impact communication plan.
When done this way, the projects produce many different SharePoint island sites, poor search and share capability, inconsistent rules of engagement (governance) and ill defined responsibility for updating, storing or retiring information. They end up creating or duplicating the very problems that SharePoint was intended to solve.
In our practice, we see several consistent patterns:
-
The complexity and time requirements of the Information Architecture work in a SharePoint project is almost always underestimated.
-
Business objectives get lost when a SharePoint project get delegated solely to IT.
-
When business objectives get lost or go untracked, it is very difficult for any SharePoint project to succeed.
Manage your SharePoint projects with the right people working a dual Information and Technical Architecture approach and your chances of long term successful business results will increase dramatically.
i-Squared Inc. is a Pittsburgh based consultancy specializing the Enterprise Content Management. Comments should be directed to bhockswender@i-squared.us.