SharePoint is probably one of the best money-saving content management systems on the market today. More than a few organizations have boasted of saving $400,000 or more. And the money-saving stories come from various industries including city government, retail, federal government and more.
But most organizations only harness about 50% of SharePoint’s capabilities—mainly using Document Management, Records Management, Workflows and Business Intelligence. There are a few, however, who have taken their SharePoint implementation one step further and used it to replace third-party applications. SharePoint introduces external content types, which make it easy to use SharePoint to add as well as view/update data stored in an external database. Its secure store service provides a way to securely connect to external data. But, a project aimed at taking advantage of all that SharePoint has to offer could easily become massive.
This post discusses the feasibility of using enterprise architecture concepts in conjunction with Microsoft SharePoint Worksheets, technical diagrams and guides to implement SharePoint. This post does not discuss doing away with information published by Microsoft. Instead it presents a way to divide a SharePoint implementation into smaller, manageable pieces so a broader range of requirements can be defined and incorporated into an overall SharePoint Implementation.
Basic Enterprise Architecture
Enterprise Architecture presents the framework necessary to break an organization into manageable pieces. Most Enterprise Architecture frameworks include a Vision and four architectures (Business Architecture, Data Architecture, Technology Architecture and the Application Architecture). Several enterprise architecture frameworks recommend dividing the organization into segments.
Segment Architecture
A Segment Architecture approach focuses on analyzing a business function within an organization. The Business, Data, Application and Technology Architectures are completed for the segment—a cycle that is repeated until all segments in the organization are completed. Below is a diagram from the Federal Enterprise Architecture (FEA) Reference Model Document. The diagrams show how the federal government has broken its two support operations (Management of Government Resources and Service for Citizens) into segments.
Enterprise Architecture is often used to implement Enterprise Resource Planning (ERP) systems—making it a feasible option for an enterprise-wide SharePoint implementation.
Business Architecture
Business Architecture focuses on the following key areas: Business Activities (tasks performed to complete a process), Business Rules, Business Goals, Business Services and the Business Functions used to deliver the Business Services. Some Enterprise Architectures also call for performance metrics so organizations can measure their success toward achieving their business goals.
In general, the Business Architecture provides organizations an opportunity to review current Business Activities for a business function.The objective is to define how the activities are completed and look for improvement areas that SharePoint provides. There are various artifacts that can be used. For example, FSAM recommends the "As-is Business Process Swim Lane Diagram" to capture how work currently gets done. The "Target Business Process Swim Lane Diagram" to identify how work will get done in the future, which should include activities to be automated by SharePoint workflows.
In addition, the inputs and outputs used by a business function (s) is also captured. Data and documents shared by multiple business functions are captured through data-sharing matrices. Keep in mind that the enterprise architecture approach used drives the artifacts used to document each architecture.
The most critical pieces of information captured for a segment's business architecture are the activities, roles and the information shared. A business function defines how it does work and the information it creates or produces. If an organization uses Business Process Swim Lane Diagrams to capture activities and activity steps, the Target Business Process Swim Lane Diagram should include a swim lane for a SharePoint workflow to capture its role in the process. Also keep in mind that once the Target Business Process Swim Lane Diagram is completed; the SharePoint Developer still needs to create the Visio diagram to define the steps, actions, branches, etc. for the workflow. Following is a segment artifacts business architecture Target Business Process Swim Lane Diagram for Staff Acquisition.
Note: An Operational Node Connectivity Description Diagram, which is an enterprise architecture artifact from the DoD Architecture Framework (DODAF), could provide additional insight as needed.
Partial Operational Node Connectivity Description (OV-2) Diagram
Breaking the SharePoint implementation work down into architectures and segments gives organizations the ability to implement more in less time because the focus is on a smaller scope of work. This approach applies industry best practices to ensure the project does not become overwhelming. When capturing the business architecture, information regarding the roles and who does what provides the information needed to configure SharePoint’s security in addition to outlining high-level workflow behaviors.
Lastly, the Microsoft Office SharePoint 2010 Worksheets used during this architecture include planning for audience and content targeting worksheets related to planning workflows, etc. Additional documents can include the Business Process Operations Report, Operational Node Connectivity Description Diagram, Organizational Chart, etc.
Data Architecture
The Data Architecture focuses on the organization’s data. The inputs and outputs captured using the TO-BE version of the Business Process Operations Report identifies the data, documents and records to be implemented. The rules associated with the process are also captured. As the inputs/outputs were captured, a matrix was also managed so others in the organization could indicate whether or not they used a given input or output.
At this this point there is still additional information that must be considered for the Data Architecture, including designing and implementing the Information Architecture. As additional business functions are assessed the termsets, terms, content types, etc. will increase based on additional information gathered. There are a number of SharePoint 2010 Worksheets used to capture the information needed to answer the above questions. A few of the considerations include the following:
These are just a few of the questions that are addressed to complete the Data Architecture.
Technology Architecture
The Technology Architecture is used to define the technology required to implement a customer’s SharePoint implementation. Discussions are held regarding servers, software, backup/recovery, planning import and export servers, upgrade paths for any existing SharePoint instances, etc. Microsoft has developed a number of technology diagrams that can help with defining the Technology requirements for an organization’s server farm. A number of the technology diagrams are in the “Planning Guide for Sites and Solutions for Microsoft SharePoint Server 2010, Part 1.” Any other worksheets related to configuring or building the infrastructure are used in this architecture.
Application Architecture
The Application Architecture is most concerned with application capability and branding. Discussions held during this Architecture also include capturing information on the capability that should be built in SharePoint to replace third-party applications or outdated home grown applications. The organization’s objective drives what artifacts are used. For example, the organization may compile a list of software capabilities by system (for organizations with multiple business applications). This makes is easy to spot duplicate capability and even duplicate systems. It can also be used to determine what capability should be rebuilt using SharePoint to operate a more integrated environment.
Other areas reviewed during this architecture include what business service applications will be used as well as the secure stores and external content types required to connect to external data. The Microsoft SharePoint Worksheets used include Plan top-level site collections and sites, plan incoming e-mail and all other worksheets that relate to building or configuring software capability.
Summary
More than a few organizations have boasted of saving $400,000 or more. And the money-saving stories come from organizations in various industries including city government, retail, federal government and more. But most organizations only harness about 50% of SharePoint’s capabilities—mainly using Document Management, Records Management, Workflows and Business Intelligence.
Most likely, many organizations do not use SharePoint to its fullest ability because of its many features and using it to its fullest likely means an overwhelming project that is likely to fail. Organizations can be divided into segments and divide the SharePoint work into architectures (i.e., Business, Data, Technical and Application). Dividing the implementation into smaller pieces gives organizations an opportunity to include more SharePoint functionality and experience a more useful implementation that will save money.
The process begins with the Business Architecture, which would use the selected business architecture templates to capture the business activities and steps along with data and documents being shared. The next step would be to further define the Data Architecture. Although the Application Architecture is defined before the Technology Architecture; the Technology must be implemented prior to the Application Architecture. In other words, update or add hardware before deploying the applications.
But most organizations only harness about 50% of SharePoint’s capabilities—mainly using Document Management, Records Management, Workflows and Business Intelligence. There are a few, however, who have taken their SharePoint implementation one step further and used it to replace third-party applications. SharePoint introduces external content types, which make it easy to use SharePoint to add as well as view/update data stored in an external database. Its secure store service provides a way to securely connect to external data. But, a project aimed at taking advantage of all that SharePoint has to offer could easily become massive.
This post discusses the feasibility of using enterprise architecture concepts in conjunction with Microsoft SharePoint Worksheets, technical diagrams and guides to implement SharePoint. This post does not discuss doing away with information published by Microsoft. Instead it presents a way to divide a SharePoint implementation into smaller, manageable pieces so a broader range of requirements can be defined and incorporated into an overall SharePoint Implementation.
Basic Enterprise Architecture
Enterprise Architecture presents the framework necessary to break an organization into manageable pieces. Most Enterprise Architecture frameworks include a Vision and four architectures (Business Architecture, Data Architecture, Technology Architecture and the Application Architecture). Several enterprise architecture frameworks recommend dividing the organization into segments.
Segment Architecture
A Segment Architecture approach focuses on analyzing a business function within an organization. The Business, Data, Application and Technology Architectures are completed for the segment—a cycle that is repeated until all segments in the organization are completed. Below is a diagram from the Federal Enterprise Architecture (FEA) Reference Model Document. The diagrams show how the federal government has broken its two support operations (Management of Government Resources and Service for Citizens) into segments.
 |  |
Business Architecture
Business Architecture focuses on the following key areas: Business Activities (tasks performed to complete a process), Business Rules, Business Goals, Business Services and the Business Functions used to deliver the Business Services. Some Enterprise Architectures also call for performance metrics so organizations can measure their success toward achieving their business goals.
In general, the Business Architecture provides organizations an opportunity to review current Business Activities for a business function.The objective is to define how the activities are completed and look for improvement areas that SharePoint provides. There are various artifacts that can be used. For example, FSAM recommends the "As-is Business Process Swim Lane Diagram" to capture how work currently gets done. The "Target Business Process Swim Lane Diagram" to identify how work will get done in the future, which should include activities to be automated by SharePoint workflows.
In addition, the inputs and outputs used by a business function (s) is also captured. Data and documents shared by multiple business functions are captured through data-sharing matrices. Keep in mind that the enterprise architecture approach used drives the artifacts used to document each architecture.
The most critical pieces of information captured for a segment's business architecture are the activities, roles and the information shared. A business function defines how it does work and the information it creates or produces. If an organization uses Business Process Swim Lane Diagrams to capture activities and activity steps, the Target Business Process Swim Lane Diagram should include a swim lane for a SharePoint workflow to capture its role in the process. Also keep in mind that once the Target Business Process Swim Lane Diagram is completed; the SharePoint Developer still needs to create the Visio diagram to define the steps, actions, branches, etc. for the workflow. Following is a segment artifacts business architecture Target Business Process Swim Lane Diagram for Staff Acquisition.
Partial Operational Node Connectivity Description (OV-2) Diagram
Breaking the SharePoint implementation work down into architectures and segments gives organizations the ability to implement more in less time because the focus is on a smaller scope of work. This approach applies industry best practices to ensure the project does not become overwhelming. When capturing the business architecture, information regarding the roles and who does what provides the information needed to configure SharePoint’s security in addition to outlining high-level workflow behaviors.
Lastly, the Microsoft Office SharePoint 2010 Worksheets used during this architecture include planning for audience and content targeting worksheets related to planning workflows, etc. Additional documents can include the Business Process Operations Report, Operational Node Connectivity Description Diagram, Organizational Chart, etc.
Data Architecture
The Data Architecture focuses on the organization’s data. The inputs and outputs captured using the TO-BE version of the Business Process Operations Report identifies the data, documents and records to be implemented. The rules associated with the process are also captured. As the inputs/outputs were captured, a matrix was also managed so others in the organization could indicate whether or not they used a given input or output.
At this this point there is still additional information that must be considered for the Data Architecture, including designing and implementing the Information Architecture. As additional business functions are assessed the termsets, terms, content types, etc. will increase based on additional information gathered. There are a number of SharePoint 2010 Worksheets used to capture the information needed to answer the above questions. A few of the considerations include the following:
- What data is shared across two or more groups?
- What document templates and forms must be made available?
- What document libraries are required?
- What document routing rules are needed?
- What global versus local termsets and terms are required?
- What records are we managing and what retention and other policies are needed for the records?
- What content types are used to standardize data collection, document grouping, etc.?
- What documents do we want to rate?
- What audiences are associated with what documents?
These are just a few of the questions that are addressed to complete the Data Architecture.
Technology Architecture
The Technology Architecture is used to define the technology required to implement a customer’s SharePoint implementation. Discussions are held regarding servers, software, backup/recovery, planning import and export servers, upgrade paths for any existing SharePoint instances, etc. Microsoft has developed a number of technology diagrams that can help with defining the Technology requirements for an organization’s server farm. A number of the technology diagrams are in the “Planning Guide for Sites and Solutions for Microsoft SharePoint Server 2010, Part 1.” Any other worksheets related to configuring or building the infrastructure are used in this architecture.
Application Architecture
The Application Architecture is most concerned with application capability and branding. Discussions held during this Architecture also include capturing information on the capability that should be built in SharePoint to replace third-party applications or outdated home grown applications. The organization’s objective drives what artifacts are used. For example, the organization may compile a list of software capabilities by system (for organizations with multiple business applications). This makes is easy to spot duplicate capability and even duplicate systems. It can also be used to determine what capability should be rebuilt using SharePoint to operate a more integrated environment.
Other areas reviewed during this architecture include what business service applications will be used as well as the secure stores and external content types required to connect to external data. The Microsoft SharePoint Worksheets used include Plan top-level site collections and sites, plan incoming e-mail and all other worksheets that relate to building or configuring software capability.
Summary
More than a few organizations have boasted of saving $400,000 or more. And the money-saving stories come from organizations in various industries including city government, retail, federal government and more. But most organizations only harness about 50% of SharePoint’s capabilities—mainly using Document Management, Records Management, Workflows and Business Intelligence.
Most likely, many organizations do not use SharePoint to its fullest ability because of its many features and using it to its fullest likely means an overwhelming project that is likely to fail. Organizations can be divided into segments and divide the SharePoint work into architectures (i.e., Business, Data, Technical and Application). Dividing the implementation into smaller pieces gives organizations an opportunity to include more SharePoint functionality and experience a more useful implementation that will save money.
The process begins with the Business Architecture, which would use the selected business architecture templates to capture the business activities and steps along with data and documents being shared. The next step would be to further define the Data Architecture. Although the Application Architecture is defined before the Technology Architecture; the Technology must be implemented prior to the Application Architecture. In other words, update or add hardware before deploying the applications.
