Friday, January 6, 2012

SharePoint Business Architecture

Architecture refers to the art of building. The word "architecture" has many meanings. Probably, the most understood meaning is "the art of constructing structures such as homes and buildings." The architect designs the blueprints of the home or building, taking into account factors such as design, space, light, materials, stability, load, and future needs.

Architecture is important because it accounts for the functional and nonfunctional requirements early on. Microsoft Office SharePoint Products and Technologies are powerful tools that increase collaboration and sharing of content. If implemented correctly, SharePoint can store and serve a vast quantity of information very well. However, without proper architecture and governance, a SharePoint deployment can become an unorganized collection of sites, links, users, and documents that hampers productivity and makes it harder to find information.

A good architecture plan and governance plan  lay down guidelines for deploying SharePoint as a solution to common business challenges. The architecture of SharePoint includes designing and allocating the hardware infrastructure needed to support the site, listing out the sites and site hierarchies that will serve the needs of the business, establishing users and roles that will be given permissions to the sites, establishing the relationships between sites, and planning for the needed site features, site customizations, and site and list relationships (which include how data will be rolled up and aggregated from sites and lists to provide an overview of information).

A good governance plan outlines the administration, maintenance, and support of the SharePoint environment. The governance strategy seeks to ensure that SharePoint is used in accordance with the designed goal and that best practices are followed to keep the portal manageable and usable. Best practices include processes for operation in the portal for tasks such as creating sites and lists, assigning permissions to users, using consistent naming conventions, and generally enforcing the guidelines.

When creating a building, architectural concerns include data gathering, planning, and the design of that building. The SharePoint architect must design the SharePoint building to withstand the test of time (meaning the architect must future-proof the implementation by building in robustness and resiliency) and, based on future client requirements, be able to expand easily (in other words, scalability with an eye on future upgradeability of SharePoint installation based on factors such as business need, hardware, software resources, and so on).

For SharePoint, there are three levels of architecture: hardware architecture, software architecture, and information architecture.

Hardware Architecture

To deliver a robust SharePoint 2010 environment, it is necessary to carry out technical design, which looks at all areas of SharePoint 2010 concerning the equipment it will run on or be connected to and systems and processes it will interface with. The following is a list of planning requirements:
  • System requirements determining what is required to deploy SharePoint 2010.
  • Services architecture determine what service applications are defined and how are they structured.  
  • Logical architecture presents the design in terms of isolation. This planning task looks at farms, service applications, Web applications, content databases, site collections, sites, zones, MySites, and so on.
  • Authentication examines authentication methods, such as claims-based authentication topologies.
  • Server hardening this task focuses on server snapshots, ports, protocols, and the Web Server, Application Server, and Database Server roles.
  • Business continuity examines the business decisions, processes, and tools put in place to handle a crisis. A crisis can affect the organization or be part of a local, regional, or national event. Business continuity and disaster recovery are huge areas in SharePoint and planning for them is an important part of ensuring a resilient and robust platform.
  • Performance and capacity determines the process of mapping the design for SharePoint 2010 to a farm size and the hardware needed to support the business goals. 
  • Virtualization SharePoint 2010 is fully supported when deployed in a Windows Server 2008 Hyper-V environment. This task examines the licensing and topology.

Software Architecture

The software architecture of SharePoint is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. So decisions to be made include determining what components of SharePoint are needed, what will be visible, and the structure of SharePoint. For example, is SharePoint going to be treated as an out-of-the-box solution, slightly modified with internal applications, or will it include third-party additions? Will it simply need just team site components (for example, the free SharePoint Foundation version), or do you need more service application, enterprise content management, or metadata features, such as those provided through SharePoint 2010 Enterprise?

Software architecture examines SharePoint from a site and solution planning perspective, taking into consideration site components, security, governance, enterprise content management, Web content management, managed metadata, business intelligence, data and processes, access services, quota management, and social computing.

As an example, suppose that you’re going to implement SharePoint in an organization that already has SharePoint but needs to expand. They have a third-party tool providing some functionality that the client finds useful. From scoping the information architecture, you found how much usage it gets, how the data is used, how it flows, and so on. From further investigation of the software architecture, you find that the relevant tool cannot grow with the service. This means revisiting the functionality in terms of the information architecture and finding an alternative, which then drives the software architecture.


Information Architecture

Information architecture involves studying the type and amount of information used within an organization, organizational structure, information flow, process flow, and more. This is an extremely important aspect of the Plan phase. Without it, SharePoint is not defined to meet the client requirements, because information architecture leads to SharePoint user strategy in terms of content management. Identifying the organizational information and management information goals combines the work of information analysts and business analysts, coordinated by the project Manager and feeding back to the SharePoint architect.

Large organizations have documentation plans and methods of managing their data across the organization (for example, retention plans and archive plans), and some use information analysts to manage, coordinate, and categorize how members in the organization deal with information. Additionally, organization face legal and regulatory compliance requirements that directly influence how data is retained long term. In the United States, for example, the Sarbanes-Oxley (SOX) Act established record-retention rules in July 2002. It is highly recommended any company have a records-retention policy that complies with regional and national laws.

Another benefit of a good records-retention policy is a decrease in storage costs.The information analyst details from the ground level the organizational data concerning information standards and policies set out by the business. Information architecture establishes information control and compliance policies so that accumulating information is done in a well-managed way and does not create data chaos.

SharePoint 2010 provides enterprise content management tools that can help lower costs associated with the control and storage of information, decrease complexity, and increase user participation relating to content control. Combining SharePoint 2010 with Office 2010 takes information management to a higher level by extending information control from the desktop environment to SharePoint 2010 sites and content.

The aim of information architecture in SharePoint is to reduce the manual end user actions related to metadata, to scale policies and processes across all types of content in an organization, and to increase compliance and transparency. To meet this goal, there must be an examination leading to the creation of an organizational taxonomy. During the Design phase of the SharePoint project, the information analyst (working with the SharePoint architect) creates a taxonomy for the organization by examining metadata and information policies.

The business analyst can provide, through the collection of user requirements, an understanding of what the typical content life cycle is in the business. This shows how end user content becomes managed content. Typically, managed content begins its life as temporary information created by the individuals in the organization, leading to work in progress (and this means multiple individuals working on the same content) and in the backdrop of retention and disposition (business teams or individuals deciding on whether documents should be archived and what their state is, either approved, published, or other). SharePoint 2010 provides tools to ensure the content life cycle can be designed and adhered to. Enterprise content types, document sets, information management policies, metadata, term sets, and content organizers can be established using SharePoint 2010 document management features. 

Here are some basic procedures for setting the information architecture for SharePoint 2010:

  • Carry out an investigation and inventory of existing content.
  • Classify the content by performing the following tasks: Look for definitions of structure, policy, and defaults; Identify organizational-level content by enterprise, department, and team; Define what “general use” content is.
  • Organize content into enterprise content types and document sets, keeping the following factors in mind: Content types are where there are definitions of structure, policy, and defaults; Content types can inherit from other content types; Document sets are where the work spans multiple documents.
  • Decide where information management policies apply. When doing this, be sure to consider access permissions, auditing, user restrictions (for example, no printing), retention, and deletion.
  • Decide on applicable metadata by performing the following tasks: Define customized columns, and associate them with documents and lists; Define any cases where the system or user might take different actions based on the characteristics of an item. Note that the characteristics of the item are metadata; Find out what common things users will want to sort or filter items on; Find out what words or phrases users are likely to tag items with; Use Choice or Lookup columns in SharePoint 2010 sites; Use the existing taxonomy if the organization has one.
  • Map the physical flow of the document, including the sites, lists, and libraries where the content will be physically located throughout the document’s life cycle.