Wednesday, June 4, 2014

Sharepoint Architecture Template Part 1



Revision: 0.1



Table of contents

List of figures

1      Introduction

·      PORTAL = Automotive Supply Chain Portal, a private community site that internal and external parties need to have an account to login and contribute information.
o     Internal parties refer to MSTECHSHARING user, such as: developer, support rep, sales rep, and marketing.
o     External parties refer to MSTECHSHARING customers that can be 1st tier-supplier and 2nd tier-supplier.

1.1   Purpose

This document defines the MSTECHSHARING Architectural Design based on the MSTECHSHARING Functional Design Specifications. This Architectural Design document shall not repeat those design specifications. It details the high level key system components and also the deployment architecture to meet the functional design specifications. Key technologies are identified for each MSTECHSHARING service component.
The MSTECHSHARING architectural design strives to be both scalable and flexible. The system design is component based and provides great flexibility in deployment. The technical overview defines major system components and related technologies. It also provides deployment architecture.
The use cases mentioned in this document capture the specific functional and business rules applied on each independent business process activity and should enable the system users to validate the functionalities supported implicitly and explicitly by the system.  The use cases also identify the end users of the system.

1.2   Target audience

This document is developed by MSTECHSHARING Portal development team and will be used by project stake holders for development and maintenance.

1.3   Definitions


1.4   Scope

This document is applied to PORTAL project

1.5   Acronyms, and Abbreviations

Abbreviations and definitions used throughout the document are presented here to aid the reader.
Table 1: Acronyms and Abbreviations
Software Requirement Specification
Application Programming Interface

1.6   References

1.7   Overview

This document has following contents:
o     Section 1: Show document purposes and overview.
o     Section 2: Describe system overview and features.

2      Overall Description

2.1   System overview

2.1.1     MSTECHSHARING Technology Overview

MSTECHSHARING’s architecture design recommendations are the Functional Requirements document which supported for MSTECHSHARING’s customer and MSTECHSHARING’s staff, so we choose “SharePoint Technology” to manage information of each customer

2.1.2     Architectural Strategy Statement

To meet the MSTECHSHARING’s core requirements of a robust, scalable architecture, a combination of technologies has been recommended. We recommend this flexible suite of solutions to take advantage of the strengths of SharePoint

2.1.3     Inputs

Overview (datetime).

2.2   Software’s limit and storage data

2.2.1     Software limit

2.2.2     Storage data

3      Recommended Architectural Components

3.1   Standard Farm model

3.1.1     Overview

3.1.2     Technology Considerations

3.1.3     Software and Hardware Requirements

4      SharePoint 2010 farm topology

4.1   Define web server, application server, Database server, query server, crawl server

4.1.1     Web server

4.1.2     Application server

4.1.3     Database server

4.1.4     Query server (Query component)

4.1.5     Crawl server (Query component)

4.2   How many topologies for SharePoint Server 2010 and how many server on each topology

4.2.1     Limited Deployments

4.2.2     Small Farm Topology Deployments

4.2.3     Medium Farm Topology Deployments

4.2.4     Large Farm Topology Deployments

4.3   Server role in each topology: front-end, back-end, database

4.3.1     Web server roles

-         Host Web pages, Web services, and Web Parts that are necessary to process requests served by the farm.
-         Direct requests to the appropriate application servers.
-         This role is necessary for farms that include other SharePoint Server 2010 capabilities. In dedicated search service farms, this role is not necessary because Web servers at remote farms contact query servers directly.
-         In small farms, this role can be shared on a server with the query component.

4.3.2     Application server roles

4.3.3     Database server roles

4.4   How to solve: we use farm model because number of user and Data storage are large

4.4.1     Starting point architecture follows number of items

4.4.2     At current time:      How to setup two tiers limited deployment:

4.4.3     At next time:      How to setup two tiers small farm:

4.4.4     In the future      How to setup three tiers: 


Post a Comment