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.

 

SharePoint Governance Architecture

Governance is the cornerstone to any successful SharePoint implementation. Without it, you are doomed to fail eventually—a lesson that many organizations learn the hard way.

Because governance matters so much, there is a lot of information about it, starting with the TechNet SharePoint Server 2010 Governance Resource Center.

Many of these resources focus on how to create a governance framework: how to assemble the people, policies, and procedures and how to develop a governance plan. But all too often, such discussions leave out a fourth equally important component of governance: technology.

You must understand the technology that you are trying to govern; you can’t ask it to do something that it cannot do. And you should use the technology to facilitate governance. In this first of a series of articles, I will explore the technical side of governance and thereby answer several vital questions:

• What does a governable SharePoint implementation actually look like?
• What is the physical and logical architecture of such an implementation?
• How many farms, servers, web applications, content databases, site collections, and sites does such an implementation have?

The initial answer to all three questions is, unfortunately, “It depends.” The answer depends not on SharePoint, but on what you are trying to achieve by using SharePoint. The best way to get to the answer that applies to you is to follow my four-step Architecting Governance process. By following this process, not only can you answer the previous question, but you will have a logical, physical, and governable architecture that meets your business requirements.

Given the limitations of space and time, this article will focus on the process itself, which involves four major steps. In future articles, I will explain how you can apply the process to specific scenarios, to gain prescriptive guidance towards successful architectures. And I will show you how to use the technology to automate and enforce your governance policies.

Step 1: Define Your Requirements

 

Step 1 of Architecting Governance is all about requirements. As a consultant, you spend probably 80 percent of your time helping customers to define requirements and develop discipline around requirements gathering. After all, you must understand the requirements for any solution before you can effectively design that solution. SharePoint is no different. 

The problem that I observe is that SharePoint implementations involve a lot of requirements. So I find it helpful to categorize them, and then identify which categories are salient at each step in the Architecting Governance process. I suggest that you group your requirements into these categories:

• Business requirements—These are the requirements that really matter. They define the business purpose of the solution that the customer is asking you to create. Whenever possible, avoid polluting business requirements with technical requirements. More often than not, technical requirements are artificial. When a business customer says, “I need a sub site that does x,” or “I need a button that does y,” that customer is casting themselves as a technologist—a solutions developer. Encourage them to take a step back and describe the desired result (x or y) without mentioning technology. Let the technical solution be developed by those who know the technology.
• Technical requirements—Occasionally, technical requirements must be considered. For example, if your mobile sales force is going to use their iPads to access the solution that you are providing, then the ability to access the solution from iPads is a valid technical requirement. Such technical requirements more often relate to architecture—interoperability with other solutions—or infrastructure than to functionality or usability.
• Project requirements—These requirements relate to the creation of the solution, not to the business purpose of the solution. Budget and deadlines are prime examples of project requirements.
• Information-architecture requirements—Information architecture, in its most traditional definition, relates to how content is described, organized, and discovered.
• Information-management requirements—Information-management requirements define how the content is managed over its lifecycle: how is it created, maintained, and archived or deleted. These requirements relate to security, records management, auditing, and compliance.
• Service-management requirements—Behind the solution, the content, and the information is the service itself. Service-management requirements describe IT assurance expectations: recovery, availability, and performance. These requirements lead to service level objectives (SLOs) or service level agreements (SLAs).

Categorizing requirements is valuable for several reasons. First, you can identify the dependencies between requirements. This ability allows you to proceed through the requirement-gathering process in a logical manner.