This post is a rough draft of a chapter I'm writing for the SharePoint 2010 Best Practices book. I'm posting this to see what type of comments and feedback these ideas elicit. Please let me know what you think. Thanks.

The success or failure of any SharePoint implementation is directly related to how well the organization's mission, vision and goals are developed and communicated to form a proper context into which SharePoint can be implemented. To the extent that the mission, vision and goals are mis-aligned, immature or inadequately communicated, the SharePoint deployment will lack direction, focus and maturity.

Often, organizations blame the technology for not working well in these scenarios. Instead, by not doing their due diligence at the strategy layer, these organizations unwittingly diminish the value of every platform they install to support their business goals. In this chapter, we'll present our current thinking on how to gain alignment between the company's strategy layer with with your SharePoint implementation. There is much to learn, so we need to get going!

More info This chapter will not call out a minimal number of individual best practices because this chapter discusses a single, broad best practice, namely, that the context into which SharePoint is installed must be that of a clearly articulated mission, vision and set of goals. It is the responsibility of those who are charged with the oversight of the organization to develop these three enterprise elements in an unambiguous form and to communicate such to the members of the company.

More Info In this chapter, we'll use the phrase strategic layer or just strategies to refer to that layer of business where the mission is defined, the vision is defined and communicated and the resulting strategies are developed.

Understanding why Alignment is Important

In most environments the authors find themselves consulting, the organizations have reasons and plans for their SharePoint implementation but are at a loss to connect those plans to the organization's strategic layer. Lack of continuity between the strategic layer and the operational layer results in a number of negative outcomes, including resistance to change or excessive project costs due to scope and focus changes. For example, it does an organization little good to emphasize in their strategic plans that they are going to grow and mature their sales process and then not provide a robust CRM system in which to grow and mature that process. Another example would be when we state that we're going to use SharePoint for document collaboration and then not teach users how to use SharePoint features and forbid them from using e-mail to pass documents between each other.

There are three core reasons that alignment between the strategic layer and the implementation of SharePoint is important. First is that the implementation of any software package, including (but not limited to) SharePoint is intended to provide a tool set for the company to achieve its' mission, vision, goals and objectives. If the strategic layer isn't well defined and well communicated to the company, then it's likely that any software implementation or any process development will not be supporting of the company's strategy.

Secondly, mis-alignment between the software packages that provide the toolbox for employees to achieve success in the company's strategic layer will result in inefficiencies whose opportunity costs will be both hidden and wasted. It's one thing to know and understand an opportunity cost and to make a tradeoff decision that accounts for the cost. It's quite another to implement one or more processes with supporting software that are mis-aligned with the organization's strategic direction and create unnecessary opportunity costs by injecting inefficiencies into your system. Obviously, the former is preferred; the latter is to be avoided.

A third reason to gain alignment is due to the ripple effects of mis-alignment. If SharePoint is implemented in mis-alignment to the company's strategic direction, then the software platforms and processes that either depend on SharePoint or utilize SharePoint's features will also be mis-aligned. For example, if you install Project Server on top of SharePoint or if you utilize SharePoint's workflow features, you'll find that your Project Server implementation or some of your workflows won't align with where the organization is headed. Now, the authors assume that SharePoint is being installed as an enterprise service offering, not as a point solution.

Alignment can be gained only when the following is true:

• Organization has a well-defined and well-communicate strategy
• Organization is intentional about the implementation of the strategy
• The strategy is written in such a manner as to communicate downlevel goals, objectives and actions that support the strategy
• The software implementation is seen as a tool to accomplish the downlevel goals, objectives and actions that support the strategy

From Vision to Best Practice

What follows in the coming sections is likely the most important discussion you can have about the environment into which SharePoint is installed. While it is meritorious to discuss the technical best practices, it is more important and formitable to discuss the proper context in which SharePoint enhances the vision, mission and strategy of the organization.

This section will present a number of ideas that most technically-oriented people may brush off as over-engineered business process. But if you take the time to read this and seriously consider its' implications, you'll find that this section is more than mere bloviation, it is the core of the onion around which a solid SharePoint implementation exists.

From Vision to Strategy

Most organizations exist for a purpose – they don't just "appear" one day through a random act of chance. People associate in different ways and for a plethora of reasons. But most of those reasons can be reduced to the notion that in one way or another, they believe their association will be good for them in the future. Dissociation occurs for the same basic reason: people believe their future will be better if they dissociate from those with whom they are presently associating.

When businesses are started and grown, they generally do so because those involved in the effort share a common vision and mission. Both are usually expressed via individual statements. A vision statement takes into account the current status of the organization, and serves to point the direction of where the organization wishes to go. As a means of setting a central goal that the organization will aspire to reach, the vision statement helps to provide a focus for the mission of the corporation, business, or non-profit entity. In contrast, a mission statement is more concerned with the overall aim of the business, a simple statement of the company's reason for being. Often the statement will include verbiage that makes a pledge to deliver a superior product or service to customers on a consistent basis. From this perspective, a mission statement is about maintaining a certain quality or attribute.

Both the vision and the mission of an organization can change over time, but such change is usually incremental and the pace is very slow.

The strategy of the organization lays out the combination of policies, processes, and procedures that are employed to help an organization achieve its' mission and vision statements. An overall business strategy is multi-layered, since it involves the coordination of the operations of every department and division within the company structure. While involved, this type of strategic planning is necessary if the function of each component of the business is to compliment all the other components.

The development and connection of the vision, mission and strategic statements is rarely accomplished by anyone other than upper management in an organization. If the organization is a non-profit, then this work falls (usually) to the governing board. If the organization is a privately held, for-profit business, then these activities are fulfilled by the owners and key employees in the business.

For purposes of this book and this chapter, we'll assume that you have a clear set of statements that lay out the vision, mission and strategy of the organization. However, even the strategic layer will be muddled by the introduction of two very common elements that help shape the strategy of an organization. In fact, this author would postulate that these two elements have more to do with the strategic focus of an organization than we'd like to admit. Often the vision and mission statements provide the guardrails while the strategy forms the road that we build as the organization matures and moves through time. It is in this context that we turn our attention to two methods of further developing the context in which SharePoint resides as well as understanding how to make a non-emotional, data-driven decision on which features in SharePoint are needed in a given environment.

The Strategic Layer

In this section, we'll turn our attention to Figure 3-1 and look at the two main elements that often form the strategic direction for an organization.

The first element is a problem to resolve. At a high level, many organizations face pervasive, nagging problems that must be resolved if they are to move forward and either capture new opportunities or mature as an organization. Sometimes, these problems are internal – such as the development of a mission-critical process to support the effort of capturing an opportunity. For example, a company might wish to mature its' customer information in their CRM system so they can launch a new line of products. Having additional demographic information on their customers might help them better segment their database so that they can more effectively market their new line of products to their current customers.

Often, the problems to resolve are closely related to the opportunities to capture. The latter can be represented by a technology update in one's industry, the demise of one's competitor, the addition of new skills or products that opens up new markets to the organization or perhaps a change in the laws or regulations that opens up new opportunities for the company. Regardless of what it is, most companies are assessing new products or services, new ideas and research or new processes that allow a company to capture additional parts of a new or existing market on a regular basis. Growth is usually the result of innovation and that nearly always represents new opportunities for a company to pursue.

Most strategic plans look at both problems to resolve and opportunities to capture. But regardless of which particular issue we're looking at, the end result is the same: we need to develop a business case to capture the opportunity or the business requirements that solve the problem. In reality, both are sets of requirements and statements that outline what is needed to move forward. We just use different verbiage to refer to the solution that solves a problem versus the business case that justifies moving forward to capture an opportunity.

It is at this layer that we must accurately and tightly define either what the problem is or what the opportunity encapsulates. The solution (requirements) can't be well written and be effective downstream in the process unless the problem or the opportunity is tightly defined.

Figure 3-1: Illustration depicting the process that starts with vision and ends with best practices.

Referencing back to Figure 3-1, there are two important items to note. The first is to understand that the two elements which form the strategic layer are problems to resolve and opportunities to capture. Also notice that the parallel activity of forming a business architecture from which the SharePoint feature set is aligned is also important to undertake because it is a data-driven method from which you can select the SharePoint features you need to execute your strategy without involving emotion or politics.

The way in which we define our problems and opportunities is through the process of writing a business plan to capture the opportunity or develop a set of business requirements to resolve the problem. In most situations, this activity will seem to be two sides of the same coin – we'll be writing down a business plan to capture an opportunity while also writing down what we need to do to avoid future problems. For example, if a company wants to expand in the same market with a new set of products, then this is clearly an opportunity to capture. But at the same time, this opportunity represents potential problems, such as ensuring that the current product line is not cannibalized by sales from the new product line or communicating clearly with customers so that confusion is not created by the introduction of the new product line. When a plan develops requirements that will enable the company to capture a new opportunity while also outlining how to avoid potential problems, you're clearly writing a business plan to capture an opportunity. This plan will include business requirements to avoid the problem(s) in the future, but the plan is entirely forward-looking, it is not defining a problem from the past.

Hence, the defining characteristic between a business plan that enables a company to capture an opportunity and a set of requirements that resolves a problem or set of problems is the element of time when looking at the problem. For example, if we're writing a set of requirements that looks at how to resolve a long standing problem, then our definition of the problem is based on experience of having the problem. In other words, we're looking back in time to learn about the problem and define it. Now, our requirements to resolve the problem are going to be fulfilled in the future, so in both cases, requirements are forward looking. But when defining a problem, the definition that gives rise to the requirements is backward looking. Perhaps the matrix in Figure 3-2 will help.

Figure 3-2: Differential Characteristics of Business Plans that Capture an Opportunity and Business Requirements that Resolve a Problem

	Where does the problem (potentially) exist?	purpose of writing business requirements	Implementation is…
Writing a Business Plan to Capture and Opportunity	Future	Avoid problems in the future and ensure success	Forward-looking
Writing Business Requirements to Resolve a Problem	Past	Define existing problem and offer path to resolution	Forward-looking

NOTE: Both types of plans will produce a set of business requirements that must be met in order for the plan to be successful. When we move to the next stage, Business Requirements and Governance, we're understanding that whether you're going after a new opportunity to help your business grow or whether you're trying to resolve a nagging problem, you'll have a set of business requirements that must now be translated into software decisions and project plans.

Business Requirements and Governance

Once we have the business requirements, it's time to write our technical requirements of what we want the software to produce. It is at this layer that variability and politics can seriously undermine the overall process.

The authors of this book have seen, on multiple occasions, customers who took the feature set of SharePoint and inserted that feature set as their written technical requirements for their project. Nothing will kill confidence in a SharePoint implementation faster than doing this because we're still not looking at SharePoint (or any other software product) at this layer. We're merely translating the business requirements into technical requirements that our software must have.

Now the reality is that the product team has done a good job of understanding this layer in the development of SharePoint and you'll find that often, SharePoint's feature set will meet your technical requirements. So the reason you go through the effort of writing your technical requirements is two-fold. First, you do this because it helps confirm to you and your organization that SharePoint is the right software product for your solution. And frankly, if SharePoint isn't the right software product, it's better to find this out now rather than after the product's implementation. Secondly, it helps remove the politics from the process. If you can demonstrate by mapping SharePoint's features to the technical requirements that SharePoint is the right software product to implement the business requirements, then the political infighting that tends to occur in larger organizations with multiple software teams in the IT department can be mitigated if not entirely eliminated.

So, what does it mean to translate a business requirement into a technical requirement?

Here is an example of what it means to articulate a business requirement and then turn the business requirement into a technical requirement.

Business Requirement    A document management system will be necessary to support the document lifecycles of the core documents necessary for this project and that will support legal requirements, such as chain of custody, legal holds and swift e-discovery.

Technical Requirement    The software package will support document management with the following features:

• Check out, Check in and versioning

• Workflow support for document's lifecycle enforcement
• Record declaration
• Record holds
• Auditing and Logging
• Metadata assignments with enforced uniformity where-ever the document is hosted or consumed
• All content should be indexed
• All content should be isolatable should e-discovery processes be declared on any single or group of content items
• All content should be securable using local control with global oversight

As you can see, the technical requirements deal with how the technology should behave and/or what elements must exist in the software in order for the software to support the business requirement.

Governance is really the intersection of information architecture, technical architecture, business processes, and business pressures. The real world issue we face is that all four of those are dynamic and since they are in constant flux, the governance of SharePoint is an ongoing effort. One of the hallmark's of good governance is that someone is clearly in charge and has been vested with authority to force compliance. In most environments that the authors have visited, this is not the case. Organizations that have good governance always have this hallmark in common.

Other hallmarks of good governance include the following:

• Process: governance must stipulate how process will support and work within SharePoint such that compliance with the process is true and yet ability to innovate the process is available within the governance model
• Measurements: governance is useless without compliance and compliance cannot exist without standards and measurements. Metrics that result from consistent measurements ensure that management has visibility into the process and the utilization of SharePoint as a business tool and whether or not SharePoint is being utilized in the highest-value ways to support the business goals.
• Enforcement: close in concept to measurements, governance is also useless without enforcement of the rules. Whereas compliance is the reporting of how well business users comply with the rules, enforcement is the pro-active actions management executes to ensure compliance. There will always be some business users who don't follow the rules. Without enforcement of the rules, they might as well not exist. In this book, we emphasize writing only those rules that can be enforced. If you write a rule for governance that can't be enforced, then the rule should not be written or included in the governance model.

More Info: For a more thorough discussion of governance, please read Chapter 8, Creating Procedural and Technical Governance Strategies.

Technical Requirements and Governance

Once the business requirements have been set, it's time to write the technical requirements. In the previous section, we illustrated how to turn a business requirement into one or more technical requirements. While tedious, this process is absolutely necessary for the following two reasons:

1. You can't know which software package to select until you know what you need the software to do. Writing out what the software and should and should not do given the set of business requirements you've written is essential to achieving a great SharePoint deployment.
2. Assuming that SharePoint Server 2010 is the correct software platform to support your business requirements, you'll also need to tweak or refine the business architecture process (refer back to figure 3-1) for this particular deployment of SharePoint. In addition, the technical requirements for SharePoint will then inform you as to the type of deployment you're undertaking relative to the other Enterprise Content Management, Record Management, Document Management and/or Collaboration packages in your environment:
   1. Point solution: SharePoint is installed and deployed to support a specific opportunity or to resolve a specific problem. Most of SharePoint's features remain turned off.
   2. Multi-point solution: SharePoint is installed and deployed to support multiple opportunities or to resolve multiple problems, but most of SharePoint's features remain turned off.
   3. Partial Enterprise solution offering: SharePoint is installed and deployed to resolve service offering gaps in your enterprise application architecture. These services are deployed with agnosticism toward any particular project or group of projects. Attention is given to ensuring that those features turned on in SharePoint either do not overlap with other enterprise applications or are consolidated into SharePoint.
   4. Full Enterprise solution offering: SharePoint is installed and deployed with all features and services turned on. Overlapping functionalities in other software packages are consolidated into SharePoint 2010.

While it might sound simple to align SharePoint with business strategy, as one considers all that is necessary to make this happen, one realizes that it is not so simple. Business strategy necessarily results in technology purchases and implementations. It is not uncommon for companies to have incomplete strategies, resulting in technologies that either leave gaps in supporting functionalities or overlaps across multiple platforms for the same functionality.

Writing technical requirements can consistently result in the highest chance for the best possible scenario: a suite of fully integrated software packages that when combined, the following is true:

• All requirements and strategies are fully supported
• No gaps exist in the technologies relative to the support of the requirements and strategies
• No overlaps exist in the technologies relative to the support of the requirements and strategies
• Business user training is kept to a minimum
• Lowest possible cost is attained
• Governance across all platforms is integrated and enforced
• Information architecture and design is fully implemented

Technical requirements will also pay attention to legal, cultural, budgetary, skill-set support, user acceptance, and process integration. As one author has put it: if all they can afford and execute correctly is email + file servers, that may be the best ECM solution until they can grow their budget, culture, IT support skills, user acceptance and processes to support a SharePoint implementation.

Now, we all know that a good ECM solution doesn't stand tall on email and file servers, but the author's comment is well taken: If the customer can't implement and govern anything better than what they have today, introducing SharePoint may be a bad solution for them until they can mature to the point where their culture can accept a SharePoint implementation.

Mapping Business Reference Architecture to SharePoint's Features

In this section, we'll discuss the process of moving from a Business Reference Architecture (RA) to selecting SharePoint's features for your environment. There are three main steps or efforts to this process:

• Understanding what a reference architecture is and the RA outlined below
• Building your own Business Architecture (BA) from the RA
• Mapping SharePoint's Features to your BA by understanding how SharePoint's features map to the RA

Understanding the Business Reference Architecture

Any reference architecture is merely a template for understanding and building an actual architecture. The RA is a way to understand what functions and processes in which a business could engage. The reference architecture can be treated like a checklist: compare what your business does with that which is presented in the RA and then build the BA for your business or organization. The RA is used to ensure that you don't miss any parts in building out your BA. The entire purpose in using the RA is to build out your own BA as a foundation to understanding which parts of SharePoint should and should not be used in your environment. Referring back to Figure 3-1, this is what we refer to as the development of the baseline of SharePoint features for your organization. Note that this is not the end-point in deciding what features you'll ultimately utilize in your business. The final decision (that will likely be revisited several times over the foreseeable future) will be determined based on the results of your architecture work (as described here) and the requirements of your strategic projects.

The use of the RA runs in parallel to the business and technical requirements work and acts as a throttle to impulsive decisions based on a single project. From a pace layering viewpoint, where different layers of a model flow at slower or faster paces than the other layers, you can think of the RA layer as being the slower layer whereas the business opportunities and problems layer is more agile and more responsive to customer and market demands. Both paces are necessary to the proper use of SharePoint's features.

For example, while you might turn on the document conversions services on your Web Front End (WFE) servers because you know that as an organization, you're moving toward the use of Web Content Management (WCM) services as part of your larger Enterprise Content Management (ECM) solution, you might find that a strategic project requires certain paths and jobs to be created for that project. Hence, at a RA/BA level, you decide to use WCM services and turn on the Document Conversion services, but then a strategic project requires that you have a set of enumerated job and paths created plus a second WFE server installed to load balance the document conversion demand anticipated for that project. Once the project is completed, you either re-purpose the server to other uses within the farm or you decommission the server. In this example, the "slower" pace is the decision to turn on the basic services required to provide the WCM environment. The "faster" pace is the development of the jobs and paths as well as the installation of a second WFE server to load balance the increased document conversion demand. Figure 3-2 illustrates a sample Business Reference Architecture. The architecture is presented with components of a business placed in logical groups. For example, the component of strategy is placed in the vision and mission group.

Figure 3-2: Business Reference Architecture

Every business and organization have certain characteristics in common. The RA is meant to visualize those characteristics, as follows:

Vision and Mission    This layer is exceedingly important to any organization who wishes to align the breadth of their resources toward a focused effort. Without tethering objectives, goals, strategies and measurements to the vision and mission, organizations can easily find themselves engaging in activities that might be profitable and good, but a distraction from the core mission and focus of the organization

Operations        This is an encompassing area that offers support of the organization's mission and vision. These support functions are necessary in order for the organization to survive and when mis-managed, can cause potentially fatal damage to the business.

Product Production    Not all businesses have products that they produce. Many are service-based businesses. Service based businesses will find their skills and knowledge development mapped to the operations area, whereas those businesses that produce physical products will have both skill and knowledge development for their staff as well as the production of their products.

Research and Development    All organizations need to understand their products and services better and make improvements to gain competitive advantages. Such improvement, from innovation to cash flows, requires research into knowledge bases, the development of new knowledge and the development of people, processes, skills and products in order to grow and ensure the organization survives in a competitive market.

Sales and Marketing        Marketing is concerned with communications to customers, partners, vendors and employees. Marketing helps shape public perceptions of the rand, skills and products of the organization. Sales is concerned with the transaction of the customer purchasing a service or product from the business. It is also concerned with customer relations and that area overlaps with marketing and customer service.

Business Data Management    Every business manages data and it is information that provides one of the most valuable assets of an organization. Even though the value of information does not appear on the balance sheet, nevertheless, it is important to call out as a distinct area in the RA. Those organizations who manage their information better than their competitors gain a competitive advantage.

Customer Service    This layer is concerned with ensuring the customers of an organization are delighted with the products and services of that organization. Without strong customer service, an organization will have negative "customer moments", which are unspoken impressions that customers form about the organization based on their interactions with the organization that are negative. Such moments tend to diminish the potentiality of the customer purchasing additional products and services from the organization.

Building Your Business Architecture

As we stated earlier in this chapter, the goal of using the RA is to build out your own Business Architecture so that you can better understand which features of SharePoint to utilize that will support the goals and objectives of your organization.

What we offer here is a method of comparing your business to the RA and then building out your own BA. That method consists of several steps:

1. Read through and understand the Business Reference Architecture. Be sure to understand the use of reference architectures more generally.
2. Consider each part of the RA and map your business to it. When mapping your business to the architecture, be sure to:
   1. Define if that part of the RA is included in your business or not
   2. If included, define the degree of importance that element plays in your business
3. Build your own business architecture (BA)
4. Map the features of SharePoint to your BA
5. Map other enterprise applications in your environment to your BA
6. Make decisions about consolidation, deployment or leave as-is

Mapping SharePoint's Feature Set to your Business Architecture

If one were to overlay SharePoint's features on the RA, one would find that the feature set does not map well to a BA. Also, a comprehensive list of SharePoint's features to work through would be time consuming and likely hold diminished returns for the time invested. Hence, we do believe that you'll end up mapping SharePoint's features to the BA, but that each organization's mappings will look different and contain a different approach. For example, one organization might emphasize the ECM features in SharePoint while another might emphasize workflows. More to the point, some might list workflows as a supporting feature in their BA while others might list workflows as a supported feature, the latter meaning that workflows is a key reason that SharePoint is being implemented and the other features of content types or lists are implemented only to support the workflows needed for the solution.

But the entire effort to develop your business architecture will be conducted in vain if you don't take the time to map your use of SharePoint's features to your BA. Doing so will provide the following benefits:

• Greatly reduce, if not eliminate, turf wars between teams within the larger information technology department as to the use and need for SharePoint
• Utilize a data-driven method of deciding which features in SharePoint should be utilized within the organization
• Communicate to business decision makers and non-technical influencers well-reasoned talking points on why SharePoint should be implemented and connect the software to strategic projects in a way that (perhaps) most other software platforms have not enjoyed in your environment

Adjusting SharePoint's Implementation to Specific Projects and Needs

The method that we have discussed thus far is a global method of mapping SharePoint's features to your business architecture. This model we are outlining in this chapter will allow for specific adjustments to the use of SharePoint's features for a given project or set of projects, as long as those projects support and further the vision, goals and strategies of the organization.

Such adjustments may mean starting new SharePoint services or not using services that have already been started. It may involve the installation of additional application servers whose lifecycle is tied to the life of the project the servers are supporting. But the larger point is that individual projects – especially strategic projects – should be allowed to further refine the deployment of SharePoint in your organization.

Deploying SharePoint with other Existing ECM Systems

Admittedly, this model assumes that SharePoint is being installed primarily as a supporting service for the enterprise and that other ECM systems that might currently exist are being clearly defined in their roles as SharePoint is introduced or expanded. In the majority of organizations, SharePoint is being installed into environments where other ECM systems are already in place and yet the managers of those systems are not being consulted or SharePoint is being installed in conflict with those systems.

We consider the installation of SharePoint into environments with existing ECM systems as a worst practice if such deployment is conducted in conflict to or without consultation of the other ECM systems that presently exist. Best practice is to ensure that you know where SharePoint starts and stops and that you know where the other ECM systems start and stop in your enterprise application architecture.

We also do not consider a full implementation of SharePoint to be a best practice unless the business requirements dictate a full implementation and other systems (especially ECM systems) have a clear articulation as to where they will start and stop within the enterprise application architecture. Mapping SharePoint's ECM features to your business needs and then developing a delta between the functions already covered by your ECM system and functions which are not is an important evaluation step as part of the process of your SharePoint implementation.

Figure 3-3 illustrates a sample analysis of SharePoint's ECM features support of an overall ECM reference architecture with attention to how those parts of the architecture are supported (or not) by other ECM systems as well. Performing this type of analysis will add further data to the decision on how and where SharePoint should be implemented within your environment.

Figure 3-3: Mapping SharePoint's Features to an ECM Reference Architecture

Comparing the results of an enterprise technology assessment as an overlay to the reference architecture allows you to see the strengths and challenges in your current implementations. This will inform you as to where your enterprise application architecture is strong and weak. For example, in those areas that have a heavy concentration of dots, such as the document management service in the sample shown on this slide, you'll find that this indicates an opportunity for application consolidation. The challenge, when consolidating, is to cover as many business requirements as possible with as few software platforms as possible at the lowest possible cost.

The absence of dots indicates that the organization lacks a robust technology solution and that might represent an opportunity for SharePoint to fulfill those needs as well.

Each dot on the overaly should correspond to a specific technology that is either implemented or has a planned implementation. Many software platforms, including SharePoint, will be able to meet the business requirements for many parts of the ECM architecture. This is not uncommon, since most software vendors spend considerable time and effort in understanding the needs of business and then writing their software to meet those needs. But not all software platforms are created equal across these different parts of the ECM architecture. For example, SharePoint may be best in class for collaboration, but only adequate for imaging and capture. So your evaluation should consider the quality of service of each software platform in each part of the ECM architecture as well as whether or not that platform has a solution for that part of the architecture. It's a matter of considering both breadth and depth for each software product.

The reference architecture can also be used to map the desired or "to be" state of technology usage for ECM. Starting with the baseline reference architecture, plot the desired technologies onto the diagram into the appropriate services. If you already have SharePoint deployed and in use, it is likely that the "as is" reference architecture has SharePoint plotted in many services and rated as "5 - best in class" or "4 – potential to be a standard". This analysis of the as-is and to-be reference architectures forms the basis for a technology roadmap, which further informs how you use and work with SharePoint in your environment.

Moving from Project to Best Practice

This is the stage at which SharePoint is being utilized for specific, perhaps strategic projects that support the overall direction and strategy of an organization. As SharePoint is utilized, people learn how to use its' features and over time, learn how to better adapt and refine those features to their day-to-day work environment. As inefficiencies are rooted out and replaced with better uses of the features, the organization learns how to use SharePoint better.

As a result, some practices in the use of SharePoint become solidified and, as we outlined in Chapter 1, those practices become best practices within that organization's use of SharePoint.

Summary

The Business strategy and goals need to be the organizing principle around which your SharePoint deployment pivots. The model presented in this chapter presents a method of starting with the vision and mission of the organization and how to connect the use of SharePoint to that vision and mission. This model could be utilized for any software platform: it is applied to SharePoint in this chapter.

Implementing this model is not for the faint of heart and will require considerable effort, time and attention. The rewards are high for those who assume a methodical approach to the utilization of this model. The overall model was not derived from any source on the internet, so the use of this model will necessarily be green-field in nature. The authors encourage those who utilize this model to blog about their experiences so that the community can learn and refine this model to be more effective in SharePoint deployments.