When approached with the opportunity to present a series of administrative and architectural topics for SharePoint 2010, I knew that I wanted to tackle the most important and complex hurdle first.  I come from the background of a Business Analyst and Consultant.  My job is to solve business problems using people and technology.   I learned very quickly, that a good Business Analyst tackles the tough business problems first in order to ensure that the technology will fulfill the desired solution.  When evaluating the needed set of skills for an architect in SharePoint 2010, I identified the new Service Application Architecture as the most important tool in the architect’s skill set.

Add on to the fact that this conference was scheduled during the Beta release of SharePoint 2010, and I had a serious challenge ahead of me.  Would my audience be filled with innovators and early adopters?  Would they be educated and knowledgeable about SharePoint, or would they be simply starting out on their SharePoint journey?

I will say that overall, my audiences were the kindest, most respectful audiences that I’ve ever presented to.  I even had some audience members that attended all three of my sessions.  You know who you are, and I am thankful.

Welcome

In this series of blog posts, I’m going to talk about the new Service Application Architecture in SharePoint 2010.  If you remember one thing from this series of posts, I want it to be this:

Service Applications in SharePoint 2010 are hierarchical and interdependent.

The objective of this series of blog posts is to examine the Service Application Architecture in SharePoint 2010.  The purpose of these posts is to educate SharePoint administrators and SharePoint architects and to provide visibility to business owners so that you may fully understand the scope of your SharePoint 2010 investment.  The mission is to deliver this material in a fun and exciting way, and the goal is to provide a complete and fulfilling storyline.

Setting Expectations

Before you continue your investment in this series, I’d like to set some expectations for you.  This is not going to be a series of posts filled with technical content.  If you would like to learn about the technical aspects of the individual Service Applications in SharePoint 2010, simply submit the name of a given Service Application to your favorite search engine, and have at it.

If you are an administrator, an architect, or a business owner, this post is for you.

PART 1 – THE HISTORY OF SHAREPOINT:  GROWTH PATTERNS

I’ve always been fascinated by history because there is so much we can learn and apply to our daily lives.  When looking towards the future, you will often find me referencing some aspect of history to support a claim, vision, or hypothesis.

Let’s begin with a little history on the growth patterns for SharePoint.   Each version of SharePoint has out-of-the-box (OOB) functionality, provides the ability for developers to tap into the object model (OM) and for 3^rd party vendors to build stable and supportable solutions that integrate with the framework.

I’m going to provide my perspective on the growth patterns for SharePoint releases over the years. I’ll start with SharePoint 2003.

SharePoint Portal Server 2003 and Windows SharePoint Services 2.0

The focus of SharePoint Portal Server 2003 was twofold.  First, Microsoft wanted to remove the bottleneck of centralized administration and push down the responsibility and accountability to the knowledge workers that worked closest to the content.  Second, since Microsoft was about to revolutionize the way we collaborated together, they needed a way to mitigate the risk of bringing a new technology into the workplace and forcing change upon everyone who used it.  In order to remove that barrier to entry, they provided a rich set of integration features within the Office 2003 suite that allowed us to be fully productive without even touching the portal via the browser.  Unfortunately, and this is a sore spot for me, many of these integration features weren’t widely adopted at the time.

Figure 1 below, depicts my perspective of the functionality provided by SharePoint Portal Server 2003.  In a general sense, I feel that there was a very small amount of out-of-the-box functionality available to end users.  We were limited in our abilities to configure out of the box Web Parts, lists, and libraries before we had to ask a developer to begin customizing a certain aspect of SharePoint.  Whether it be a custom theme or a custom template created by modifying the ONET.xml file, configuration quickly brought us to customization; whether we liked it or not.

On the other end of the spectrum, there were a very small number of 3^rd party vendors providing supportable extensions and solutions to SharePoint.  Enterprise Search and Disaster Recovery were common solutions available through 3^rd parties at the time.

In regard to the overall amount of functionality provided by SharePoint Portal Server 2003, the vision of the Enterprise Content Management (ECM) system wasn’t fully realized.  Functionality consisted solely of Document Management (DM) features, and saw limitations even in that space.

I believe that an iceberg is a perfect analogy to describe SharePoint functionality.  On top of the water is this glacial fragment of beauty.  Though it is eye catching and remarkable, in reality, only makes up a small portion of the overall iceberg.  Under this natural structure of beauty and time usually lies an exponentially larger portion of the iceberg that is hidden under the water.  This part is massive, overwhelming, and often deadly.  There is a common theme among every version of SharePoint.  Like the iceberg, the out-of-the-box features and functionalities that we know about are a fragment, just a small fraction of the true power, functionality and usability that SharePoint can actually provide.  Way too often, companies opt for custom built solutions without fully investigating the out-of-the-box capabilities and implementing a configurable solution. I would say that the ratio of out-of-the-box functionality that existed “above the water” (i.e. widely known) was 40%, in relation to the remaining 60% that existed “below the water,” or was not widely understood.

Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0

With the advent of Microsoft Office SharePoint Server (MOSS) 2007 and Windows SharePoint Services (WSS) 3.0, we were provided with a completely different experience than we had in SharePoint 2003.

Touching again on the goal of SharePoint, Microsoft focused a lot of its ECM efforts on downplaying the concept of “information management” and promoting the concept of the “knowledge worker.” Information management conjures up thoughts of static data, old reports, and cold, dusty server rooms.  The concept of a “knowledge worker” places the focus squarely on the individual, and how they can interact effectively with the data to deliver solutions that provide visibility to business owners and drive the direction of the business.  MOSS 2007 was purposefully designed to enable the knowledge worker to become more effective with the data, more efficient with the solutions they created, and more independent in their jobs.

With MOSS 2007, we see tremendous growth in the out-of-the-box functionality available to knowledge workers.  Figure 2 below depicts that many of the solutions that were custom developed to extend the out-of-the-box functionality of SharePoint 2003 were now baked right in to MOSS 2007 upon release.  Popular extensions provided by 3^rd party vendors seemed to overlap with Microsoft’s overall vision for SharePoint and were built into the out-of-the-box functionality as well.

At the same time, the ecosystem of 3^rd party SharePoint vendors also grew.  Existing 3^rd Party vendors grew their lone SharePoint extensions into a suite of solutions, and new opportunities for entry quickly made themselves available to those who wanted to get in on the action.  Adding to search and disaster recovery solutions, we saw 3^rd party vendors provide solutions and extensions for web parts, workflow, systems integration and migrations among others.

In keeping with the overall vision of establishing SharePoint as a best in class ECM solution, Microsoft not only improved the feature set for Document Management (DM) within SharePoint, they also added features for Records Management (RM) and Web Content Management (WCM).  These efforts solidified MOSS 2007 as a complete ECM solution.

When we look at the overall functionality available in MOSS 2007, we see that our iceberg has grown by leaps and bounds.  I often say that SharePoint grew by an order of magnitude (e.g. just like adding another zero to your paycheck).  Yes there were more out-of-the-box features with SharePoint 2007, but more importantly, the focus on knowledge workers and their ability to create and configure custom views of data using the Data View Web Part were instrumental in the way we saw SharePoint as a framework for solutions, rather than just an online storage medium.

Compared to SPS 2003 where (in my humble opinion) 40% of the functionality appeared to be available to the knowledge worker, in MOSS 2007, I would say that the functionality that was considered widely known, dropped to around 25%, while the amount of underutilized out-of-the-box functionality available to us grew to about 75%.

Microsoft SharePoint 2010 and Windows Foundation

I would hope by now, that you can see where I am going with all of this.  Here is my perspective on SharePoint 2010 and Windows Foundation.

Figure 3 below depicts that SharePoint 2010 and Windows Foundation has grown one step closer to Microsoft’s vision of SharePoint becoming the corporate standard for not only data storage and collaboration, but also the creation and deployment of services to support critical business problems for the knowledge worker.

Out-of-the-box Web Parts have grown, social media concepts including folksonomy tagging and the end user context are now paramount tenants of many of the available ECM features.  Integration with, and extension of the Office 2010 clients are also considered to be a foundational component to the knowledge worker’s tool set.  At the same time, 3^rd party vendors are becoming more specific with their solutions.  Charting, graphing, and mapping solutions are now widely available by 3^rd party vendors and are designed not only to extend SharePoint’s capabilities, but to enhance specific solutions created by knowledge workers that solve critical business problems.

When we reference our iceberg analogy for SharePoint 2010, we see again that SharePoint functionality has grown by leaps and bounds.  We also see that I don’t have enough space in my diagram to fully depict the overall size of the available functionality.  As of the initial authoring of this blog post, we are still discussing a Beta version of the product.  Though I will not claim to know the extent of which SharePoint functionality has grown over MOSS 2007, I can safely state that the potential for creativity and the opportunity for the knowledge worker to configure out-of-the-box solutions to solve critical business problems does in fact seem limitless.

In Conclusion

It is important that business owners, architects and administrators step back and take a big picture look at the history of SharePoint so that we can be informed as to where the technology will take us in the future.

Figure 4 below shares my personal view of how SharePoint has matured over the years in regards to features and functionality.  As I try to depict, there has been a continual reinvestment in the accuracy and visibility of data to business owners, along with a continual improvement in the knowledge worker’s ability to create configurable business solutions targeted towards solving critical business problems.

Meanwhile, over at the Legion of Doom!  Sorry, you know that I always have to include some sort of superhero reference in my blog posts. What I meant to say was, meanwhile, the ecosystem of 3^rd party vendors has taken full advantage of the open object model and framework, and has continually grown and fortified their solutions, release after release.

I want to make one thing clear about my perspective.  I am not a developer.  I am an architect, an administrator, and an evangelist for SharePoint.  At no point in this post have I stated openly or even made reference to the belief that development is being consumed by OOB functionality or 3^rd party developers.  I am not a developer, nor do I claim to play one on TV.  Sorry, bad joke.  Here is what I know about development in SharePoint 2010.  I know that Visual Studio is more GUI based than ever before.  I know that the SharePoint developers that I have greatly respected over the years have focused their development skill sets on very specific technologies within the development space; Silverlight and AJAX Web Part development to start.   Am I saying that development is dying?  No.  I simply believe that as a whole, business owners will look longer and harder than ever before at configurable out-of-the-box Web Parts to provide business solutions, prior to opting for a custom developed solution, or a 3^rd party solution for that matter.

The SharePoint Learning curve

Before I end Part 1 in this series of blog posts, I’d like to touch on one other nugget of wisdom that I have learned over the years of working with SharePoint.  There has been one constant with SharePoint.  As it has grown in functionality and purpose, everyone who wants to consider themselves an administrator, an architect, or an evangelist needs to start from the beginning and learn from the ground up.  These are new technologies that grow exponentially in every release.

I would like to take this opportunity to set the expectations for both you and your boss.  For every one thing you learn in SharePoint, you come to realize that there are now two additional things that you need to learn, that you didn’t know existed before. So, if we were to graph this over time, we would see that the learning curve for SharePoint might resemble Figure 4 below.  We would clearly conclude that as time goes on, we actually regress in knowledge and become “stupider” over time.

Welcome to the next 3 years of your education!

PART 1 – THE HISTORY OF SHAREPOINT: SERVICE DEPLOYMENT

I’ll now begin Part 2 of my series of blog posts on the Service Application architecture in SharePoint 2010.

As SharePoint has grown, so has Microsoft’s approach to enterprise service deployment.  This blog post serves as the 2^nd post in a series designed to educate SharePoint administrators, architects, and business owners on how to properly approach the new Service Application Architecture in SharePoint 2010.

Again, we are still providing the big picture here, so we will need to touch on the different releases of SharePoint to see how the deployment of enterprise services has changed over the years.

SharePoint Portal Server 2003

Let’s start our analysis by looking at the enterprise service architecture within SharePoint Portal Server 2003.

The Enterprise Service Architecture

With SharePoint Portal Server 2003, the SharePoint architect had only one service to deploy; Enterprise Search.  This service was associated to your portal at the farm level and was deployed with sort of a “light switch” approach.  This meant that you turned this service on or off for the entire portal.  Figure 6 depicts how simple the choice was.

Unfortunately just because something was simple, doesn’t automatically mean that it is easy to do.  What architects quickly learned was that the components of enterprise search were confusing to manage. Administrators had a limited amount of freedom in implementing this enterprise service correctly without adversely impacting the existing information taxonomy across your site architecture.

The Architect’s Skill set

It appeared as though the SharePoint architect’s skill set for deploying the enterprise service in SharePoint 2003 was very simplistic.  You have one enterprise service.  Do you want to turn it on or off, and how do you want to search for content across your organization?  With the limited amount of out-of-the-box flexibility in SPS and WSS site and area templates, and the limited number of out-of-the-box Web Parts per template, the portal and its services seemed to work against the architect’s best intentions in implementing a corporate SharePoint solution.

Microsoft Office SharePoint Server 2007

As Microsoft Office SharePoint Server (MOSS) 2007 was released, SharePoint architects soon learned that the deployment of enterprise services had changed drastically.  Let’s take a closer look.

The Enterprise Service Architecture

With the release of MOSS 2007, the overall features and functionalities available to us grew.  It was only logical that the enterprise service architecture not only grew, but adapted to meet the needs of the business as well.

One service becomes six services

From SharePoint Portal Server 2003 to Microsoft Office SharePoint Server 2007, the total number of Enterprise Services increased from one (1) to six (6).  Not only did the amount of services increase in scale, we were also introduced to the Shared Services Provider architecture and the Shared Services themselves.  The enterprise services now consisted of:

Enterprise Search

Audience Targeting

Profile Import & MySites

Excel Services

Reporting

Business Data Catalog

The Shared Services Provider architecture

The Shared Services Provider architecture modified the scope at which Shared Services interacted with your portal.  Enterprise services were no longer deployed at the farm level.  A new level of granularity gave architects the ability to consume enterprise services at the Web Application level.  This architecture is depicted in Figure 7 below.

The Shared Services architecture gave architects a “bargain bin” approach to enterprise service deployment.  You provisioned a single Shared Services Provider (i.e. another level of infrastructure), and you were given one instance of each service to configure and deploy.  If you only wanted to deploy enterprise search, your bargain bin also included Audience Targeting, Profile Import & MySites, Excel Services, Reporting, and the Business Data Catalog.

You didn’t have to deploy or configure the other services; you simply had them available to you for future provisioning.  If you wanted to deploy another instance of enterprise search, you’d create another Shared Services Provider, and you would receive another bargain bin containing the remaining 5 enterprise services.  These services had minor interdependencies, but by and large, you were free to deploy whatever services you wanted, and in whatever order you wanted.

The epidemic that existed

From my experience in educating hundreds of SharePoint administrators and architects over the years, the Shared Services Provider architecture was the one aspect of SharePoint that nobody seemed able to learn well enough.

The fact of the matter is, the Shared Services Provider architecture was the most important skill set any SharePoint architect or administrator needed to have in their SharePoint 2007 tool box.  There were very little directions and documentation surrounding the real-world implementation and proper deployment and configuration of the Shared Services Provider architecture, and I can’t tell you how many times I heard  SharePoint 2003 architects simply deem themselves SharePoint 2007 architects without educating themselves on this topic.

SSPs forced architects to focus on the business in order to get the architecture correct

The Shared Services Provider model was responsible for answering the question, “How do I know that my SharePoint implementation is deployed correctly across Web Applications and Site Collections, and how do I know that it will scale well into the future?”

First, Architects had to take a defensive stance in the deployment and configuration of Shared Services.   They were forced to look towards the business to find answers as to whether or not there were elevated or confidential materials, a politically energized atmosphere, a multi-tenant environment, or the requirement to separate unique business services from one another.  You started with a single Shared Services Provider deployment model, and you would only add another if you received a definitive business reason as to why it had to be so.

A defensive stance was required because deploying Shared Service Providers had a major impact on your SharePoint resources.   Every Shared Services provider that was deployed increased your administrator’s enterprise service support workload by 100%.

The Architect’s Skill set

Compared to the skill set required to deploy the enterprise search service in SharePoint Portal Server 2003, the skill set required for an Architect to appropriately deploy enterprise services in MOSS 2007 was drastically different.  The answer to support growth, stability, and scalability of the environment was much more process intensive to figure out.   Here is an example.

Figure 8 below depicts two distinct site architectures for Microsoft Office SharePoint Server 2007.  Please explain each architecture and then with the knowledge you’ve learned about Shared Services Providers, compare and contrast each site architecture as they pertain to the Shared Services Provider architecture.

Every SharePoint 2007 Architect should not only be able to answer this question, they should be able to discuss the explanation in business terms, and at length.

In order to answer this question, the architect needs to tap into a much bigger skill set.  You have to understand Web Applications, Site Collections, Content Databases and sizing, service level agreements, security, the enterprise search index and how to deploy multiple instances of that service.  You have to understand the multiple migration options into both architectures, and tap into the business’ view of the risks and rewards for each.  You even had to get into the mind of the business owner and find a way to apply a hierarchical site architecture (b) to a seemingly flat infrastructure (a).

My point is, the skill set required for the SharePoint 2007 architect is drastically different than the skill set required for the SharePoint 2003 architecture.  In order to be successful, you had to grow your general knowledge of SharePoint and focus more and more of your efforts on understanding the true needs of the business.

SharePoint 2010

With the release of SharePoint 2010, it is only fitting that the deployment of enterprise services change as well.

The Enterprise Service Architecture

Again, the overall features and functionalities of SharePoint grew by leaps and bounds over the previous release.  As expected, the deployment of enterprise services became much more complex and time intensive.

“Componentization”

With SharePoint 2010, we no longer have to deal with the “bargain bin” concept of Shared Services Providers and Shared Services.  The feedback to the SharePoint product team surrounding the Shared Services Provider infrastructure was received loud and clear.  “We don’t want to be constrained anymore.  We want to be free to scale our environments and deploy enterprise services as we see fit.”  This theme not only describes the deployment of enterprise services, it applies to many other aspects of SharePoint 2010 as well.

“Ask and ye shall receive.”  Microsoft’s response to this “cry of freedom” feedback was to break down the enterprise services into smaller components in order to achieve scalability and a higher granularity of control.  At the same time, Microsoft’s vision for SharePoint 2010 required them to promote many of their existing functionalities to the enterprise service level.  Hence the Service Application Architecture was born.

The Service Application Architecture

The Service Application architecture is the next iteration in Microsoft’s deployment of enterprise-level services for SharePoint 2010.  What were six (6) services in MOSS 2007 have now blossomed into sixteen (16) services in SharePoint 2010.  These are listed below:

Access Services

Application Discovery & Load Balancer

Business Data Connectivity

Enterprise Search

Excel Services

Fast Search

Managed Metadata

PerformancePoint

PowerPoint

Secure Store

Security Token

User Profiles

Visio Graphics

Web Analytics

Word Automation

Word Viewing

Figure 9 depicts my view of the Service Application Architecture as a set of interdependent and hierarchical services designed to work together to support critical business processes and scalable enterprise solutions.

Famous Last Words

I believe it was Peter Parker’s Uncle Ben, who said, “With great power, comes great responsibility.”  As SharePoint architects and administrators, we did our best to provide feedback to Microsoft as to what we wanted with the enterprise service deployment in SharePoint 2010.  We made it clear that in our feedback we did not want to be constrained in any way by services, “bargain bin” configurations, or scale.  We wanted limitless power, and we wanted to be left alone to do as we pleased.

Not to put too fine of a point on this subject, if you think about all the times in your life where you got what you wanted rather than what you needed, you may conclude that what you wanted wasn’t always the best thing for you at the time. Too often, there is a giant gap between what we think we want, and what we really need.  As a SharePoint architect, it is our responsibility to separate the wants of the business from the true needs of the business and deliver a solution that meets critical business objectives.  The big question that I identified in alpha, and will now pose publicly in Beta, is, “have we shot ourselves in the foot by asking for this type of service architecture?”  Only time will tell.  I look forward to revisiting this post in another 3 to 4 years to reflect on this perspective and answer this question.

Of course there were other factors that aided in the creation of the Service Application Architecture in SharePoint 2010.  In order to scale SharePoint in many areas, Microsoft had to do away with the constraints of the Shared Services Provider model and implement something much more flexible.  The bottom line is that the reality of a new enterprise service architecture is upon us, and it is the architect’s sole responsibility to become educated and improve their skill set in order to adequately deliver the right solution to the business.

A kid in a candy store

So we asked for the reigns to be lifted.  We weren’t content to learn about the business and play within the constraints of the Shared Services Provider model back in SharePoint 2007.  We had to run our big mouths and trade in our $5.00 / month allowance for an unlimited black American Express credit card.  We were then set loose inside a candy store so big, I’m at a loss for an adequate example to finish my analogy.

The fact of the matter is, the enterprise service architecture in SharePoint 2010 is more complex than ever before.  We are now required to learn nearly 3 times the amount of services. Since these services are now interdependent, we are not only required to learn about them individually, but we also need to learn how they interact with one another.

The purpose of the SharePoint architect is to provide the business with visibility into their true investment required to deploy and maintain a SharePoint 2010 implementation that will meet their critical business needs and support their critical business processes.

Because we are given an enterprise service deployment architecture that is so granular in scale and void of any constraints, all of the responsibility and accountability to correctly deploy enterprise services throughout our implementation will fall squarely upon the shoulders of the SharePoint architect.    This means that the only way for a SharePoint architect to succeed in their role is to not only become properly educated on the Service Application Architecture in SharePoint 2010, but to understand the true needs of the business and provide visibility into how those needs can be solved by implementing the correct set of service applications.

As you learn more about the individual Service Applications, you’ll come to realize that all this talk about ”scalability” is often achieved by adding additional hardware to support the many granular components of the individual servcies; and that costs the business money.  I believe that without the proper education, many SharePoint architects will find themselves learning on the job and at the same time, negatively impacting the business.  We wanted to be released from our constraints, and that translates directly to an increase in responsibility and accountability to make the right decisions.  If we make the wrong decisions in regards to the deployment of enterprise services in SharePoint 2010, if we deploy the wrong services or we deploy them in the wrong order, we will only be impacting the business and costing them time, money, and resources.

No checks and balances…No constraints this time… No safety net if we fail.

PART 3: SERVICE APPLICATION EDUCATION

If you know me, you know that I am not one to identify a problem without offering up a solution to go with it.  This is the final post in this series, and it is designed to provide an in-depth look into a unique perspective that I have created over months of education and real-world experience.  From a SharePoint perspective, I’m an architect, an administrator, an evangelist, a user group president, an international SharePoint conference board member, a speaker, an author, an instructor, and a consultant.  Everything I do supports the education of SharePoint.

After all of that background, I finally get down to discussing the Service Application architecture in SharePoint 2010.  Did I mention “Big Picture?”  I’ve spent the majority of my time with the early builds of SharePoint 2010 trying to understand the educational roadmap for SharePoint Architects to follow, as well as to determine the major challenges that many SharePoint Architects would have to not only face, but overcome in order to correctly deploy enterprise services in SharePoint 2010.

Why EVERYTHING we do at SharePoint Experts is based upon real-world experience

In my efforts to educate myself on the Service Application architecture within SharePoint 2010, I realized that in order to understand the big picture, I had to understand the individual parts.  This led me down the path of pulling information from Microsoft, TechNet, MVPs, whitepapers, conference sessions, blogs, and even the engineers on the teams who actually created these services.

My Motivation

There has been an incredible amount of effort put into the creation, deployment, and education of Service Applications in SharePoint 2010, and we are not even out of the Beta stage yet.    Through all of my research attempting to learn about the real-world application of Service Applications, I was unable to find the information that I needed.  Sure, there was a lot of technical information surrounding the individual Service Applications, but nothing concrete about the real-world application of the planning or implementation of the combined services as a whole.

I had identified a niche.  There was a gap in the SharePoint information spectrum and I wanted to fill it.  It took me months to design and create this perspective, but I believe that in the end, it could be a very important body of knowledge for every SharePoint 2010 architect to obtain.  This is the type of real-world education that I provide to my students in my SharePoint Planning and Administration Bootcamps, and I’m happy to share it with the SharePoint community now.

A high-level overview of Service Applications

We have to start somewhere, so let’s start at a high level.

The Service Application

For each Service Application that you deploy, you get three components to configure. The first component is the actual Service Application itself; often referred to as the “application”. This component can usually be described as an administration page that you will use to configure the service itself. If you were deploying the Enterprise Search Service Application, this page would point you to your Enterprise Search Administration dashboard. Everything you would need to do in order to configure the service itself will reside on this page.

The Service Application Connection (or Proxy)

Whenever you deploy a Service Application, you not only get the application, you also get a Service Application Connection (or Service Application Proxy). The Proxy is listed under the Application on the Manage Service Applications page in Central Administration. The Service Application Proxy handles all of the connectivity information to your environment so that the Service Application can run and communicate effectively within the environment. One item listed in the Service Application Connection is the Proxy Group that the Service Application will use to connect to the environment.

Proxy Groups

WAIT! I have to deal with a Proxy and a Proxy Group? This is getting confusing! Yes… sorry. Let me explain. Each Service Application interacts with your environment at the Web Application level. In order to provide the application’s service to your portal, you have to get paired up by a Proxy Group. I like to think of a Proxy Group as a matchmaker between Service Application Proxies and Web Applications. The Proxy Group is a very lightweight component that doesn’t include any configuration or modification. It is simply a grouping mechanism to manage the individual Web Applications and the Service Application Proxies that they consume.

Service Application Deployment scenarios

There are many variations in which to deploy Service Applications throughout your environment(s)

Deployed within a farm

The most common deployment scenario seen with Service Applications is when they are deployed within the scope of the farm. Whether it is production, test or development, each Service Application is specific to only one environment.

Deployed across farms

Most Service Applications can be configured for connectivity to other farms. The Service Application Proxy is made accessible, and a Service Application can publish its services to other farms. At the same time, Web Applications can consume services from Service Applications residing within other farms.

Deployed for farm consumption

In the most extreme cases, companies may find that their business call for them to balance and maintain multiple farms within the same environment. In this instance, SharePoint now allows for the provisioning of a Services Farm; a farm deployed strictly for the purpose of running Service Applications that are dedicated to supporting multiple farms. This is a very advanced concept, and only unique environments will require this configuration.

How to approach Service Applications from a real-world business perspective

There are so many Service Applications to learn about and to deploy, it can be hard to figure out where to begin. Here is my unique perspective on the Service Application architecture.  I hope that it is helpful to you.

Service Applications are interdependent

Through my own personal education on the Service Application Architecture in SharePoint 2010, I have learned that unlike previous iterations of SharePoint such as SharePoint Portal Server (SPS) 2003 and Microsoft Office SharePoint Server (MOSS) 2007, Service Applications in SharePoint 2010 are highly interdependent. This means that as Administrators, we are no longer able to simply deploy just one enterprise service.  Specific aspects of one Service Application may consume content from, or benefit from the configuration of one or more Service Applications. These dependencies add a new wrinkle in our Service Application architecture. As architects, we have to take these interdependencies into account prior to deploying any service applications within our environments.

Service Applications can be duplicated

To make the architecture and administration story a bit more convoluted, a single farm can provide duplicate (or multiple) instances of a Service Application that can be grouped within a single Proxy Group. In turn, each SharePoint farm and each Web Application within that farm can consume the services provided to it by multiple instances of the same Service Application.

I’m confused! How can I make sense of all of this?

If you are sensing confusion with Service Applications, remember that you are tackling one of the largest and most complicated changes in SharePoint 2010. Understanding the ins and outs of a single Service Application is very time consuming. Learning a little bit about each of the Service Applications is an extraordinary effort in and of itself. The goal here is to learn enough about each Service Application so that you can make yourself aware of interdependencies and the architectural implications of implementing each of the Service Applications available to you. This is the real challenge for everyone who wants to become a SharePoint 2010 Administrator or a SharePoint 2010 Architect.

The way I see the Service Application Architecture in SharePoint 2010

Through my own personal education in this area, I have created the following approach to understanding Service Applications in SharePoint 2010.  I hope you find this useful.

In order to make sense out of the many Service Applications available to us, I thought it might be beneficial to organize Service Applications into groups based upon dependencies. This way, we would be able to associate a priority to our Service Applications and apply some sort of logical direction in which to learn, configure, and deploy these applications throughout our environments.  Please note that as I learn more about the interdependencies of the service applicaitons, I’ll update these slides.

The Foundational Service Applications

I personally view the following service applications as “Foundational” service applications.

Application Discovery and Load Balancer Service Application

The Application Discovery and Load Balancer Service Application depicted in Figure 10 below is one of two Service Applications that come pre-configured and deployed upon installation of your farm. This Service Application is in charge of administrative tasks such as adding servers to the farm and the management and grouping of Service Applications across Web Applications. The load balancing refers to the management of requests to Service Applications throughout the farm. This service is sort of like air. We know it exists. We cannot see it. But we know we need it to survive.

Security Token Service Application

The Security Token Service Application depicted in Figure 11 below is the second of two Service Applications that come pre-configured and deployed upon installation of your farm. The Security Token Service Application is in charge of authenticating anyone or anything (e.g. a web service) to SharePoint. This Service Application acts as a broker for SharePoint and supports multiple authentication providers for both ASP.NET and Windows Communication Foundation-based applications. This is also a fundamental Service Application within SharePoint.

Secure Store Service Application

The Secure Store Service application depicted in Figure 12 below provides a single sign-on proxy capability that is used by other service applications to safely and securely connect to back-end data sources. Most notably, the Excel Services, Web Analytics, PerformancePoint, and Business Data Connectivity Service Applications all utilize the Secure Store Service Application in order to provide enterprise-class solutions within SharePoint.

Managed Metadata Service Application

The Managed Metadata Service Application depicted in Figure 13 below is considered a foundational Service Application because it allows you to create and store the information taxonomy you need to run many aspects of your business and your SharePoint environment. It not only supports the metadata in lists and document libraries, it also provides custom refiners for FAST Search, Term Sets for the user Profile Service Application, and reporting elements for the Visio Graphics Service Application. In fact, many of the other Service Applications benefit from a library or a pre-defined Information Taxonomy store.

The Structural Service Applications

With the foundational Service Applications deployed throughout your environment, it is important to focus on a subset of Service Applications that provide a “structural integrity” to the offering of enterprise-level services your business users will consume. Each of these Service Applications play a critical role in the overall presentation of services and service data presented to your end users. Without deploying these service applications, you are guaranteed to leave gaping holes in the structures of dependent Service Applications.

Office Web Application Service Application

Both the Word Viewing and PowerPoint Service Applications depicted in Figure 14 below fall under the identity of the Office Web Applications for SharePoint. The Office Web Applications provide pixel-perfect representations of office client applications using native browser objects such as Images, HTML and JavaScript. Word documents and Excel spreadsheets can be viewed in full fidelity, and PowerPoint presentations can be broadcasted openly to a URL for others to view. The Word Viewing and PowerPoint Service Applications are considered Structural service applications because they provide structural visibility into the Search service application to allow users to preview Word documents and PowerPoint presentation slides.

Excel Services Service Application

The Excel Services Service Application depicted in Figure 15 below elevates the Excel Workbook to a secure, performant, and scalable Business Intelligence platform for SharePoint. Excel Calculation Services’ ability to connect to external data sources requires elevated credentials to be configured within the Secure Store Service application. Additionally, Excel Calculation Services sets the foundation for another Service Application by the name of the Web Analytics Service Application.

User Profile Service Application

With the User Profile Service Application depicted in Figure 16 below, SharePoint Administrators are given a very high granularity of control over the import and configuration of the user profiles that will support the social networking aspects of SharePoint 2010. The User Profile Service Application is considered a structural service application. It sits on top of the Managed Metadata Service Application and utilizes it to maintain term sets of user properties.  It also provides the indexed profile properties to the Search Service Application for the social search experience.

Business Data Connectivity Service Application

The Business Data Connectivity Service Application depicted in Figure 17 below is the next iteration of Business Data Catalog functionality and establishes itself firmly as a structural service application. The Business Data Connectivity Service Application now allows for read and write connectivity to external data sources. The Business Data Connectivity service builds upon both the Security Token and Secure Store services to assist in the connection of external data. It also provides inputs to the PerformancePoint, Search, and Visio Graphics Service Applications.

The Functional Service Applications

Sitting on top of the Structural Service Applications are a host of Functional Service Applications. These Functional Service Applications are geared towards fulfilling a very specific business need or solving a very specific business problem. Some Functional Service Applications are deployed on their own without any dependencies to any other Service Applications. Other Functional Service Applications rely upon the Structural, and in some cases, the Foundational Service Applications in order to be fully deployed.

Word Automation Service Application

The Word Automation Service Application depicted in Figure 18 below can be deployed on its own without any dependencies to other Service Applications. Word Automation provides end users and business processes with the benefits of unattended, server-side, bulk document conversion into common formats such as .PDF and .XPS. It also establishes the ability for documents to be simultaneously co-authored.

Web Analytics Service Application

If you aren’t familiar with this Service Application, you may recognize it by other aliases. The Web Analytics Service Application depicted in Figure 19 below is also known as “Project Gemini” and is more commonly recognized as PowerPivot. PowerPivot is an extension of SQL Server and provides an in-memory calculation engine that sits on top of, and enhances PivotTable and reporting functionalities within Excel workbooks. The Web Analytics Service Application requires an unattended account to be created using the Secure Store service account,  Excel Services, and might even benefit from the Business Data Connectivity Service Application.

Access Services Service Application

The Access Services Service Application depicted in Figure 20 below enables organizations to create Access database solutions locally and then publish those databases as full fidelity SharePoint applications. Database tables become lists, macros generate aspects of workflows, and forms are displayed in the browser. The Access Services Service Application could require support from the Business Data Connectivity and Secure Store Service Applications.

PerformancePoint Service Application

The PerformancePoint Service Application depicted in Figure 21 below allows knowledge workers to build Business Intelligence dashboards from within SharePoint.  Information can be pulled from Excel spreadsheets, SQL reports, SharePoint lists, or 3rd party data sources. This Service Application is mostly dependent upon the Excel Services, Business Data Connectivity, and Managed Metadata Service Applications.

Search Service Service Application

There are two enterprise class options for implementing Search within SharePoint.  Enterprise Search and FAST Search for SharePoint are depicted in Figure 22 below. Both flavors of the Search Service Application are deeply reliant upon the Managed Metadata Service Application for indexing and relevance. Also very important to the Search Service Application is the User Profile Service Application for its ability to provide the baseline for social networking and deliver a customizable human component to your search experience.

Visio Graphics Service Application

The Visio Graphics Service Application depicted in Figure 23 below is the belle of the ball in this release of SharePoint. Visio Graphics Services allows business users to easily diagram and share Visio diagrams with other business users within SharePoint.  Diagrams are “smart” as they now have the capability to maintain themselves to reflect the most updated information from many different data sources including SharePoint lists. The Visio Graphics Service Application relies heavily upon the Managed Metadata Service Application for reporting and displaying the most up-to-date information pertaining to the diagram or process.

Choose Your Own Adventure…

So, with the knowledge applied that Service Applications in SharePoint are hierarchical and Interdependent, you have two options.  You can either choose to see conformity and structure as depicted in Figure 24.

Or you can choose to see complete chaos as depicted below in Figure 25.

In Conclusion

I’d like to conclude this series of blog posts with the following thoughts.

Choose Wisely

Even though the  Service Application deployment model in SharePoint 2010 may seem a bit chaotic at times, I challenge you to try and see things from a position of conformity and structure rather than chaos.  I hope that you choose to focus on the needs of the business in order to drive your implementation and deployment of services rather than following the wants of a few key individuals.

… But isn’t there more to the story?

Yes, there is… a lot more in fact.  We’ve touched on a high level technical overview of the subject. There is a lot more material that we could still uncover surrounding the individual Service Applications.  On top of that, there is education to obtain surrounding the real-world business application of these services.  I know what you are thinking…

“How do we go about gathering requirements for these services?”

“How do we begin to match critical business needs to the appropriate service applications and what solutions are we supposed to create?”

How should we go about communicating the appropriate solution to the business owners who are responsible for making those decisions?”

If you are interested in answering these questions, I’d like to encourage you to check out my SharePoint 2010 Planning and Administration Bootcamp from SharePoint Experts.  This entire series of blog posts equates to approximately 1.5 hours of my 40 hour class devoted to the Architectural and Administrative education of SharePoint 2010.  I hope this information helps you to feel more comfortable with your skill set and provides you with the confidence you’ve been looking for as you step lightly into SharePoint 2010 Architecture.

Thank you for the opportunity to contribute to the community.  I hope this series of blog posts was helpful to you, and I look forward to seeing you in class!

Matt Passannante
Director of Implementation Services
SharePoint Experts, Inc.

Part 5: My Proposed Solution

This is my final installment in this series. I have spent weeks discussing why SharePoint implementations fail, and it is time for me to provide you with my solution. Up until this point, I’ve explained that in order to implement SharePoint effectively, you MUST take a business-focused approach.

It is detrimental to implement SharePoint into your organization based solely upon a limited number of exciting features or functionalities. The most effective way to implement SharePoint into your organization is to evaluate the current state of the business as a whole (e.g. existing processes, requested improvements, collaborative needs) and implement SharePoint-based solutions to support and enhance those critical business processes.

You do not bring SharePoint into your organization because you want to utilize one or two features or functionalities for your personal or departmental gain. You bring SharePoint into your organization because you want to solve critical business problems throughout your entire organization.

The facts of the matter are as follows:

• For years, companies have been implementing SharePoint solutions without thinking of the business first. Real-world experience tells me that I should plot my course BEFORE I run my race.
  
• For years, the qualifications for playing the role of the SharePoint administrator have gone undocumented. Apparently all it takes is an employee’s enthusiasm to learn the technology combined with the business’ desire to launch the technology. Unfortunately, sometimes the business is unable to, or doesn’t recognize the need to hire qualified resources. We all know that just because you WANT TO BE a professional football player in the NFL, doesn’t mean that you WILL BE good at it.

For years, our SharePoint Implementations have been undersupported, understaffed, and ineffective in solving critical business problems. It is time to reset expectations for what is required to properly implement SharePoint within an organization.

My Proposed Solution: ADEQUATE Resources to Support the Implementation

I propose a team of individuals working together to “effectively bring SharePoint into the organization.” This team is made up of three very important roles:

For you business owners out there, I’ve created a visual diagram to communicate the distribution of skill sets that I believe are required for the SharePoint team members. For each role, a series of skill sets are represented as 3-D blocks. The depth and breadth of that team member’s skill set will be represented by the length and width of the block.

Each of these individuals will have a specific focus within the SharePoint arena, yet they will work together as a team to “effectively bring SharePoint into the Organization.” The days of a single SharePoint administrator tasked with carrying the unattainable expectations of the business on their back must come to an end.

In Conclusion

This is the solution I am proposing. If you know me, you know that I am a very passionate person when it comes to SharePoint. I am so passionate about this message, that you will see me support it in every classroom I teach, and every presentation that I deliver. We have suffered too long from inadequate resources to support our implementations. It is time for all of us to make a change.

Thank you very much for taking the time to read my blog posts on this topic. Please visit the SharePoint Bootcamp website to learn more about me, my training, and my company

Matt

I’m so excited; I just had to post this topic to my blog.  I’ll be teaching my SharePoint Planning and Administration Bootcamp publicly in Anaheim, California in two weeks (from April 27^th to May 1^st). SharePoint Experts has been to Anaheim before, but never like this.  Class will be held at Disney’s Paradise Pier hotel.  That’s right!  We are in the park! 

Over the past few months, I’ve been working diligently to update my class materials, and have rewritten the foundation of the class to cover Windows Server 2008. I’ve also produced a lot of new material surrounding performance and optimization of SharePoint.  On top of that, I’ve got another year of exciting real-world experience to share.  If you’ve paid close attention to my blog, or have seen me speak at a conference as of late, you know that planning SharePoint is still my bread and butter, and is taken very seriously in my class.

• If you are an Administrator, and you want to solidify your SharePoint Administration skill set, this class is for you. 
• If you are a Business Owner, and you want to see the big picture perspective, I'll show you. 
• If you are an Architect, and you need to design your implementation properly, you’ll learn it here.
• If you happen to play ALL of these roles, this class definitely for you!  Sign up now!

While in Anaheim, I’ll be teaching alongside Dustin Miller and Heather Solomon.  Dustin will be teaching the Original SharePoint Bootcamp, and Heather will be teaching the SharePoint Branding Bootcamp. 

To find out more, or to sign up, visit http://www.SharePointBootcamp.com.

See you in Anaheim!

Matt

If you are familiar with my style of presentation, you know that I focus on the business first, and take the extra steps necessary to make the audience as comfortable and entertained as possible throughout the session!  A SharePoint Experts presentation wouldn’t be complete without additional bonus content provided to you via my blog.  Here it is!

For those of you who attended my sessions at the Summit, I’d like to take this opportunity to personally thank you.  If you found my real-world experience to be of benefit, and are interested in applying the lessons you've learned to your own implementations, I’ve posted the bonus session materials below:

Session 1.2 – MOSS 2007 Deployment Planning:
Maximizing User Adoption Through Proper Information Architecture
References found here.

Session 7.1 – MOSS 2007 Deployment Planning:”
Planning Your Intranet Solution Around Your Business
References found here.

Thank you for the opportunity to contribute to to the SharePoint community!

Matt

Part4: “SharePoint Administrators are NOT Superheroes!”

I really want to emphasize the outlandish expectations that the business has historically held for SharePoint Administrators.

A Business Analyst:

As a SharePoint Administrator, you may be asked to take on the role of a Business Analyst by planning your implementation. This means gathering requirements for feature specific functionality. You have to be able to look at a business problem, and propose a solution using a specific technology. You also need to be able to create and deliver professional looking documentation such as proposals, project plans, presentations, and often training material. Most likely, you’ll be asked to facilitate meetings with Business Owners in order to present that material.

A Solutions Developer:

As a SharePoint Administrator, you may be asked to take on the role of a Solutions Developer when growing your SharePoint implementation. This would entail the understanding of the roles played by the current applications within your organization. You may be asked to evaluate an existing set of applications for a possible integration into SharePoint.

A SharePoint Architect:

As a SharePoint Administrator, you may be asked to take on the role of an Architect when planning your implementation. This may involve the knowledge to properly define the logical topology of your SharePoint Implementation. Planning the appropriate Sites, Site Collections, Web Applications, and Shared Services Providers with an eye towards the big picture will allow you to evaluate the future effects of decisions made today. This will be extremely important in your success as a SharePoint Administrator, because often times, it is your recommendation that gets implemented.

A Hardware Administrator

As a SharePoint Administrator, you may be asked to take on the role of a Hardware Administrator when building out your implementation. Though you may or may not be the one ordering the hardware, or even setting it up, it is important to understand the hardware options to support your implementation. You have to understand the SharePoint server roles, and the opportunity costs associated with selecting specific chipset architectures and other hardware components such as memory, disc space, and storage.

A Security Administrator

As a SharePoint Administrator, you may be asked to take on the role of a Security Administrator when setting up and installing your implementation. You’ll need to understand how SharePoint secures information at the farm, site collection, site, list, and item level. Depending upon the complexity or scope of your implementation, you may need to understand the different security protocols and possible risks within your network. You may need to institute multiple authentication methods across your implementation and interface with multiple back-end credential stores.

A Network Administrator

As a SharePoint Administrator, you may be asked to take on the role of a Network Administrator when planning your implementation. You may be the one called upon to suggest an appropriate server topology to support your implementation. When you get beyond the single box, or sandbox implementation, you’ll need to learn about intranet, extranet, and internet options. You’ll need to understand DMZ configurations and additional hardware components that interface with, and protect your implementation. You’ll need to learn how to setup and even troubleshoot network connectivity issues. This can be a tall task for anyone new to network administration.

A Database Administrator

As a SharePoint Administrator, you may be asked to take on the role of a Database Administrator. You may have to understand proper SQL Server setup and disc configuration. You could be responsible for the backup and restore processes, and the evaluation of database logs and performance tuning. In the event of a disaster, you need to have the processes in place to recover your data within predefined service-level agreements.

A .NET Developer

As a SharePoint Administrator, you may be asked to take on the role of a .NET developer. In many cases, you may not be the one doing the development, but it is important that you understand what functionality is available out of the box, what is configurable through the UI, and what would have to be developed using the object model. You’ll need to understand when to deploy features , a custom web part, or a custom configuration.

A SharePoint Evangelist

As a SharePoint Administrator, you may be asked to take on the role of an Evangelist throughout the lifespan of your implementation. You’ll be challenged with the task of evangelizing the capabilities of MOSS 2007 throughout your organization. You’ll need to be able to handle a multitude of technical and non-technical questions about your SharePoint implementation. You’ll need to understand available features and functionalities, and communicate effectively to all types of personalities. As an evangelist, you may be asked to assist in gathering requirements, leading training sessions, ensuring governance practices are followed, or providing demos. You’ll also need to understand the current status of your implementation.

Ok… take a breath. What you just read were 9 separate roles that when combined, commonly equate to the SharePoint Administrator’s role.

It is overwhelming.

It is daunting.

For 99% of SharePoint Administrators out there, it is unattainable.

Because the title of our role has the word “Administrator” at the end of it, the business often looks at SharePoint Administrators and sees the glass half empty. “If the portal is down, you’d better understand why it is down, and you’d better know how to fix it. If the portal is up, you’d better be available to handle anything we can throw at you.” It may sound harsh, but many SharePoint Administrators feel this way towards the business they serve. We walk around with this badge… or shield… or curse that reminds us somehow, we need to dawn a cape and save the world when the business is in distress.

I’ve been on this Super hero kick as of late, so please allow me to indulge myself. If you’re old school, then you know that even the Green Lantern, who held power; limited only by the imagination, was powerless against something so simple as the color Yellow! If you consider yourself new school, you’ve read Alan Moore’s WATCHMEN and you know that even if superheroes did exist, they’d just be ordinary people, with ordinary problems, and our lives wouldn’t have turned out any better or worse than they already did.

Note to Alan Moore: Please do not be offended by Matt Passannante’s one sentence description of one of the greatest texts ever written by man.

SharePoint Administrators are NOT superheroes!  Superheroes do not exist.

The business has to stop seeing the SharePoint administrator role as an endless well of expectations and abilities. At the same time, SharePoint administrators need to understand their limits and work effectively within them.

This has been a very intense series of posts for me to author. I promise that my next post in this series will offer up a solution and level-set expectations for both Administrators and Business Owners.

Thank you for reading.

Matt

Part 3: “I really don’t remember signing up for this.”

Depending upon a multitude of factors such as your company’s size, your outlook on training, your boss’ outlook on training, your technical background, the scope of the implementation, and of course the timeline and available budget , the requirements to effectively bring SharePoint into the organization can be drastically different from one implementation to another.

Most of the SharePoint Administrators that I have spoken with describe the business’ perspective as, “You are the SharePoint Administrator. If we have a problem with SharePoint, we are coming to you.” This makes sense right? If you have a problem with your paycheck, you go to Finance. If you have a question about your benefits, you go to Human Resources. It just makes sense that if you have a question about SharePoint, you go to the SharePoint Administrator. Right? Keep reading please.

In the examples above, you are bringing your problems to a member of a department, and not an individual. If you have a payroll issue, you will more than likely be transferred to a payroll specialist. Often times, the subject of your query is handled by a separate entity or company altogether. Within a single department (e.g. HR), you might have a Benefits Coordinator, a Personnel Manager, and an Employee Relations Manager. Depending upon the size of your company, you might even have a Vice President to oversee all of these roles. Where a department can have multiple resources; each focusing on a specialized aspect of that function, your SharePoint implementation often has only one person to handle all of the questions thrown at them.

If you haven’t figured it out yet, a large majority of people in the SharePoint administrator role are suffocating under the ridiculous expectations and crushing responsibilities involved in their daily activities. I am NOT proposing that SharePoint become its own division within your company. I am simply making the point that our SharePoint implementations need more than just a SharePoint administrator. Let me prove my point. We all love tests, right? Let’s take one now. No cheating and eyes on your own paper. Begin!

If you have the ability to answer each of these questions, in great detail, and without hesitation, then congratulations, you are in what I like to call, “The 1% club.” Here is the key to your locker. Your member’s jacket is hanging in the foyer.

For the other 99% of the SharePoint administration community out there who were not able to answer each of these questions fully and with confidence, DO NOT feel bad. In my experience, the 1% club is filled with a select few individuals who have dedicated their careers to SharePoint administration.

The problem is that these are all “introductory” or “leading” questions for a SharePoint administrator. The subject matter in the test above was derived in under a minute and represents some of the most common questions posed to SharePoint administrators on a daily basis. Each question in the test represents a different background or technical foundation. Your first response is to think, “Oh, those are easy questions. Any SharePoint admin should be able to answer that.”

If you are a business owner, and you truly feel that way about the SharePoint administrator’s role, then let us look at the test again and uncover the real expectations.

By not defining the role of the SharePoint Administrator, the business has come to expect that a SharePoint Administrator should carry each of these skill sets. It is my opinion, that the following picture accurately represents the real-world expectations of the SharePoint Administrator.

Unfortunately (and I am truly saddened to say this), I think there comes a time in every SharePoint administrator’s career, when they realize that this is the expectation that has been placed upon them, and they have to make a decision about their career. In my heart, I feel that there is something very wrong with this picture. How do you feel about it?

Stay tuned for my next post in this series as I will be discussing each of these expectations in more detail. After that, I will be proposing my solution to fix this. On a more personal note, I know that your time is precious, and I want you to know that I appreciate you reading the posts in my blog.

Thank you,

Matt

of my series titled Inadequate Resources to Support the Implementation, I spoke about the ease of entry into the role of the SharePoint Administrator. Way too often, it is on a whim or in passing that someone is asked to “dabble” in the setup or site provisioning of SharePoint. Little did we know, sometime over the next year of our lives, we’d be asked to pose for the cover of Van Halen’s 5150

In Part 2 of this series, we uncover the giant pink elephant in the room that everyone seems to be so reluctant to confront.

Part 2: The oversight we’ve been paying for all these years

I had mentioned previously that SharePoint Administrators originated from some very diverse backgrounds. In the past year alone, I have taught SharePoint Administrators whose backgrounds (i.e. roles held prior to becoming a SharePoint Administrator) were as follows:

Account Manager

Administrative Assistant

Application Developer

Business Analyst

College Graduate with a Degree in Horticulture
… Seriously!

CRM Administrator

Database Administrator

Executive Administrative Assistant

Information Manager

IT Consultant

IT Administrator

IT Manager

IT Support Consultant

Junior Analyst

Marketing Assistant

Network Administrative Assistant

PBX Operator
… Yeah! The phone guy!

Project Manager

Sales Manager

Senior Account Executive

Senior Analyst

Senior Consultant

Senior Technologist

Solutions Developer

Systems Administrator

Technical Intern
… Very Secure!

Tier 1 Support Specialist

Tier 2 Support Specialist

…Isn’t this starting to feel like an infomercial on the Jerry Springer show?
“In two quick years, you can train to be an…”

SAP Manager

Securities Admin

Security Manager

Server Administrator

Vice President

Web Designer

Web Services Developer

… and more.

WOW! That is quite an exhaustive list, huh? It was only within the past few years that I started keeping track. Doesn’t it seem a little odd, that almost anyone and everyone is being asked to play the role of a SharePoint Administrator these days? This isn’t anything new. From what I can tell, this has been the norm since SharePoint’s inception.

I believe that this diversity in experience is an assisting factor as to why so many SharePoint implementations are failing to reach their potential within their organization. In the grandest of senses, we are taking the most important information throughout the company and hosting it centrally for everyone to access. Depending upon your background, experience, skill set and your thought process on how best to accomplish this, the road required to complete this task can be drastically different than someone else’s. This isn’t a bad thing… In fact, it is almost expected. The problem occurs, when you ask each of these people to play the role that has never been defined in the first place.

Double doors open. Enter Pink Elephant.

The SharePoint Administrator’s Role

OK, so there is a pink elephant in the back of the room. Is anyone going to acknowledge it? No? Ok. I’ll take the leap of faith here and say something that will probably frustrate a lot of people. I’m saying this because it needs to be said. We need to deal with it, solve it and move on. Here it goes.

“The SharePoint Administrator’s role has never been clearly defined.”

Did someone mention a pink elephant standing in the back of the room? I don’t see him anymore.

It is easy to find a definition of a SharePoint administrator’s role in any book out on the shelf today. Ask any SharePoint administrator whether or not that definition fits their current role, and I’m betting you’d be hard-pressed to hear a positive response. The definition in the book often serves more to scope the chapters of the book, than it does to actually define what the role actually requires.

Don’t get me wrong, there are some seriously talented people in our SharePoint community. MAD PROPS to Shane, Todd, and Steve for creating a quality resource that should stand the test of time for many administrators!

From a real-world perspective (and at SharePoint Experts, EVERYTHING we do is based upon our real-world perspective), the term “SharePoint Administrator” is not simply:

“…a technical resource responsible for keeping the SharePoint environment up and running”

Over time, the role has morphed into:

“…You are the person responsible for effectively bringing SharePoint into the organization”

The lack of definition surrounding the role, and the impossible expectations demanded by the business has truly diluted our identity as SharePoint administrators. Until we can fully understand the root cause of the problem (which we will discuss later in this series) and we can identify a plan outlining the role of the SharePoint Administrator (which again… we will), SharePoint implementations run an exponentially higher risk for failure due to the expectations of the business and the inadequacies of the person playing the role of the SharePoint administrator.

Stay tuned for my next blog post in this series as I will uncover these seemingly impossible expectations that most businesses have for their SharePoint Administrators.

Matt

Hello everyone! 

Here at SharePoint Experts, we are expanding our training offerings in some new and very exciting ways!  Starting the week of February 9th, we are hosting five Three Hour Tours highlighting popular SharePoint topics such as…

The Data View Web Part: Deep Dive! – Learn more
February 9, 2009, 1:00 PM – 4:00PM CST

SharePoint Features: What's the Big Deal? – Learn more
February 10, 2009, 1:00 PM – 4:00PM CST

Brand It!: SharePoint Branding, from Start to Finish – Learn More
February 11, 2009, 1:00 PM – 4:00PM CST

InfoPath and SharePoint: A Primer – Learn More
February 12, 2009, 1:00 PM – 4:00PM CST

(If you enjoy the content that I’ve published to this blog, you’ll want to sign up for…)

SharePoint Planning: The Business Comes First – Learn More
February 13, 2009, 1:00 PM – 4:00PM CST

Business analysts and SharePoint administrators alike should attend this session to get a deeper understanding of how various SharePoint features map to common business requirements. Matt Passannante will help you to discover the importance of considering the business first when planning your SharePoint implementation.

Learn how to:

• Perform business stakeholder interviews to objectively determine business needs and requirements
• Plan administrative duties and server topologies based on real business requirements and not just "nice to have" meetings
• Determine the true ROI of a successfully planned SharePoint implementation

In this 3 hour session, Matt will cover key planning concepts specific to SharePoint Implementations.  He will walk you through an interactive planning roadmap that will allow you to plan for your specific implementation.  Whether you are an Administrator or a Business Owner, you will walk away with the tools and confidence needed to properly plan your environment.   

Also, be sure to sign up for our mailing list for future online exclusives.

Hope to see you there!

Matt

“Here is the answer. A company with a SharePoint implementation employs this type of resource.”

If your answer is “A SharePoint Administrator,” you are incorrect!

If your answer is “What is. a SharePoint Administrator,” you are correct.

If you were playing as Sean Connery, we would have also accepted:

(In classic Connery voice) “Your Mother, Trebek! Ha Ha Ha HA HA HAAAA!”

Chances are, if you have a SharePoint implementation in place within your organization, you have someone on staff playing the role of the SharePoint administrator. Let’s get serious and talk about the role of your SharePoint Administrator for a little bit.

The Beginning Of The End

I am the Director of Implementation Services and the author and instructor of the SharePoint Planning & Administration Bootcamp for SharePoint Experts. I train 100’s of SharePoint administrators each year. This is a very diverse group of people, coming from a very diverse background. Most people that I’ve educated about this role, never even planned on being a SharePoint Administrator in the first place.

In every public class I teach, I have a discussion with my students about how they became a SharePoint Administrator. Without fail, the following interaction takes place:

(Me in my teaching voice): “So you show up to work one day, and you’re doing your job. Maybe you are a business analyst and you are working on a project plan. Maybe you are in support and you are working on an open case or two. Maybe you are a systems administrator and you are going through some logs to check for any issues that arose over the last shift. All of a sudden, you receive a tap on your shoulder. You turn around, and it is your boss.

“Hello There. How are you today?” your boss says calmly.

“I’m fine,” you respond.

“Listen, we’d like to move forward with a new technology called Microsoft SharePoint. We are looking for someone to champion this effort for us. Anyway, we were all sitting around in the conference room, thinking about who could help us, and your name came up. I know that what you are currently working on is very important, but we just want to get a SharePoint site up and running here within the next few days. Do you think you would be able to help us out? I promise that this won’t take more than 10% of your time, and I also promise that it won’t go into production.”

At this point, your boss is staring you down and focused intensely on your eyes. The thought that you are currently 110% allocated to your existing role is exploding inside of your head, yet your desire to portray a team player makes you crack a smile as you say, “Sure. That sounds fine. I’ll look into it.”

Depending upon your boss’ level of excitement, you might even hear this closing statement. “Thank you. We really appreciate it! Why don’t you head to the bookstore during your lunch break and buy a book on SharePoint. I’ll even make sure you can expense it!”

Now, before I go any further, I need to let you know that it is at this point in the class, that I pause to look at my students in the classroom. Without fail, the room is silent. The student’s faces are filled with dismay as it appears I’ve just shared the contents of their childhood diaries. I say in a stern and passionate voice, “If this has happened to you, please raise your hand!“  Time after time, an overwhelming majority of students raise their hands.

“Look around.” I say calmly.

As they look around the room, they begin to cringe and even chuckle. They suddenly experience what I like to call, Band-Geek Syndrome (BGS) or Theatre Geek Syndrome (TGS).

Just like band geeks or theatre geeks in school, we all saw ourselves as outcasts at one time or another until the day we picked up that instrument or took to the stage and found our calling. Some of us even went so far as to win a National Championship Percussion Title! …but I digress.

See, SharePoint Administrators are just like band geeks or theatre geeks. Historically, the SharePoint administrator role has been one of isolation. There has really never been a clear cut direction for the role of a SharePoint Administrator, and we often feel lost or confused about our education, expectations, and activities. The moment we find out that there are other people who have had similar experiences along their road to becoming a SharePoint Administrator (however crazy and outlandish their road may seem), we find great comfort in our historic similarities and our confidence-level skyrockets.

It is such an immense relief to know, “Hey. I’m not crazy. I’ve been banging my head against this stuff like everyone else!” Once you accept this realization, your road to understanding the role of the SharePoint administrator becomes much more manageable.

The question I have for you is, “Am I preaching to the Choir?”

Stay tuned as we continue to investigate the role of the SharePoint Administrator.  I might just change your perspective as we uncover why and how this role needs to change.

Click here to continue on to Part 2 in this series of blog posts

Matt 

I believe that most SharePoint implementations failto meet their true potential) due to a series of pitfalls. From my real-world experience, some of the most common causes for a failed SharePoint implementation orbit around the following:

• Inadequate resources to support the implementation
• A lack of planning
• Improper expectations as to SharePoint’s role within the business

I am not one to simply point out a problem without also providing supporting details around a solution. This blog doesn’t simply complain about a problem. It offers a solution as well. Through a series of blog posts on the topic of why SharePoint implementations fail to meet their true potential, I’ll be explaining common pitfalls, discussing real-world history, and explain the impacts these pitfalls can have within an organization’s SharePoint implementation.

From here on out, I’ll try to explain things from the perspectives of both the SharePoint administrator, as well as a business owner. Finally, I’ll provide possible avenues for improving upon these pitfalls and provide guidance as to how these problems can be avoided in the future.

Click here to read the next post in this series.

Stay tuned!