Aligning to the PLA

In this posting, Jeffrey Rosen - the Exchange Team PLA lead architect - will share more information about the Solution Alignment Workshop (SAW) process – using Exchange for the examples. First, I'll do a little recap to set the context, then go into some examples.

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