I just returned from SharePoint Technology Conference in San Francisco, where I delivered three sessions. I owe a very warm and heartfelt thank you to Chairman David Rubinstein and Conference Manager Kathy Bruin for not only providing me with the wonderful opportunity to speak, but having enough faith in me to deliver multiple sessions year after year. I am forever grateful for them for giving me these opportunities. I hope to support their conference year after year.
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 3rd 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 3rd party vendors providing supportable extensions and solutions to SharePoint. Enterprise Search and Disaster Recovery were common solutions available through 3rd 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 3rd 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 3rd party SharePoint vendors also grew. Existing 3rd 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 3rd 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, 3rd party vendors are becoming more specific with their solutions. Charting, graphing, and mapping solutions are now widely available by 3rd 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 3rd 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 3rd 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 3rd 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 2nd 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.
mpassannante
ummm….WOW!
Thanks so much Matt,
Thank you very much Matt. I am still digesting as well as trying to figure out which is my favorite part. I really like the visuals but I think the following is my fav:
“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.”
Thank you very much!
Best 2010 post I have seen and I was going to write something very similar but now don’t have to. Awesome work