Most IT professionals have a sincere interest in developing, implementing, and maintaining a robust, scalable, and flexible network. However, most of us inherit networks that have a variety of shortcomings, and we have to spend the majority of our time putting out fires. One technique that can help you get control of your network is to create a standard system architecture into which all new services and projects must fit.

Microsoft has released the second version of Microsoft Systems Architecture (MSA 2.0), a kit designed to help both medium and large organizations create a standard operating environment. Let’s take a look at MSA 2.0 and how it might help you.

Caveat emptor

Bear in mind that this article discusses a Microsoft-suggested solution to enterprise architectures. The MSA guidelines are developed by the Microsoft Windows Server group, which is responsible for helping organizations that make Windows Server their platform of choice. As such, you should expect it to be somewhat slanted to benefit Microsoft’s own products and those of their partners. However, the information presented here (and the MSA documents themselves) may help you define your non-Windows enterprise architecture as well.

What MSA 2.0 can do
Many environments got their start by slowly growing custom “one-off” solutions that solved a specific business problem. For example, maybe the accounting department chose a package based on SQL Server that stored data onto a Network Appliance network-attached storage unit, while the Marketing group grew into a custom desktop printing solution that required Windows 2000 with an Oracle database and used an EMC network-attached storage unit. This is only an example, but multiply this by dozens of departments in dozens of locations, and you can see how chaotic this type of growth can get.

Most organizations go through this type of growth before embarking on a project to rein it in. Supporting this type of environment is difficult, expensive, and frustrating. Now imagine trying to add, say, a new payroll system to this environment, one that includes centralized timekeeping and all sorts of cool new features. Also try to imagine combining the data from disparate systems in sales and marketing.

The purpose of defining a standard architecture is to prevent this type of chaotic diversity of systems, which results in a network that is expensive to support, difficult to maintain, and very challenging to integrate. A standard enterprise architecture provides the following benefits:

  • Increased security, since the architecture is widely understood by IT and the number of supported vendors and types of products is more limited
  • Decreased or at least controlled costs
  • More predictable IT lifecycle
  • Reduced implementation time through more predictable product integration
  • Better scalability

Of course, Microsoft can’t help you build a standard architecture with Microsoft products alone, especially since it doesn’t have much to do with some necessary hardware, such as servers, SAN units, and networking gear. So, in order to create comprehensive enterprise architectures, Microsoft has partnered with a select few “best-of-breed” vendors, such as:

  • Network equipment: Cisco and Nortel
  • SAN storage: Hewlett-Packard and EMC
  • Servers: Dell, Fujitsu Siemens, Hewlett-Packard, and Unisys
  • SAN fabric: Brocade Communications
  • Backup/recovery: CommVault Systems
  • Fibre Channel host bus adapters: Emulex

Architecture design goals
An enterprise architecture should be created in such a way that some key design goals are met for every solution implemented and based on the plan. For example, availability is an important consideration in every service supported by IT. Your business depends on certain services being available and loses money when they aren’t. Based on the MSA materials, other design goals include:

  • Reliability: Does the solution behave as expected?
  • Supportability: Can the solution be supported in a simple, consistent way?
  • Repeatability: Does the architecture lend itself to repeated, rapidly deployed solutions?
  • Manageability: Does the architecture define a consistent end-to-end solution for monitoring the entire architecture? Does it include alerting procedures?
  • Scalability: Does the architecture lend itself to growth if the need arises?

MSA 2.0 models
MSA 2.0 defines five sample scenarios, including those involving the corporate data center, an individual department, a branch office, an Internet data center, and an extranet. These scenarios aren’t meant necessarily to be stand-alone, but they can be used to build a comprehensive, enterprise-wide architecture that takes all of these environments into consideration as part of a single plan.

Keep in mind that the suggested solutions are just that: suggestions. Microsoft recognizes that, despite its best efforts, not every organization is running all Microsoft software and that all organizations have unique requirements. A single architecture, then, is impossible to define across multiple organizations.

You should think of an enterprise architecture as a base from which you build—kind of like the foundation of a house. If you have a big family, you might need a bigger foundation, but the foundation still looks similar to that of the house next door. The foundation of the house also has the necessary components to make the house work. These components include connections to the plumbing system, connections to the electrical system, physical connections, and so forth. These are roughly analogous to common systems needed in the enterprise, such as directory services, DHCP, DNS, certificate services, etc.

What’s in MSA 2.0?
MSA 2.0 is composed of a number of Word documents, each defining a specific aspect of the overall architecture. There are four downloadable files available from Microsoft. Each file contains information for one part of MSA:

  • MSA 2.0 Introduction
  • MSA 2.0 Reference Architecture Kit
  • MSA 2.0 Implementation Kit—Planning Guide
  • MSA 2.0 Implementation Kit—Build and Operations Guides

The MSA 2.0 Introduction file contains two documents. The first is an introduction to the MSA program, while the second explains how to use the documents.

The Reference Architecture Kit contains two sets of files that will help you begin defining the overall architecture. The first set, architecture blueprints, details architectural principles and design options available in a number of areas, such as management, security, storage, application infrastructure, and network infrastructure. The second set, service blueprints, features design suggestions for infrastructure management, deployment services, directory services, middleware, data services, backup and recovery, Web applications, certificate services, firewall services, file and print services, and more.

The Implementation Kit is made up of two parts: the Planning Guide and the Build and Operations Guides. As you probably know, properly planning any IT undertaking is an extremely important aspect of the project process and can often mean the difference between success and failure. The Implementation Kit covers the same areas as the Reference Architecture Kit, but it goes into more detail about actual products and solutions.

Sure, MSA 2.0 is Windows-centric, but that’s to be expected since it was produced by a group inside Microsoft that’s designed to market Microsoft’s products across the whole enterprise. The MSA kit is an invaluable tool for any IT professional interested in defining an overall enterprise architecture. The benefits of doing so can be enormous, and this kit can help save you a lot of work on the way to achieving that goal. Plus, you can even use the principles you’ll find in these materials as the basis for building a standard architecture for a non-Windows network.