Product Line Architectures – One Architecture to Rule Them All??

  • Article

A common question the product line architecture (PLA) teams gets is "how is it possible to predefine a prescriptive architecture for <fill in your favorite PLA product>? You don't know MY requirements, you don't know MY datacenter and IT standards." While this may be true, a common architecture like a PLA cannot be designed with everyone's specific requirements in mind; what the PLA can do is significantly lower your overall cost of engineering, deploying and supporting your infrastructure by purposely separating the "utility platform infrastructure" from "high value business solutions". Let's think about this concept a bit using a common example we see today…

The emergence and general adoption of cloud services such as Office 365, Azure, Outlook.com, SalesForce, and others are a perfect examples of utility platforms which provide incredible business value to a large number of customers across the globe. When a customer subscribes to one of these services the core design of the service infrastructure does not change. Never will a customer be asked for their preferred server topology, network configuration, service account design, etc. when subscribing to these services. This is because the underlying design of the infrastructure and the capabilities the platform offers are predetermined and consistent for each service consumer. Customers who are willing to accept the service provider's services and configuration receive in return easily consumable capabilities with reduced time-to-value, minimal setup cost, lower risk and near zero infrastructure operational costs.

Does this mean that these services cannot be configured and customized to meet specific business need? No. It simply means each service provider has drawn a line between what is "common utility" and what is configurable and customizable by the customer. This is precisely what the Microsoft Services Product Line Architecture(s) (PLA) have done in the definition of each PLA.

Creating a Product Line Architecture

Let's take a closer look at the process which was followed to create the PLAs.

Step 1 – Define the Service Definition and Service Level Targets

The process begins with defining the services which the PLA deployment would offer, and what service level targets those services would have. Defining the PLA capabilities and target service levels upfront allows the PLAs to be architected and engineered with these functional and service level requirements in mind. Following the PLA core tenant of leading with the Office 365 cloud, the PLAs service descriptions are closely aligned to their Office 365 counterparts. This alignment minimizes the probability of encountering issues when eventually migrating on-premises workloads to the cloud.

 

Step 2 – Define the Rule Set

The next step in the process is defining the expected elements which must be in-place and configured to be able to provide the PLA services at the planned service level targets. These elements include the configuration of the target datacenter infrastructure (Sites, Network, Directory, Virtualization, etc.) and the specific PLA server product settings as they should be configured in a PLA deployment. These expectations, or "Rules", are how the PLAs define what "must" be in place and what "should" be in place to be PLA compliant.

The rules are a critical component of each PLA, as equally important as the functional specification itself. Without the "rules", the PLA cannot provide any level of assurance that a deployment will function as expected at the service levels targeted. The collection of rules is each PLA incorporate the PLA core design principals and represent the "most optimal" configuration based on Microsoft Services' collective experience delivering the capabilities and products included in each PLA. Microsoft is uniquely positioned to create and maintain the PLA rule sets because no other company has the depth of experience deploying, operating and supporting the technologies in each PLA.

The rules are specifically split into two types:

"Must implement" – these are rules which must be implemented and followed for the deployment to be considered PLA compliant. If these rules are not met, the deployment is not considered PLA – this is non-negotiable for a given release of the PLA.

"Should implement" – these are rules that have configuration options which Microsoft Services would generally recommend a customer follow, but if not followed, will not affect the deployment's ability to deliver the capabilities in the service description at the service levels targeted. If a customer chooses to not follow a recommended rule their deployment can still be considered PLA compliant - if the all of required rules are adhered to during the implementation.

Step 3 – Design Functional Specification and supporting IP

The last step is designing and documenting the physical architecture which delivers the functionality defined in the service description at the service levels targeted in the service levels objectives document. The PLA rules are embedded into this design and can also be found as key drivers in other PLA materials.

Making It Real – The SharePoint PLA

Now that we know how the PLA's were created, let's take a specific look at SharePoint and how the PLA IP supports the process discussed above.

In the first step the service definitions and the service level targets are defined. The SharePoint PLA captures these in two key documents:

  • The SharePoint PLA Service Definition – this document provides a detailed description of the SharePoint services and features supported by the PLA.
  • The SharePoint PLA Service Targets – this document outlines the availability targets the platform architecture is designed to support.

In the second step we define the PLA rules. In the SharePoint PLA one will find

  • The SharePoint PLA Rule Book – this is a very detailed workbook which defines what must and should be configured in a PLA environment.

Finally the functional specification and supporting IP is created. In the SharePoint PLA you will see the physical design documented in three key artifacts:

  • The SharePoint PLA Functional Specification – a document which illustrates the specific physical configuration of the build.
  • The SharePoint PLA Functional Specification Bill of Materials (BoM) – a document which captures more granularity of all the supporting infrastructure (network, accounts, AV rules, etc.) which must be in place to start the PLA build. The BoM is an inventory list which aligns to the design in the functional specification.
  • The SharePoint PLA Build Guide – a detailed step-by-step explanation of how to physically build the PLA according to the specification.

 

Solution Alignment Workshop

So, how does Microsoft Consulting Services (MCS) leverage the service definition, service level targets and rule book to validate if the PLA is a good fit for a customer? Great question!

MCS validates this through a critical process called the Solution Alignment Workshop, or SAW. Every PLA deployment will have completed a SAW before the PLA build begins. In the SAW, customers and PLA architects will go through the PLA to ensure the PLA capabilities align to the business requirements and to validate the target environment can meet the required rules of the PLA. Out of this workshop one of three things can happen:

  • The customer and environment is fully aligned to the PLA – the PLA deployment can begin without any further action required
  • The customer wants to move forward with the PLA deployment but the environment does not meet the requirements of the PLA – in this case the customer will need to remediate the issues found before the PLA deployment can begin. Microsoft Premier Support and Microsoft Consulting Services have many offerings which customers can leverage to help address gaps or issues in order to help align to the PLA.
  • The customer is not aligned to the service definition or cannot meet the required rules of the PLA – in this situation the deployment can continue, but the deployment is not considered PLA. The deployment will have to include appropriate time for engineering, build, test and release which is typically found in a tradition on-premises deployment.

Conclusion

Are the Microsoft Services PLAs the only possible way to deploy the respective PLA server products? No. Will the PLA architecture meet the requirements of every possible business scenario? Again, no. However, based on Microsoft's experience with deploying the PLA products on-premises and running them in the cloud it is believed that the PLA will meet the most common customer scenarios. Customers choosing to adopt the PLAs will get a well-defined, tested, product group reviewed architecture which will significantly decrease deployment time and cost.