Let’s discuss some of these hybrid experiences in more detail.

Hybrid OneDrive and Profiles

Hybrid OneDrive refers to the ability to choose where each user has their work-related private files stored, in the cloud or on-premises. As you’ll see with other experiences, it isn’t an all or nothing choice. With SharePoint Server 2016, I can easily define audiences and put users in those audiences and specify where I want their OneDrive for Business to be created. For example, I may not want my factory workers to need an Office 365 license, they produce few documents, but I still want a secure place for them to put those files. I can specify that factory workers’ OneDrive for Business will be on-premises while everyone else gets one created in Office 365. While everyone else enjoys a 1 TB storage quota, I can specify something much lower for my factory workers and not have to spend extra money on storage.

Similarly, for profiles, using redirection in SharePoint Server 2016 enables some users to have a new enhanced profile experience in Office 365. The new profile experience features a selectable cover photo, 1-click message button (which opens a Skype for Business conversation), and as you’d expect, basic contact information and an interactive organization chart.

Hybrid Team Sites

Hybrid Team Sites refers to the ability to choose where to host collaborative sites and isn’t limited to just the “Team Site” template. It equally applies to other templates like Project Site, Developer Site, and Blogs. With the SharePoint Server 2016, the “Sites” page keeps track of all your sites, regardless of where they’re hosted or which template they use. You can choose to follow sites where you have an interest and quickly see recent sites and recommended sites.

For example, based on some regulatory requirements, some sites may need to be hosted on-premises. We can easily create a site provisioning form to ask the appropriate questions and determine if a site needs to be hosted on-premises.

There may be other cases where Office 365 is a better fit. For example, consider Access Services. While it is powerful because it allows information workers to create compelling apps, it is difficult to setup and maintain on-premises. If you wanted to avoid the headaches, you could simply host sites using Access Services in Office 365.

Hybrid Social

SharePoint Server 2013 was the “social” release with new features like communities, blogs, newsfeeds, hashtags, and more. SharePoint Server 2016 retains all of those features and makes it easy to leverage services from Office 365, like Yammer. As with SharePoint Server 2013, you can use Yammer embed to place a social feed on any site or page. You can do this easily and automatically using publicly available code for Provisioning Yammer feeds.

Perhaps Yammer isn’t suitable for all of your content. SharePoint Communities offer a different approach, based on patterns of traditional message boards. Hybrid Social means you can use the best of both worlds.

Hybrid Discovery

Hybrid Discovery is the term I’m using to refer to any feature that relates to finding information, on-premises or online. First, we have true hybrid search experiences. With SharePoint Server 2016, you can configure your search indexes to be hosted in the cloud, merged with your online indexes. This means that relevancy, analytics and results are inclusive.

Second, eDiscovery can now look at your entire corpus of content as one. A single search gives results from both on-premises and online. This is especially useful in scenarios where your eDiscovery search is focused on a user or set of users who may have content spread across locations.

Third, you can now bring the power of the Office Graph and specifically Delve to your on-premises content. Delve shows me popular documents, what my teammates are working on, related content and surfaces content that I might find interesting. I want, no I need, that information for content on-premises equally as much as the content that’s online.

There’s More

I only touched on a few of the scenarios where SharePoint Server 2016 unlocks business value through hybrid experiences. There’s more, and I’m sure you’ll see information coming soon or have a chance to explore yourself. Hybrid experiences are really compelling, that’s why the SharePoint 2016 Product Line Architecture (PLA) is a hybrid architecture. The PLA takes the best of Microsoft’s learnings from the cloud, projects with customers, Premier and broad support and repeated consulting engagements to come up with a reference architecture. Find out more by contacting your Microsoft representative and by visiting the PLA blog.

Previews and Online Viewing

This one is an old trick but still, so useful. When you integrate SharePoint Server 2016 and Office Online Server, you get rich online viewing and editing of your Office files. Browser-based viewing and editing is useful in situations where the Office client is not installed but also when you just don’t need to download the entire document. And the “Online” versions are powerful, you can do the most common tasks right there in the browser. Just as an example, with PowerPoint Online I can modify my font, its size, colors, insert shapes, insert pictures, create SmartArt, hyperlinks, insert video, apply a slide design, and even apply the most common transitions and animations.

In addition, you get previews inside document libraries and with your search results, as shown below.

Durable Links

Senior Product Marketing Manager, Bill Baer, wrote an excellent article on Durable Links several months ago. In summary, SharePoint provides an identifier for Office documents rather than using its name. This means you can rename your files and even move them around within your Site Collection, and the link will continue to work.

This is really useful. Consider you keep “draft” documents in a separate document library or subsite before they’re final. The file could undergo several name changes and versions but the link won’t change. Then, when you move it to a different site or to the “final” document library, the link still works.

Excel Services

Excel Services in SharePoint Server 2013 provided a way to interact with workbooks with data models in a browser, refresh them, work with Power View in a browser as well as PivotCharts, PivotTables and calculated fields. But, you could not create or edit a workbook from the browser or view it if it had rights management applied. For that, you needed Excel Web App and you had to make a choice of which to use.

With SharePoint Server 2016, some of the Excel Services functionality has been moved into Office Online Server. We now have a single service, through Office Online Server, which provides the ability to display and interact with Excel workbooks. So, if you intend on using Excel Services features, including the Excel Web Part, deploying Office Online Server is a must.

Wrap Up

Consider Office Online Server when planning for a SharePoint Server 2016 deployment. The previews, browser-based viewing and editing, Durable Links, and Excel Services capabilities offer users a richer experience. In addition, the same set of servers can be used by Exchange Server 2016, Skype for Business, file shares and other web sites to display Office documents.

We think Office Online Server is essential, that’s why the SharePoint 2016 Product Line Architecture (PLA) includes it as part of the architecture. The PLA takes the best of Microsoft’s learnings from the cloud, projects with customers, Premier and broad support and repeated consulting engagements to come up with a reference architecture. Find out more by contacting your Microsoft representative and by visiting the PLA blog.

One of the exciting new IT Pro features of SharePoint Server 2016 is the ability to patch your farm without causing any downtime.  While updating the SharePoint 2016 PLA Operations Guide, we tested this feature and found it works quite well as long as the Web Front End (WFE) servers are removed from the load balancer while patching.  But before we go into the details, here is a bit of an overview of patching SharePoint for those who aren’t familiar with it.

The process of updating a SharePoint Server 2016 environment is a two-phase process: binary patching and build-to-build upgrade.

Patch phase

The patch phase has two steps, the patch deployment step and the binaries deployment step. During the patch deployment step, new binary files are copied to the server running SharePoint Server 2016. Services that use files that the patch has to replace are temporarily stopped. Stopping services reduces the requirement to restart the server to replace files that are being used.

The second step in the patch phase is the binaries deployment step. In this step, the installer copies support dynamic link library (.dll) files to the appropriate directories on the server that is running SharePoint Server 2016. This step ensures that all the web applications are running the correct version of the binary files and will function correctly after the update is installed. The update phase is complete after the binaries deployment step.

Build-to-build upgrade phase

The next and final phase to deploy software updates is the build-to-build upgrade phase. This phase modifies database schemas, updates objects in the farm, and updates site collections. After you finish the patch phase, you must complete the update installation by starting the build-to-build upgrade phase. The build-to-build upgrade phase is task intensive and, therefore, takes the most time to finish. The first action is to upgrade all the SharePoint processes that are running. After you upgrade the processes, the databases are crawled and upgraded. After you complete a farm upgrade on one server, you have to complete the process on all other servers to maintain compatibility.

Patching steps

Here is a diagram which shows a sample sequence of steps required to install an update on a typical SharePoint farm topology.

1.     Remove half of the web servers (WFE#1) from rotation in the load balancer, or pause the load balancer to stop incoming requests to the servers.
2.     Run the executable file to install the update on each web server that is out of the load-balancing rotation (WFE#1).
3.     Add the updated web server (WFE#1) back into the load-balancing rotation.
4.     Remove the remaining web server (WEB#2 from rotation in the load balancer.
5.     Run the executable file to install the update on each web server that is still out of the load-balancing rotation (WFE#2).
6.     Add the updated web server (WFE#2) back to the load-balancing rotation.
7.     Run the executable file to install the update on the Central Administration server (APP#1).
8.     Run the executable file to install the update on the second application server (APP#2).
9.     Run the executable file to install the update on the first Search server (SRC#1).
10.    Run the executable file to install the update on the second Search server (SRC#2).
11.    Run the executable file to install the update on the first distributed cache server (DCH#1).
12.    Run the executable file to install the update on the second distributed cache server (DCH#2).

At this point in the process, the databases and other components such as settings, features, and site-level data must still be upgraded because the SharePoint Products Configuration Wizard was not run on any of the farm servers. However, the farm should be capable of running in backward compatibility mode for a limited time.

Upgrade Servers

1.        (Optional) Use the Windows PowerShell Upgrade-SPContentDatabase cmdlet to upgrade each content database. This is an optional step, but it will help ensure that all content databases are upgraded first. It has the advantage of enabling some parallelism to reduce upgrade time. If it is not performed, all remaining non-upgraded content databases will be upgraded serially when you run the SharePoint Products Configuration Wizard to upgrade the farm servers.
2.       Run the SharePoint Products Configuration Wizard on the Central Administration server (APP#1).
3.      The SharePoint Products Configuration Wizard also starts an immediate upgrade of the configuration database and all other databases that are not already upgraded. Because it is likely that the content databases are the only databases that have already been upgraded, as described in the previous step, all the service application databases are also upgraded in this step.
4.       Run the SharePoint Products Configuration Wizard on the remaining application server (APP#2).
5.       Remove the first web server (WFE#1) from rotation in the load balancer, or pause the load balancer to stop incoming requests to the servers.
6.       Run the SharePoint Products Configuration Wizard on the web servers (WFE#1)
7.       Add the upgraded web server (WFE#1) back into rotation in the load balancer
8.       Remove the first web server (WFE#2) from rotation in the load balancer, or pause the load balancer to stop incoming requests to the servers.
9.       Run the SharePoint Products Configuration Wizard on the web servers (WFE#2)
10.       Add the upgraded web server (WFE#2) back into rotation in the load balancer
11.       Run the SharePoint Products Configuration Wizard on all remaining servers, one at a time (DCH#1, DCH#2, SRC#1, SRC#2)

Wrapping it up…

As the SharePoint motto goes, we’re “working on it.” That’s right, we’re hard at work on creating an update of the SharePoint 2013 PLA for SharePoint Server 2016.

As a refresher, you should review the following posts found on this blog:

• Introducing the Microsoft Product Line Architecture which explains what the PLA is.
• Benefits of using the Product Line Architecture which explains the value to you as a customer.
• SharePoint PLA in 2015 which touches on including hybrid scenarios (which we did).

In designing the PLA, we look at deployments across our customers, future needs, current and anticipated trends. In doing so, we follow the 80/20 rule; create something that 80% of our customers can use while spending 20% of the effort. In looking at TechNet’s Plan for SharePoint 2013 articles, you can see topics on requirements gathering, planning worksheets, and planning articles for every major feature of the product. Most organizations just don’t have the time to invest in detailed planning and more importantly don’t have the inputs to determine the right design.

Before we look at what’s in store for SharePoint 2016 PLA, we need to understand the “A,” that is, the architecture. My favorite definition comes from Wikipedia, with a twist. Architecture is both the process and the product of planning, designing, and constructing buildings and other physical structures. In this post I’ll focus on the product or the result and not on the process.

A More Modern Architecture

When we tried to design an architecture that was low cost but still high value, it really wasn’t possible without hybrid capabilities. Office 365 has far surpassed the on-premises products with the set of experiences it can deliver though cloud-only capabilities.

More importantly, most of our customers are seeing the value, added security, and richer experiences delivered by Office 365 and are choosing hybrid architectures themselves. We saw this with SharePoint 2013 over a year ago and I wrote Introducing the hybrid add-on which describes a use case and design for hybrid. Since then, hybrid deployments have seemingly accelerated with no signs of slowing down.

With SharePoint Server 2016, it’s easier than ever to create hybrid experiences that are seamless to your users. That’s why the SharePoint 2016 PLA is a hybrid architecture.

What Does That Mean?

Starting with a prescriptive, scalable, reliable, highly-available architecture provides you with a full set of capabilities to provide to your users. With this hybrid architecture, you have the flexibility to host content and solutions where they make sense most and you don’t need to spend a ton of time planning and designing.

But what if you’re still not considering leveraging the cloud in any way? The SharePoint 2016 PLA is still the best predefined architecture to start with, and you would simply choose to forego any cloud integration right now. This does come with a drawback though, a slightly reduced set of capabilities. For example, Office Video, Planner, and Yammer to name a few, are only available in the cloud.

What about upgrades and migrations? You may be comfortable with the cloud but aren’t ready to bulk move everything just yet. Implementing the SharePoint 2016 PLA gives you the flexibility to migrate content at your own pace. You could easily upgrade your content and services to SharePoint Server 2016 immediately, while planning your migration to Office 365 over a longer term. With the right architecture in place, you decide how and when to roll out capabilities and features to delight your users. Stay tuned for more posts on SharePoint and other Product Line Architectures.

SharePoint 2013 can be setup in many different ways. Microsoft Support has documented in a number of Knowledge Base articles, supported and unsupported configurations. TechNet articles describe what configurations and settings are recommended. Out of the number of supported and recommended variants, PLA (Product Line Architecture) defines a standard for the implementation of SharePoint 2013 in your datacenter. It sets the starting point for strong governance for the implementation, smooth operation of it and adoption of SharePoint by business users.

The approach Microsoft has chosen follows a number of design objectives. PLA should decrease design ambiguity and thereby reduce the implementation costs, support costs and implementation time. Upgrades should be easier and less complex. The PLA leverages the practices and experiences Microsoft has building Office 365, thereby helping customers get to the cloud more easily when they decide to do so. The service level target is to achieve a 99.9% availability of the resulting SharePoint farm (the same as Office 365). All security recommendations of the PLA minimize risk without excessive operational burden. And the PLA farm is designed to be extensible in the future.

Different Stakeholders, Different Views

Typically, the Microsoft architect in a PLA engagement obtains feedback from the stakeholders involved in the SharePoint project. This feedback points in as many different directions as there divergent interests.

IT managers (e.g., CIO) usually focus first on the complete implementation that PLA offers and on the cost reduction. They understand that the PLA will reduce the cost for planning, implementation, support and upgrades. Even more important for the management is the strong governance PLA enables. While you may hesitate to start using SharePoint in the cloud, you want to be prepared to change this position later on.

If the enterprise already has experience with SharePoint or similar projects the IT managers and Enterprise Architects position governance as the top advantage for using the PLA.

Developers will realize the benefits of cloud-compatible code but may miss the full trust code of the server object model. In many enterprises, the developers implemented additional tools and solutions for operation and business departments that use full trust code. Some requirements may call for 3^rd party software which is usually full trust code and therefore, not permitted. Developers and 3^rd party vendors will have to transform these now or in the future.

Operations sees the prescriptive design and the reduced complexity as the most important advantage. But they may hesitate in adopting the PLA because it may not fit in to existing operations processes such as monitoring, high availability and disaster recovery.

Business departments realize that the PLA offers a solid platform – as does Office 365. But it does not offer any business solutions out of the box. SharePoint-based applications still have to be built by the business. However, because it's focus on cloud-compatibility, the PLA can enable the business to work in hybrid model much more easily.

Security departments are happy to have all standard features of SharePoint security in place. However, since some business departments demand the urgent need for extranet access, security is missing two-factor authentication and other precautions for a secure access for external users.

Cloud-compatible, Easier Upgrades

The SharePoint 2013 PLA helps to implement an on-premises farm that provides similar functionality to its users as Office 365. The rules in the PLA are such that applications on a PLA can be migrated to Office 365 with less effort. PLA does not allow full trust code and directs the developer to the SharePoint app model using client side object model. The single Web Application, single Farm concept eases management, similar to Office 365. This also helps to make upgrades easier, for example to SharePoint Server 2016. By following the operations recommendations to keep the PLA farm healthy, future upgrades will be smoother and less costly.

Improved SharePoint Governance

PLA defines its implementation by a set of rules for:

• Services, administrative accounts, and Active Directory
• DNS, SSL certificates, load balancing and networking
• Virtualization, Windows Server OS and IIS
• SQL Server and SharePoint configuration
• Operations and Governance

The rules and recommendations limit the variety of possible configurations and guide to a reproducible result. The build and operations guide push in the same direction. The governance recommendations tie it all together from the business user perspective.

If we ask what the PLA can deliver – the governance foreseen here is its major invention. It makes PLA different from the recommendations and supportability statements from TechNet and KB articles by restricting the flexibility of SharePoint Server 2013. We will see that if we want to solve some of the restrictions imposed by the PLA, we will be obliged to bring our own additional governance rules.

PLA is designed to be used and implemented following all rules – at least all rules positioned as mandatory. If your project needs to deviate from one or more mandatory rule, you will take the burden to adapt all documentation and functionality that is affected by the rule change.

PLA Limitations and extensibility

Our discussion of the design objectives for PLA shows that PLA brings number of advantages for the implementation of SharePoint Server 2013. To harvest these, the customer has to accept number of decisions made by the PLA. However, some customers have complaints such as:

Enterprise Architecture claims that the size limits for total items and uploads may hinder the company to fulfill the requirements raised by the business departments in the future. That PLA accepts one farm only for content and application services could be a blocker for growth too.

IT operations have their own proven practices for disaster recovery and high availability. In most cases, these are based on 3^rd party tools. Since the customers apply it for all applications, they insist to use it for SharePoint too.

Security departments are missing additional precautions to protect HBI (High Business Impact) content and access via extranet. They need these to fulfill the existing business requirements. They also insist on using Kerberos instead of NTLM as the authentication protocol as it is more secure.

SharePoint Server 2013 supports more diverse configurations. For example, Kerberos for authentication is supported, multiple farms and web applications are supported, file size and other sizing limitations can be higher and different disaster recovery models are supported.

The deviation in one of these major decisions will not be a pure PLA implementation. As we illustrated above, a deviation may still be supported by the product but the customer will lose part of the advantages of PLA. In the case where a project deviates from the PLA rules, it has to ensure that the parts implemented still fit together with the rest of the architecture, scripts, operations and governance. This results in additional project effort, cost and more long-term maintenance for the deployment. The impact of such decisions varies. For example, if the customer insists on Kerberos for authentication, the project has to add the SPNs to the prerequisites list, to the operations guide, the build guide and modify the build scripts. Additional test cases will be necessary too and IT operations will need to maintain those SPNs. Troubleshooting authentication problems becomes much harder and supporting BYOD (bring your own devices) and extranet access becomes extremely difficult.

The PLA is extensible as long as the rules are still adhered to. For example, it is easy to add external access, BI features or advanced workflow without breaking PLA rules. You just need to ensure your implementation and the vendors features will work properly while adhering to the PLA principles.

While it may be unavoidable in some cases to comply with all rules in the PLA, you should try to adhere to them as much as possible. Doing so will enable your organization to reduce future costs, make upgrades easier and if desired, make the move to the cloud easier as well.

The SharePoint PLA is only available through Microsoft Services or an approved Microsoft partner. Contact your Microsoft Services representative for more information and to get started.

This post was authored by Hans Georg Baumgärtel and Wahid Saleemi.

The rate of change with product and feature release is really an amazing thing to see at Microsoft.  I don’t think I have ever seen us so focused on innovation and change.  It’s the goals of the PLA teams to make sure we account for these changes in our PLA architecture and make sure that customers that engage in implementing these preferred architectures are aligned to take advantage of these changes in the best recommended and supported manner.  There are new PLA’s underway and I hope to be able to share on this blog the new releases of these updates.

Why OneDrive?

OneDrive for Business offers one of the most compelling values for cloud storage. In most organizations, it’s used for personal work-related documents, drafts, or for simple ad-hoc collaboration where a typical SharePoint Team Site isn’t necessarily warranted. This, and similar use cases are a perfect fit for cloud storage.

Organizations have different reasons why they prefer to keep SharePoint on-premises. Some examples are:

• Existing software and other capital investments
• Custom code which cannot be quickly transformed for the cloud
• Regulatory or company policies preventing use of the cloud

In most cases, these reasons are not blockers for the use cases for which OneDrive for Business is suited. Most organizations can easily use a hybrid model where some content remains on-premises and other content (such as personal work-related documents) can be stored in the cloud.

Hybrid add-on

An add-on in the SharePoint PLA is a component which is optional, usually an enhancement or a variation of the default architecture. There are existing add-ons, for example, for deployments in Microsoft Azure and for advanced Business Intelligence features.

The hybrid add-on enables scenarios in an existing SharePoint PLA deployment for:

• moving OneDrive for Business workloads to the cloud
• redirecting all users or a subset of users to the cloud for their OneDrive
• powerful search capabilities including search results from SharePoint Online to be displayed in your PLA farm
• OneDrive for Business Sync client (for Windows; OS X version in development)

Because the SharePoint PLA is already cloud-aligned, combining OneDrive for Business with your on-premises PLA farm is a great fit. It is also one way to ease into the cloud. Over time, you could enable Office 365 with SharePoint Online and start moving team sites to the cloud.

Microsoft Services has unique expertise to help deploy a hybrid architecture while assisting organizations to develop a comprehensive governance strategy.

The SharePoint PLA is only available through Microsoft Services or an approved Microsoft partner. Contact your Microsoft Services representative for more information and to get started.

This post was authored by Wahid Saleemi.

The idea behind a Product Line Architecture is to enable our customers to deploy a configurable product implementation based on a consistent framework of recommended architectural decisions. If the option to deploy Office 365 doesn’t fit in your strategy or existing environment, a PLA deployment should be your next step to evaluate a hybrid or on-premises scenario.

A lot happened to the SharePoint PLA in the last year. For example, new specifications and guidelines were added to the existing content:

• Business Intelligence design and build guide
• Azure IaaS design and build guide
• ADFS design guide
• Foundation for Service Provider Reference Architecture

Many customers have benefited from the guidance, designs, scripts, and other artifacts that were produced by the SharePoint PLA Team. The feedback from those customers was taken and used to improve the next iteration of the SharePoint PLA, available now.

Bottom line: Customers like you can benefit from a very well tested, widely adopted, prescriptive architecture.

The road ahead…

The SharePoint PLA Team continues to develop high quality artifacts that can reduce deployment time. One of the goals for the team in 2015 will be to build solutions that work on-premises and in SharePoint Online to enable an easy transition & migration to Office 365 or enable hybrid scenarios. We’re looking for ways to reduce the cost, effort, and duration for getting an on-premises SharePoint farm running. We’re also working on common hybrid scenarios that leverage OneDrive in the cloud for file sharing and synchronization.

The SharePoint PLA is only available through Microsoft Services or an approved Microsoft partner. Contact your Microsoft Services representative for more information and to get started.

This post was authored by Sven Piekowski and Wahid Saleemi.

We will use Lync as an example for this blog post, but this applies to our PLA's for Exchange and SharePoint as well.

Let's start with a "traditional" deployment. In such a case you would start with a Lync consultant and architect in an envisioning workshop. The architect/consultant would ask you what you want to achieve with your Lync project and start collecting the business and technical requirements. Based on the customer's requirements, the consultant/architect would create a high level architecture and then work with you to go into the plan phase to create a more detailed design, and later on build the environment, stabilize it, and finally roll out on scale (the deploy phase).

While this model has been proven successful in the past, there is also a lot of room for improvement. First of all, this approach is much more dependent on the individual skills and experience of the Lync resources you are working with – have they already be involved in large scale voice deployments like yours and have they architected for all of the optional components of your environment like Persistent Chat? How will learnings from other projects reused in your project – to get sure that consultants/architects do not build isolated islands of best practices but share their experience with each other? How can we ensure that what one person considers as the "best" design is also what the product group and product support agree to? Ultimately, products as complex as Lync allow a virtually an unlimited number of configurations (which is still great if you have very specific requirements that are no covered by PLA)

As a services organization, Microsoft Consulting Services (MCS) is very interested in developing a methodology that allows for the following:

• Repeatable results
• Consistent high quality
• Quicker project cycles
• Reduced risk and cost

The PLA was created for achieving these goals. We started by specifying the target for availability and the service description of what should be included and what should be excluded in the architecture. This tells us what we need to include in the architecture and also the service level target (SLT) we need to achieve. The service description is closely aligned to Office 365 to enable customers to eventually migrate workloads to the cloud. We also allow hybrid configuration, which means in Lync that some of your users can be hosted on-premises and some users in the cloud.

As a next step we looked at each component of Lync to determine how we need to architect for this specific component to provide the desired features, as well as the required availability we pre-defined.

MCS was already involved very early in the development stage of the Lync 2013 – as part of the Technology Adoption Program (TAP). The TAP program is where customers deploy Lync in beta status in their production environment. As part of this program MCS consultants and architects are involved. This way we could already start the PLA planning at a very early stage in the product cycle to develop recommended practices and collect information of what to do and – maybe more importantly – what not to do. In the case of Lync 2013, MCS was already involved in deployments as early as in October 2012, over a year before the product reached RTM status.

Based on this experience, MCS created "rules" and underwent a review process. The rule capture how Lync 2013 must be architected and for how it must be configured. In the reviews, we also involve the product group directly to ensure that we use Lync as it was designed, and also that it is fit for future updates. Last but not least, support engineers also reviewed all the rules to assure that they followed supportability. Also the support review make us aware if some configuration led in the past to a significant number of support cases, so we can avoid it. MCS has also invested thousands of work hours not only in developing these rules, we also created a lot of additional IP that will be used for PLA deployments – ranging from functional specifications for detailed designs, test plans, and operation guides. The PLA is a whole delivery methodology, consisting of architecture, IP and all the experience from hundreds of Lync projects.

All of this puts MCS in a unique position when it comes to creating an architecture for Lync

• Very early access to bits and involvement in TAP program
• Direct dialogue with product group to validate the design
• Direct dialogue with support to avoid problematic architectures and configurations
• Experience and expertise from Lync consultants and architects all over the world and learning from numberless Lync projects

As you can see, the approach of using the PLA will give you the following:

• Achieve balance between scalability, reliability, and security
• Efficiently deploy the infrastructure while maximizing uptime, minimizing failures and downtime
• Reduce deployment costs, administrative overhead, manage risks and complexities
• Ensure upgradeability and patch-ability
• Maximize reusability to make the solution more cost effective
• Focus on empowering users and providing business value such as collaboration

Using the PLA will not be an "experiment" – it is a redelivery of Lync projects that have been delivered multiple times successfully!

About the Author

Thomas started in 2007 to work for Microsoft as a Consultant for OCS 2007. Since then he has worked on large deployments, led instruction classes about OCS/Lync (Ignite, Microsoft Certified Master) and spoke at events like TechEd (see some of his sessions here) or Lync Conference. Thomas is a Microsoft Certified Solution Master: Communications. For the Lync PLA Thomas is the technical lead architect.

In order to understand why Microsoft Consulting Services (MCS) invested in creating the Product Line Architecture (PLA), you have to understand how we designed Exchange for customers in the past. MCS projects are based on Microsoft Solution Framework (MSF). MSF breaks projects in to 5 phases (figure 1), and the one we'll focus on in this blog posting is 'Envision'.

Figure 1: MSF Framework

The Envision phase is where we work with a customer to define and gather their requirements – both technical & business, in order to create a design that is unique to their needs. If you boil it down, one of the most important requirements we gather is around service level agreements (SLA's), recover point objectives (RPO) and recover time objectives (RTO). These requirements are so important to knowing how to create the design – what level of high availability or site resilience is needed, which translates to number of servers, copies of databases, and other architecture features. Many times, a customer would not have these requirements documented, so a lot of time is spent on this work.

To make this process more clear, think of building a house as an analogy. If we were building a house, we would interview the customer and make sure the design meets the unique needs of the customer (single family? One floor? Three car garage? etc.). Otherwise, we could end up with a house that we would spend too much money on un-needed features, or made really bad assumptions (you didn't want a pool?). The effect of this approach is that it takes time to work out this detail, when many customers assume they could just start building servers. In fact, some customers buy hardware before we start the design (or project even beginsJ). Another effect is that we sometimes spend a lot of time trying to figure out what is supported or not. Finally, these types of projects tend to involve customization, which makes it very hard to move forward to new versions and take advantage of new features that could have a big positive impact.

Given the cost of the deployments, and risks that these projects tended to carry – we decided there must be an alternative way to approach this that we could offer our customers. It turns out, timing was perfect because our cloud solution (Office 365) had reached a level of maturity, and so did the product, to give us this new approach for the PLA. The other major impact Office 365 had on the formation of the PLA is the service model for messaging. Getting customers to think about delivering IT as a service is a major shift in the industry, which has some interesting results:

• Focus on costs – for messaging this translates to cost per mailbox. Since the Exchange product has comprehensive native eDiscovery features, there is a push to remove PST's and enable compliance. This results in larger and larger mailboxes.
• Reporting against SLA, RPO and RTO targets – Trending and capacity planning performed at an on-going basis to meet the changing needs of your customers
• Continual service improvements - delivering new features faster vs. staying on a platform until end of life. EOL tries to deliver a good ROI based not investing in a platform as long as possible, with a large "balloon" cost at the end for upgrades. With a continual service upgrade model users and administrators benefit from product updates and hardware improvements over time (4GB drives this year, 6-8GB drives next year – replace drives as you need to expand capacity)

Simply put, the PLA has a similar engagement approach to Office 365 – but on-premises. By this I mean we take the approach of offering a service level target, which defines an architecture that is more configurable than customizable. We no longer need to spend long cycles doing envisioning work, and we have a design that is supportable and optimized the way the product was designed to be used.

Now that we had this approach and design created – we needed a way to help customers understand the value of this approach and probably challenge long standing practices on 'how things should be done'. Office 365 solved this problem by leading customers through solution alignment – and we adopted the same practice.

The SAW is an opportunity for a customer to learn the details on the PLA on the architecture items that they must comply with. In other words, we do ask the customer what they want, rather they are shown the details of what they get. Going back to the house analogy, we have a number of building codes that must be followed, such as the placement of receptacles and light switches. You have choices on the interior trim, but you cannot ask us to build an apartment (I chose this example on purpose as the PLA does not cover multi-tenancy solutions). At the end of the process, we deliver a report that shows the areas that a customer needs to remediate in order to comply with the PLA (as well as areas that are in compliance). If the customer wants to continue the PLA approach, they have a clear understanding of what is required. Alternatively, it also helps customers who want a custom design see a comparison on what that cost / value of that additional work is, so management can understand the impact of taking that custom approach.

The Exchange SAW covers the following areas (figure 2).

Figure 2: Exchange SAW Agenda

We step through these topics (figure 3) and capture whether or not a customer is aligned with the PLA. If not, what is the remediation activity, and who is responsible (customer, MCS, partner, etc.).

Figure 3: Example of an Exchange SAW Topic

Just like our custom envisioning workshops, these slides lead to great discussions and help everyone understand all the pieces needed to do a well-planned Exchange design. I hope this blog post sheds a little light on why we are adding this approach with our customers as an alternative to 'doing things the way we have always done it'. We look forward to sharing more in our next posting on IaaS and Fabric Management.

Thanks,

Jeffrey Rosen