Business Productivity and Information Architecture

“SharePoint Solution Design” document template

I published several posts regarding document templates for the SharePoint projects previously, but they were related to the specific sections of the projects.

Recently I had discussion with colleagues about the structure of “Solution Design” document and logical inconsistency we have seen all time.

Almost each project you are starting should be based on the “Solution Design” that describes and justifies what is going to be implemented. I've seen tons of documents for C++, and .NET projects in the Financing, Marketing, Industrial and others areas, that were organized quite good logically. By “quite good” I mean that you structure the document from the broad and general terms, introducing what do we have, moving toward the specialization and physical artefacts. In two words it should be “out-in” approach.

SharePoint brings a lot of new conceptions and artefacts that either don’t exist or are not taken into account for the Solution Design that came from other areas.  For example, “content types”, “capacity planning”, “farm architecture”. Reviewing several “Solution Design” documents for SharePoint projects last 6 months I saw a lot of inconsistency of how information is addressed and structured – people mess up the physical artefacts with logical ones, structure flows without any logic and smooth transitions. For example, in section of “Solution architecture” they put together logical design and network infrastructure. It’s ok for a Web application where all servers have almost the same role, but in SharePoint the logical and physical design are two different things and they don’t match each other 1-to-1. Logical designs is based on metadata and taxonomies, when physical design is dictated by “usage patterns” and data volumes. You will have absolutely two different physical designs creating system for enterprise to manage documents online and for the digital agency with the terabytes of media files – conceptually you have the same metadata but physical organization will be different due to usage approach.

I have some thought for a while about creating the “SharePoint Solution Design” template that is properly aligned - starting from the broad terms, which describe what the system is about, specializing the taxonomies and content prior to the physical organization.  Such document should aim to targets:

• Lead the reader logically to the physical design, describing what artefacts the system manipulates and how they are used. So, when we come to the physical organization the reader will have their own vision of system in mind.
• No hops between unrelated sections (like logical and physical architecture), because physical design should be justified previously.

After more that hour of analysis, brainstorming a discussion we came out with the following structure that I want to publish here and hear your feedbacks.

Update 1 (Feb 12, 2009): added the section about “Information Artefacts”. This is important to understand what are the information that system uses, ignoring the technology aspect. Is it about managind the word documents and having multilevel approval, or is it the financial company who creates the dashboard for the stock marker. This is important to be described earlier to have understanding about usage patterns, because it will affect the Information Architecture.

1. OVERVIEW
1. Background
2. Document Purpose
2. INFORMATION ARTEFACTS
1. Artefacts overview (the list of information pieces the system operates)
2. Data Flow (how data is moving across the system0
3. Usage cases (different scenarios of using information artefacts)
4. Artefacts Managing (describing how different products – sharepoint, drupal and others) can manage artefactts)
3. INFORMATION ARCHITECTURE
   1. Site Structure
      1. Site Maps
   2. User Interface and Branding
      1. Wireframes
      2. Navigation
      3. Branding
   3. Content Types, Columns and Lists
      1. Content Types
      2. Columns
      3. List
4. LOGICAL ARCHITECTURE
   1. Feature Mapping (which features of the SharePoint  are gonna be used and for which purposes)
   2. Farm Logical Architecture
   3. Web Applications
      1. Zones
      2. Managed Paths
   4. Site Collections and Content Databases
   5. Shared Services
   6. User Profile and Properties
   7. Search
   8. Audiences
   9. Service Accounts
5. CAPACITY PLANNING
6. PHYSICAL ARCHITECTURE
   1. Server Topology
   2. Network Infrastructure
   3. Storage Requirements
      1. Web Front-End Servers
      2. Application Server
      3. SQL Server