Benefits of using the Product Line Architecture

Previous blog posts described what the Product Line Architecture (PLA) is, and how it was created. This post will concentrate answering two questions from the customer's perspective; Why deploy the PLA? What are the benefits?

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.