Difference Architectures


Scott Andersen
Microsoft Corporation

October 2006

Applies to:
   Microsoft Exchange
   Microsoft Systems Architecture
   Microsoft Windows Server System Reference Architecture

Summary: The term difference architecture is the beginning of a simplicity movement in software architecture. As we document more and more solutions over time, the overall complexity of the documentation at times can become greater then the solution itself. In and of itself, this fact is not alarming. What is alarming is that people tend towards not leveraging a large architecture document. (7 printed pages)


Reference Architectures


Once upon a time, there was a software-solutions company that was famous for creating large architecture documents. After all, if the technical documentation exceeded 700 pages, it had to be good. For years, this gold standard of documentation was seen as the best way to document what one had. (I call them "thud factor" architectures. How much noise does my architecture make when I drop the documentation on your desk at the end of six weeks?)

Most of the data in that architecture was, in fact, template information. When I was a consultant, there were times in which the architecture document (template form) was 70 pages. I would add another 35-50 pages, producing a 120-page document. I would then go to a copy-service store and bind 10-12 copies of that document to present to the customer. I might have to go a couple of times (there were always minor changes), but then the architecture would be complete. The customer would have 150 bound pages of documentation behind their desk, and I would move on to my next project.

This process is similar to the lather-rinse-repeat process for applying shampoo: It has no stated end point. I would come back to customers, to redo and upgrade the previous solution that I had designed. I would start with a similar template (around 80 pages now, with the new information about the new product) and begin documenting their new architecture. By this time, I would have matured as a consultant and would, of course, have much more information to share, due to all the new features in the technology. So, I would run to the copy-service store again and make 12 more bound copies of my architecture for the customer to keep. I might have to do this again twice, due to minor changes. But now, the customer would have two bound copies behind their desk when I left.

And they lived happily ever after.

So, Why This Paper?

My first issue with this process of "repeated architecturalization" came when I realized that customers really did not read the documents that I was leaving behind. From operations guides to step-by-step documents, in most cases they merely gathered dust on a shelf.

One of the issues is that it is hard to read 200 pages of technical documentation. It tends to be dense and tightly packed with information. Unlike those cool picture books we read as kids, technical documentation includes pictures that often represent components and pieces that are not documented in the actual text. Or, worse, at times there are things in the picture that are not pictured as they are described in the text. Or (my personal favorite) the document was written long before the solution was deployed, and now the two do not look at all like each other, because the document was put on ice and never updated to reflect any changes in implementation. Of course, in addition to the denseness of the documentation, there is seldom a solid plot that includes a hero or a heroine.

Like all things, the presence of pain is an issue. Complexity is the pain of architecture documentation. If the documentation is too complex, it will never be used. If the documentation is too high-level, it's useless. Documentation that is never read is worse than useless: It's something of value that not only missed its mark, but in fact might forever alter the perception of the quality of the solution.

With pain often comes either medication to treat the pain or change to fix the pain permanently. The concept of difference architectures represents both the medication to treat the pain and a move towards simplicity in design, to resolve the problem forever.

You see, vendors have been solving the problem for us for years. Major vendors ship reference architectures with their products. Microsoft, IBM, Cisco, and others all go into a lab, install their respective solution, and ensure (based on the settings that they chose and documented) that the solution will, in fact, work. Put simply, that is a reference architecture, a starting point for future solutions. However, we need a process to bring together, into one place, what we have traditionally done (so-called thud architectures) and reference architectures.

Reference Architectures

The Burton Group defines a reference architecture as "a valuable decision-making framework." IBM defines a reference architecture as "the best of best practices."

Personally, I prefer this latter analogy. The first launch of a manned space vehicle documented the processes and procedures that have been used ever since by the space program. The Mercury program tested and validated the scenarios, as well as the implementation of the solution for future space travel. NASA iterated this solution with both the Gemini and Apollo programs. But the standards and components remain the same for each following solution. They improve the solution, but the concepts are the same. You must have:

  • Sufficient oxygen to make it to your destination and back.
  • An escape route for the astronauts.
  • Redundant systems that are wired separately from the main systems.
  • Sufficient food and water.
  • A communications system that can withstand pauses (transmission time from the moon and beyond).
  • An onboard and ground-based guidance system.
  • A solution that would allow for both ground and water-based astronaut recovery.

All of these pieces (and there are many more; for instance, the requirements around a toilet in space are a huge piece of the architecture) represent a reference architecture for building a space vehicle that is launched from earth and returns to earth with its contents shaken but not damaged. This reference architecture worked from 1961 until the launch of the Skylab program in 1975. The reference architecture was so effective that they were able to merge two different solutions (Soyuz and Apollo) and have them connect together in space. However, technology changes over time. NASA realized that the cost of an expendable space-flight system (only the last stage is returned/recovered) was significant. They began designing a reusable space craft. Even then, they didn't throw out their reference architecture. They carried forward the key concepts of the space travel, while building new concepts around reusability in space travel.

This analogy gives us a view of the value of a reference architecture. Immutable for NASA were certain core concepts. For most companies deploying technology, there are also certain immutable concepts. For example, network capacity is a known capability of the organization; exceeding the available capacity with a new solution is never good. The reference architecture represents the known good from an organization. We know that these things work, and work together.

Using a Reference Architecture

Reference architectures are quite simple. For example, Customer A requests that Company B build a Microsoft Exchange server infrastructure for its 40,000 users. Company B, being a Microsoft partner, goes to Microsoft.com and searches for a starting point.

Company B finds a series of documents called the Microsoft Windows Server System Reference Architecture (WSSRA, formerly called Microsoft Systems Architecture). Knowing that a reference architecture represents proven solutions, they choose to start with the WSSRA reference architecture. This solution, by the way, encompasses way more than a single Microsoft Exchange solution would require. So, what do our friends at Company B do? They build a difference architecture.

Reference architectures represent architectures that have been deployed, tested, and validated. Which means that if Company B decides it wants to start with the best-known scenario, WSSRA is that solution. However, as mentioned above, there is more to WSSRA than is required for a Microsoft Exchange solution.

The problem is that WSSRA is about 1,000 pages long, if you print out everything. Which puts us right back into the boat we are trying to get out of: too many dead trees. We need to show the difference from the reference architecture (the difference architecture). We do this by showing what is deployed, what we designed, and any variations from the reference architecture—without printing and binding hundreds of pages of documentation.

Microsoft Reference Architecture

The conceptual solution that is described in this document follows the guidelines established by WSSRA. WSSRA is a set of guidelines for different technology implementations to assist customers with designing, building, and operating a Windows server-based solution. This is done by using a standardized approach to IT architecture across the organization. In this way, the solution uses validated architectural guidance to ensure the integrity of the infrastructure.

Figure 1, below, shows the logical architecture for the original Microsoft Systems Architecture (MSA, the predecessor to WSSRA). This original version of the diagram shows off the full logical architecture for WSSRA.

Microsoft Systems Architecture for Enterprise 2.0

Corporate and satellite branch-office scenarios


Figure 1. MSA logical architecture

Building a Difference Architecture

So, back to Company B. They have been asked to build a solution that is based on Microsoft Exchange for Customer A. They selected the WSSRA as the baseline for their solution. However, they do not wish to hand the customer 1,000 printed pages of documentation. I talked earlier about the issue that many people have with reading just 100 pages of technical documentation. It seems like we are going in the wrong direction with our solution! Building an architecture that is based on the reference architecture published by the vendor is a great starting point, but there needs to be a way to solve this problem without giving the customer 1,000 printed pages—or, for that matter, 100 printed pages. We should be able to present the customer with a document that contains links and no more than 30 pages.

Our next step is to put together the required pieces of our difference architecture. This will involve ensuring that we have established the reference architecture that we will be using. Remember that architectures, whether standard or difference, are living documents. As such, it is critical that clear standards are established for the documentation process. Don't waste documentation space by defining the standards; make sure that they are available as a link within the difference architecture. All diagrams should include tables, so that they can be used without the architecture document. You can include links to a Web site that contains all of the diagrams and not include the diagrams in the document. This also helps keep the documentation up-to-date, as the link content is updated.

Documenting the Difference Architecture

The first thing is to determine what is deployed today using whatever method we chose. My personal preferences are for using infrastructure capabilities and Perspective-Based Architectures (PBA). In our example, we carefully studied the WSSRA solution for the Microsoft Exchange components that are relevant to what we are doing. We are finally ready to start cutting the paperwork.

Before we move on, here is a little information about PBA. After two years of research and work with international bodies, customers, and field teams, the PBA Method was developed to fill a missing element for the architecture community: to drive better decisions by capturing better questions. This is accomplished through three stages that contain structured, focused questions. Stage one is a series of questions capturing the perspective (what is your environment and where is it going). Stage two examines the impact of alternatives or existing proposals on the captured perspective (from stage one). Stage three examines the impact of the final proposal on the captured perspective (from stage one). This simple structure works with all processes, methodologies, technologies, and documentation standards. Finally, the PBA Method represents a living architectural methodology. Questions and perspective structure can evolve over time that transcends current architectures. Customers, partners, and international bodies have communicated an interest to participate in growing, promoting, and capitalizing on the PBA method.

However we determine what our current deployment is, we now take what we deploy as the solution and map that against the WSSRA components mentioned above. Then, Company B will document only those things that are directly different from those that are listed in the reference architecture. This "difference document" will be much smaller, but in fact will represent the architecture of the solution. To get this document, follow these steps:

  1. Introduce the concept of the reference architecture (RA) that was selected.
  2. Leverage an RA that exists as the anchor for the technology solution that you will be building. Begin your architecture with a preface that contains the description of the RA that is used.
  3. Include links to the relevant sections of the RA in a links section. We will need pointers to the following selections (this is a short list; there are many more):
    • Directory Services
    • Remote Network Login Services
    • Security Architecture
    • Data Center Layout
    • Exchange Design
  4. Include links to a Web site with all relevant architectural drawings. Make the upgrade easy; include all diagrams in that location, so that they are easily found. Think of your architecture as a road map to both the RA and the solution that is provided. That way, upgrades and future installers/troubleshooters can easily find the information that they need.
  5. Document any "use" requirements for the RA. For example, WSSRA has a series of downloads that you need for referencing the RA.
  6. Document any other requirements for the RA:
    • Training.
    • Tell audience how to find the printed version.
    • Network share with any required documents or Microsoft Visio drawings.
    • Web site with the architecture and components.
  7. Document any areas in the reference architecture that are not relevant to the solution. For example, the reference architecture, being a massive undertaking, might not be iterated as quickly as technologies might be iterated. Or your solution relies on a firewall different from the reference architecture. This is the difference architecture, as it shows the variance in the solution from the reference architecture.
    • Note out-of-date products.
    • Note variances (XYZ).
    • Note additions.
    • Include space for future revisions. Ensure that what is documented is what has been deployed.

Now, during troubleshooting or redesign, the architect of the new project or the technician handling the issue no longer has to read 120 pages to find the answer. The difference architecture document points to smaller pieces that are more effectively consumed and reused.

Scaling the Difference Architecture with the POD Concept

Difference architectures are about simplification. They document the changes or variances from the existing reference architecture. The problem is that, in most cases, reference architectures are not scalable. Here, downsizing instead of upward scalability is the issue. Smaller organizations cannot bear the cost of implementing the full reference architecture. For that matter, larger organizations are not able to push a full RA-compliant solution to all of the locations that require servers.

Implementing a reference architecture in small components has been designated a "POD." A POD represents a small unit (or large unit) that can be placed within an organization to handle certain components of functionality within the organization. PODs can be tailored to any size customer, as their functionality is tied to the overall WSSRA solution. Scaling the POD up or down does not change the overall course of the solution. Instead, the scaling process is a component of the reference architecture. I've covered this in much more detail in my previous article on infrastructure architecture capabilities, which is referenced above.


The solution as described in the proposal has been generated by using high-level information and experience gained in other customer environments. There are a number of factors that should be considered during the recommended architecture, planning, and design activities before proceeding with any infrastructure implementation.

With the established architecture framework (WSSRA) and the projected hardware configurations for data centers, the next tier is to document the potential differences for this solution from the reference architecture.


About the author

From 1996 through 2005, Scott Andersen worked as an architect in the Microsoft Services Consulting Business. During that time, Scott worked with many Microsoft customers throughout the world, traveling from Kuala Lumpur, Malaysia, to Lisbon, Portugal, as well as many cities in the U.S. (Des Plaines, IL; Seattle; Chicago; Cincinnati; Detroit; and the list goes on). In 2000, Scott moved into a quality-assurance role within Microsoft Services. As such, he has had to read many architecture documents, encompassing thousands of pages—a significant factor in the development of the difference-architecture process.

Scott is one of the original members of the team that built the Microsoft Certified Architect (MCA) certification and has been an MCA since April 2005. Currently, Scott works for the Microsoft Exchange Product Group as a customer-facing Program Manager.

The concept of difference architectures came out of discussions with Lewis Curtis of the DPE team at Microsoft, who has developed the excellent Perspective Based Architecture (PBA) program.