As much as I enjoy working with Microsoft products (even when they’re being difficult), I would never rush out and buy one without doing a formal analysis first. While I think Microsoft’s products do a great job of meeting the major needs of most organizations, they obviously can’t meet the exact needs of every organization. And what Microsoft’s product team considers to be a minor need—and therefore something they can leave out—might be incredibly important to your company. So before you plan to implement any new technology, assess it carefully. Consider competing or complementary products that might work better in your environment. Most importantly, investigate how the product works, and make sure that your company either already works that way, or is willing to change.
Tip
One of the biggest reasons that new technology implementations fail is that they require the organization to change the way it works, and the organization doesn’t want to make the change. Business needs should drive technology, and business processes should dictate how technology works, and never the other way around. This applies even if all you’re doing is implementing technology: Make sure your implementation meets the needs of your organization, and doesn’t simply follow the path of least resistance offered by the technology.
In this chapter, I’ll provide you with a methodology for assessing your company’s business needs, and assessing the capabilities of technologies that you’re considering. Then, I’ll show you how to use that information to select the technologies that best meet your needs, and create an initial design based on those technologies. This chapter is designed to provide a framework; the chapters in Part II of this book will provide the actual data on each of the .NET Enterprise Servers that you can plug into the framework for your technology assessment.
Finding out what your business actually needs from a particular technology can be difficult. It’s tempting to just sit down and start making a list, but if you’re reading this book then you’re probably a part of your company’s IT department, which means you may not be qualified to create a complete list of business needs. For that reason, you should solicit the input of the business professionals who will be impacted by your planned implementation. You should also consider all of the different business problems that are facing your company, because a suite of products like the .NET Enterprise Servers may be able to offer synergies that solve problems which couldn’t be solved by a single independent product.
Rather than rambling on about business needs assessments in the abstract, I’ll give you a fictional company to consider. Pete’s Big Beverages (PBB) is an international company that produces a variety of beers and soft drinks. Their products are distributed by independent regional bottlers throughout the world. The bottlers do their own regional advertising and marketing, but the majority of the advertising and marketing is conducted by the main company. The company’s corporate office is located in Denver, Colorado, and regional offices are located in New York, San Diego, London, Sydney, Seoul, Moscow, and Paris. Each office has its own local area network (LAN), and each regional office is connected to the Denver office by dedicated wide area network (WAN) connections.
PBB is a fairly typical large company. They maintain a Web site, which includes the usual mix of marketing and product information, as well as a number of online games based on their products. The Web site also includes a company store, which sells product-related merchandise like shirts, hats, and so forth. The Web site is pretty popular, drawing tens of thousands of hits each day. Whenever the company launches a new marketing campaign, Web site traffic can increase to millions of hits per day. Like most manufacturing companies, PBB deals with a number of suppliers to obtain the raw ingredients for its products. While the bottlers purchase many of their ingredients independently, some ingredients are more specialized. PBB negotiates pricing contracts for these ingredients, and allows bottlers to purchase the ingredients directly from PBB. PBB doesn’t fulfill those orders, but instead passes them on to the suppliers, who ship ingredients directly to the bottlers.
Like most companies these days, email is important to PBB. Hundreds of thousands of email messages go through their mail system each day, and the number continues to grow. PBB uses email as a means of collaboration, since regional advertising campaigns are created through a collaborative process between the regional offices and the executives at the Denver office. The Denver office also serves as a central repository for worldwide sales figures and marketing statistics, which are stored in the company’s IBM AS/400 midrange computer.
After you get a feel for your company’s basic operations, you can start identifying some basic needs. You won’t need input from other employees to state the obvious problems, but you should definitely interview executives, department heads, and employees to discover less obvious problems. For example, it might not be a problem for you that sales employees have to walk halfway around the building to fax estimates to customers. The sales manager, on the other hand, can probably tell you exactly how much money is lost every time a salesperson steps away from their desk and telephone. Getting that kind of inside look at business problems will reveal some of the most important business needs that technology can address.
You probably know enough about your company to spot some of the most obvious problems, and think about possible technological solutions. By reading through the PBB case study, you might have identified several possible problem areas:
With such an active Web site, PBB probably runs several Web servers. Managing and maintaining those servers probably consumes a fair amount of time. Also, since the Web site has occasional spikes in traffic, PBB might benefit from some way to easily and quickly increase the site’s capacity.
PBB does a lot of business with suppliers, and acts as a sort of paperwork middleman between bottlers and suppliers for some ingredients. That means PBB probably goes through a good amount of paperwork. Given that the company seems to embrace technology to some degree, they’ve probably already spent money trying to automate their supplier relationships.
Since the company’s Web site receives frequent updates, the company probably has an editorial and design team responsible for the site. That team may have workflow issues that could be solved by an appropriate technology or product.
Collaboration though email can be cumbersome, yet it’s obvious that PBB is doing a lot of it. A more advanced means of collaboration might be something to investigate.
The fact that PBB has an AS/400 means there’s probably an opportunity to leverage some of the AS/400’s data in other network operations, and vice versa. Host systems like AS/400s tend to be treated like a castle surrounded by a moat: Everything in the castle stays in, and everything outside stays out. Businesses such as PBB could benefit by bridging the moat and making data more easily accessible across the company.
The company uses a number of old, custom-developed applications for various purposes. These applications often duplicate data, which is inefficient. Even worse, many new projects could make use of the applications’ data were it available in a central location that was easily accessible from across the company’s network.
This isn’t a comprehensive list, of course, and every company with an environment like PBB might not have these problems. Most of these problems are likely to occur, though, because the types of technology PBB is using were obviously implemented over a long period of time. They probably bought their AS/400 years ago, and only recently started using their Web site to sell merchandise. Email was probably adopted gradually, growing over the years into the monster it obviously is today. There are other hints that PBB hasn’t really taken a master-plan approach to their IT infrastructure, such as the fact that they’re making do by using email as a collaboration platform when there are a number of better alternatives available.
Less obvious problems include those that reflect a problem with existing business processes. Business processes tend to evolve over time, in response to changing business conditions and restrictions. Technology itself can result in business process problems, as business processes are sometimes forced to adapt to inflexible technologies. Analyzing a company like PBB, you might find process problems like these:
The process for publishing new content to the company Web site is overly complex. Content developers and editors start in Microsoft Word. Once approved, their content is sent to an HTML developer, who places the content into the company’s standard Web templates. The final Web page is sent back to the author and editor for approval, and then to the Web site manager for approval. Finally, the content is sent to a Web technician, who deploys the content to the production Web site.
The company’s Web-based store is partially hosted by an outside company. While the store’s main Web pages are hosted by PBB, pages that actually complete sales transactions are hosted by the outside company, who maintains an e-commerce infrastructure. This process often results in customer confusion, and makes it difficult to update the transaction pages whenever the look of the main Web site changes.
The PBB Web site features an email list, where visitors can sign up to receive email product discounts, news on upcoming promotions, and so forth. Currently, the Web site places new subscribers’ email addresses into a database. When an email needs to be sent to the subscriber list, it takes the efforts of a writer, editor, HTML coder, database administrator, and network administrator to get the job done.
Many company employees work from home, and dial in to the company’s network to access company resources. Most of these employees have much faster Internet connections (DSL lines, cable modems, and so forth), but are reduced to slow dial-up speeds when connected to the company’s network, because the company doesn’t allow employees to access company resources via the Internet.
The common characteristic for these types of problems is that they’re obvious to everyone who is affected by them, but they’re fairly hidden from the IT staff in most companies. That’s why it’s so important for you to involve employees from other departments when conducting a business needs assessment.
The last category of problems you’re likely to run across are what I like to call stealth problems. These are problems that nobody knows are actually problems, although if they thought about it, most employees would demand an immediate solution. Take a company like PBB and you might find some of the following stealth problems:
Many times each year, employees from the regional offices fly to the Denver office for sales and marketing strategy meetings. Some of these meetings only last for a few hours, although getting there can require a day-long flight for some employees. Many of the meetings could even be conducted over the phone, although the marketing employees don’t like to do that because they miss out on the group dynamics of a live meeting.
Regional bottlers are independent companies, and have varying levels of technical sophistication. While some bottlers are able to report their sales information electronically, others still mail or fax a handwritten sales summary each quarter. Accommodating these various methods is expensive and time-consuming.
Most of the regional bottlers rely on printed company newsletters to receive updated information about upcoming marketing campaigns and other news. This method is slow and unreliable, as the printed newsletters aren’t always disseminated throughout the bottlers’ offices.
Field representatives, who are responsible for helping bottlers improve their sales and for analyzing such things as product placement within stores, are among the company’s most out-of-touch employees. Because they spend most of their time in the field, these representatives may only check their email once or twice a week, and have a difficult time reporting their findings to the corporate office in a timely fashion.
The Denver office runs up an enormous international phone bill each month. While calls to regional offices are carried over flat-fee leased lines, the Denver office sends a huge number of faxes to customers in each region every month. Some enterprising employees have started emailing documents to co-workers in the regional offices, where the documents can be faxed for much less, but that effort is inefficient and only minimally effective.
Tip
You should be able to start matching some of the previous business needs to .NET Enterprise Servers that can help address those needs. Use the .NET Enterprise Servers Feature Overview in Chapter 2 to help you get an idea of what each .NET Enterprise Server does, and then match those capabilities to the business needs described here (or the business needs in your own company).
Of course, not every business need can be addressed by one of the .NET Enterprise Servers. You’ll also have to identify needs that will require other products or technologies, and plan for those technologies accordingly.
Everyone in your company probably agrees that employees deserve every possible tool and advantage to help keep the company competitive. Unfortunately, companies also have to deal with budgets, which say that only so much can be done each year. That means you’ll need to pick and choose your battles, and implement solutions that can have the most positive impact on the company as a whole.
“Picking your battles” doesn’t always mean trying to solve all of the small problems first, and then tackling the bigger problems. Thanks to product interdependencies, solving one solution often lets you solve two or three others with relatively little additional effort. For example, if you decide to implement BizTalk Server, then you’re also going to be implementing SQL Server, since BizTalk Server requires it. If there’s a problem that’s been screaming out for SQL Server as a solution, then you may as well address that issue at the same time.
As an example, suppose you’ve been tasked to solve the many problems facing the Web development team at Pete’s Big Beverages. So far, the problems you’ve identified are
The process for publishing new content to the company Web site is overly complex. Content developers and editors start in Microsoft Word. Once approved, their content is sent to an HTML developer, who places the content into the company’s standard Web templates. The final Web page is sent back to the author and editor for approval, and then to the Web site manager for approval. Finally, the content is sent to a Web technician, who deploys the content to the production Web site.
The company’s Web-based store is partially hosted by an outside company. While the store’s main Web pages are hosted by PBB, pages that actually complete sales transactions are hosted by the outside company, who maintains an e-commerce infrastructure. This process often results in customer confusion, and makes it difficult to update the transaction pages whenever the look of the main Web site changes.
The PBB Web site features an email list, where visitors can sign up to receive email product discounts, news on upcoming promotions, and so forth. Currently, the Web site places new subscribers’ email addresses into a database. When an email needs to be sent to the subscriber list, it takes the efforts of a writer, editor, HTML coder, database administrator, and network administrator to get the list out on time.
PBB runs several Web servers. Managing and maintaining those servers consumes a lot of time. Also, since the Web site has occasional spikes in traffic, PBB might benefit from some way to easily and quickly increase the site’s capacity.
Running through the features of the various .NET Enterprise Servers, it seems as if some combination of Application Center, Content Management Server, Commerce Server, and SharePoint Portal Server might be appropriate.
| For more information on Application Center’s features, see “Application Center,” p. 25 |
| For more information on Content Management Server’s features, see “Content Management Server,” p. 45 |
| For more information on SharePoint Portal Server’s features, see “SharePoint Portal Server,” p. 62 |
| For more information on Commerce Server’s features, see “Commerce Server,” p. 38 |
At least one of those products—Commerce Server—requires SQL Server as a prerequisite. So it’s worth looking over the company’s other issues to see if there are any that SQL Server might be able to solve.
| For more information on SQL Server’s features, see “SQL Server,” p. 64 |
Data Transformation Services (DTS) is a SQL Server feature that seems to offer a solution for the company’s data, which is currently distributed across several different applications:
The company uses a number of old, custom-developed applications for various purposes. These applications often duplicate data, which is inefficient. Even worse, many new projects could make use of the applications’ data were it available in a central location that was easily accessible from across the company’s network.
The important part of this exercise is to tighten the scope of an implementation product. You’re not going to solve every company problem in one fell swoop; on the other hand, by understanding the interdependencies and capabilities of the products you’re considering—in this case, five .NET Enterprise Servers—you can eliminate as many problems as possible with the time and budget you have.
The last step in a business needs analysis is to formally document the business needs you’ve discovered, and indicate which ones will be the target of your implementation project (in other words, which ones you’re going to try to solve). Your documentation can take almost any form you wish, but I like to use worksheets such as the one shown in Figure 4.1. Don’t try to categorize the problems just yet. Right now, you should be thinking about the problems in terms of their impact on your organization, not on who they affect or what solutions might exist to solve them.
You don’t need to include a lot of information on the form, but make sure you include at least the following:
A brief description of the business need.
A priority of the business need. I like to use higher numbers for higher priority, such as a scale from 1 to 5 with 1 representing less important needs.
The name of a person in your organization who can provide more details on the business need at a later date, if necessary.
Tip
I’ll be using the sample form in Figure 4.1 as the basis for later exercises in technology evaluation. If you come up with your own worksheet, include lots of extra lines and columns so that the worksheet can serve multiple purposes in your own evaluation process.
Assigning a priority to business needs can be difficult. Here’s a scale that I’ve found to be helpful:
5—. Absolutely critical. The problem listed is causing the company to lose money, or at least preventing the company from making as much money.
4—. Important, but the company is surviving with the current situation. The current situation doesn’t allow for growth, though, so solving the problem is a must before growth can occur.
3—. The problem is important, but existing workarounds seem to be holding everything together.
2—. The problem is annoying, but is being well-mitigated at the current time. Although inefficient, there aren’t any easily-identifiable savings by making a change.
1—. The problem is annoying, but isn’t really causing a loss or preventing growth. It would be nice to fix the problem as part of another overall solution, but the problem isn’t worth addressing independently.
Figure 4.2 shows my sample worksheet, filled in to reflect the business needs and problems of Pete’s Big Beverages’ Web site.
Once your business needs are fully documented, you can begin assessing specific technologies for their ability solve your problems. That assessment needs to start with a first pass on potential technologies, and then a careful documentation of their capabilities.
You’ve probably already identified some potential solutions for the business problems you’re focusing on. In the case of Pete’s Big Beverages, I’ve identified five potential solutions from the .NET Enterprise Servers lineup:
Application Center
Commerce Server
Content Management Server (CMS)
SharePoint Portal Server (SPS)
SQL Server
You don’t need to worry about how realistic these possibilities are, and you don’t need to worry at this point about competing products. Your goal for right now is to identify basic categories of products that might solve your needs. You do need to get a rough idea of what each product can do for you, and then give it a rating based on how well it addresses your business needs. I like to use a rating scale of zero to three, where three represents a product that perfectly meets a business need, and one represents a product that barely addresses the need. Zero represents a product that doesn’t help solve the need at all.
Note
A zero-to-three scale is sufficient for now, because this is just a first-pass analysis. Don’t worry too much about the exact details of candidate products’ features. At this point, you can rely primarily on overview information (like that in Chapter 2) or even marketing materials from the product’s manufacturer.
When you’re finished, add the products and their ratings to your worksheet. As shown in Figure 4.3, I give each product a rating, and then multiply that rating by the priority of the business need. So Application Center, which rates a 3 on the priority-4 business need for Web management, gets a total score of 12 (shown after the slash). Add up the scores at the bottom of the worksheet, and you’ll see which products you should be examining most closely.
Once you’ve put your basic ratings in place, go back and get some feedback from your contacts. Explain why you think each product deserves the rating it got, and tell them a little bit about what each product does, based on your initial research. In my running example with Pete’s Big Beverages, the following information might come out:
Application Center can help a little bit with the publishing process, because it helps to automate content deployment. It won’t help with the overall workflow problem, though, so it only gets a score of one.
Application Center gets a perfect three for Web server administration, because its whole purpose is to make managing multiple Web servers as easy as administering one Web server.
CMS scores a perfect three on the Web publishing process, because handling Web publishing workflow is exactly what CMS is for. The high priority of that business need earns CMS a very high overall score.
Commerce Server gets a perfect score on Web store hosting and email list management, because Commerce Server is specifically designed to handle those tasks.
SharePoint only gets a score of one for Web publishing, because it’s designed primarily for intranet use, not Internet Web publishing.
SQL Server picks up one point for email management, because you could certainly develop a database that does a better job than the existing email management system. SQL Server is also capable of sending email, but it’s not the ideal solution for email list management.
SQL Server picks up three points for the application data problem, because DTS can consolidate all of the distributed data into a single database, making it more easily accessible to other processes. SQL Server can even do that consolidation on a scheduled basis without supervision, making it an ideal solution.
SQL Server also picks up three points as a prerequisite. It’s actually required by both CMS and Commerce Server, and so I added a “Pre-req” business need with a priority of five. I always use a priority of five for prerequisites to make sure the prerequisite product rates well, since I have to have it.
After talking through that information with some of the other folks in PBB, I might find out that SPS actually offers a potential solution for another business problem:
Most of the regional bottlers rely on printed company newsletters to receive updated information about upcoming marketing campaigns and other news. This method is slow and unreliable, as the printed newsletters aren’t always disseminated throughout the bottlers’ offices.
After you explain to Mary Ellen (who is in charge of the Web department) how SPS is really ideal for intranet Web publishing, she might suggest that SPS could be a solution to the printed newsletter problem: Eliminate the newsletter, and rely on an SPS-based intranet to provide bottlers with the latest information. The suggestion is a good one, especially if PBB decides to adopt SPS for other reasons. But SPS doesn’t automatically get a higher score for Internet Web publishing. Instead, I’ll modify my spreadsheet to look like the one in Figure 4.4, reflecting the new business need and SPS’s score.
SPS doesn’t get a perfect score, because in order for bottlers to access the intranet, they’ll need to somehow gain access to the Denver network. Actually, as shown on the chart, CMS gets a better score, because it could be used to publish an online newsletter to a private Internet Web site (referred to as an extranet). SPS’s features are really geared toward building intranet information portals, which don’t match up well with any of PBB’s current business needs.
Once you’ve identified your candidate technologies, you need to start documenting exactly what they do that solves your problems, and how well they do it. This is where Part II of this book comes in handy, since each chapter includes a “Technology Capabilities” section that details exactly how each of the .NET Enterprise Servers works, and what they can do for you. Taking Application Center as an example, PBB might come up with the following technology capabilities (some of which, you’ll note, are actually limitations):
Application Center enables an administrator to manage multiple Web servers as easily as one.
Application Center only works with Windows 2000 (or higher) and IIS. PBB is currently using a mix of Windows 2000 servers running IIS and Linux-based Web servers running Apache, so a complete replacement of the Linux servers would be required.
Application Center provides built-in load balancing based on actual server capacity. PBB currently uses an external hardware load balancer that only works on the least connections load balancing method, which represents a less accurate picture of server capacity.
Application Center automatically deploys new content. PBB currently deploys content manually to all Web servers.
Application Center is compatible with Commerce Server. PBB is looking hard at Commerce Server, so this compatibility is a plus. Note that Commerce Server doesn’t run on Linux, either, so the issue of moving from Linux may be decided by Commerce Server, and not by Application Center.
Application Center provides consolidated server health and performance monitoring. Currently, PBB monitors the health of each Web server individually. Application Center’s health monitoring can also extend to include other .NET Enterprise Servers, such as SQL Server, which PBB is already looking to implement.
Note that some of the product capabilities listed solve problems that haven’t been specifically mentioned so far. You’ll often find that to be the case, because once your coworkers realize what technology can provide, they realize that the environment they’re currently working with should be classified as a problem, and not simply the “way things are.” The next step in creating technology documentation is to create separate worksheets for each product that you’re considering. Figure 4.5 shows a sample worksheet. Your worksheet should list each of the capabilities the product includes, a rating for how important that feature is to your organization, and a rating for how well the product implements that particular feature.
Your product-specific worksheet should work a lot like the overall worksheet you’ve already done. In this case, rather than evaluating products’ overall suitability for your problem, you’re evaluating products’ features in more detail. Note that the worksheet in Figure 4.5 has additional blank columns. Those columns allow you to compare and contrast competing products, as shown in Figure 4.6. You’ll need to do further research on competing products in order to accurately rate them.
Tip
I always start my product-specific worksheets by using the product I’m most familiar with. Then I start researching other products. Most of the time, I can call up a salesperson in the competitor’s company and ask them for the information I need to complete their product’s column on my worksheet. Often, those conversations make me aware of additional features, which I add to my worksheet. You’ll have to do some back-and-forth work to fill in ratings on the new features for the products you’ve already evaluated. The evaluation process might seem a bit cumbersome, but it’s the best way to ensure that you’re comparing apples to apples, and selecting the product that best meets your company’s needs.
Note
As shown in Figure 4.6, you won’t always be able to find products that meet every one of your needs. The worksheet identifies a need to load balance incoming requests to geographically distributed Web farms, but none of the products evaluated offer that ability. When that happens, you’ll need to rethink the business need. Don’t be afraid to write down needs that you think might not be achievable, though. Document all of your business needs, and if it turns out that you can’t find a product to meet them, you can rethink things later.
As your evaluation progresses, be sure to note any prerequisites or dependencies between each of the products you evaluate. For example, suppose that your original thought was to use Application Center, Commerce Server, and SQL Server for an e-commerce Web site project. After a thorough evaluation, you decide that a different database server works better for your company, perhaps because you already own the necessary licenses, or because your IT staff is already skilled in the other product. That decision means you won’t be using Commerce Server, either, because Commerce Server requires SQL Server (unless you’re comfortable implementing a SQL Server solution just for Commerce Server to use). Seemingly straightforward decisions can play havoc with your design process because of the complex interdependencies between modern enterprise software. To make dealing with interdependencies easier, consider evaluating entire product sets. For example, you might do a comparison between one set which includes all Microsoft products, and a second set that includes non-Microsoft products. Each set would receive an overall score based on the individual products’ scores, enabling you to evaluate a complete suite of technologies that all work together.
Make sure your evaluation takes into account everything that’s important to your organization. Here are some suggestions:
If you’re on a tight budget (and who isn’t?), you might factor price into your evaluations. Although products within a particular class tend to cost roughly the same, including pricing in your evaluations will ensure that you’re selecting the least expensive product that meets your needs.
You can include existing skills in your evaluation, too. For example, if your staff already has a lot of experience with SQL Server, then it might receive a higher score than other database products, because less training will be needed to implement SQL Server than another product.
If you’re considering products from a fairly new or little-known company, then you can include some measure of long-term stability in your evaluation. This will help you consider the risk of adopting a technology from a company that might not be around to support it in a few years.
If your environment already includes some of the technologies that you’ll need to use, then you should include them in your evaluation as well. Doing so will help you determine whether or not the existing technologies will meet the needs of your new project, or whether those existing technologies will have to be upgraded or replaced.
You may want to include a measure of each product’s upgradeability. For example, Microsoft products can be purchased with Software Assurance, which allows you to upgrade to any new versions of the product at no charge during the Software Assurance period. Software Assurance costs extra, of course, so it’ll have to be factored into the cost of the solution.
| For more information on how Software Assurance works, see “Software Maintenance,” p. 171 |
From a purely practical standpoint, you should set some kind of formal time limit on your evaluation process. Certainly, you could spend lots of time learning about new products and their features, but that’s not going to get your project off the ground any sooner. Set a reasonable time limit for your evaluation process, and find out as much as you can within that time limit.
After you complete your technology evaluation, you’ll be able to select the products you intend to use based on your scores. Then it’s time to start creating your initial designs for your project. There are a few things you should keep in mind about your initial design:
You may not yet know everything you need to know about the products you’ve selected. That doesn’t mean you need to become an expert before starting your design. Your initial design will evolve and change as you learn more, and is intended to act as a starting point.
Your initial design should include all of the prerequisites that you’re aware of, even if they’re not configured in exactly the right way. Getting everything onto a piece of paper is the best way to start rearranging it to work better for you.
The initial design should serve as a basic checkpoint to make sure that the solution you’re building meets your original business needs. If changes need to be made to address business needs, it’s far better—and less expensive—to make those changes while the project only exists on paper!
As your initial design evolves, save every version of it that you create. You may want to just keep a folder with each new version, or you may want to use a system like Microsoft’s Visual SourceSafe, which enables you to check files in and out and can track the changes made to a file each time you check it in. Saving the old versions of your design will help you backtrack in case you discover any design flaws, and will provide documentation of your project’s development.
Note
Keep in mind that Part II of this book covers the design aspects of all 10 .NET Enterprise Servers. By creating an initial design now, you’ll be able to further develop that design as you learn more about the .NET Enterprise Servers’ design requirements and best practices.
For the remainder of this chapter, I’ll use Pete’s Big Beverages to create an initial design, so that you can see how the initial design process works. I’ll assume that PBB has completed the evaluation process and decided to go with an all-Microsoft solution based on Commerce Server, CMS, Application Center, and SQL Server. I’m not going to worry about the exact details of each product’s implementation, because I’ll have the opportunity to refine the design later, as I learn more about the products. For now, I just want to get a basic design on paper so that I have something to work with.
In my consulting practice, I find that very few companies have really good documentation for the existing network environments. If you do, fantastic! If not, you’ll need to spend some time documenting your existing network before you can start adding to it.
Tip
If your organization uses Microsoft Systems Management Server (SMS), it can help document your network. SMS 2.0 introduced a network discovery feature, which enables the software to find out what’s on your network and generate a network inventory and diagram for you.
The key things to document from your existing environment include
How many network segments you have, how many computers are on each, and how they are all connected.
IP addressing information for each segment.
Where your network servers are located, what function each one performs, and how clients connect to them.
How your computers connect to the Internet, and the location of any devices such as firewalls.
Figure 4.7 shows the existing network configuration for the Denver office of Pete’s Big Beverages, which is where the new Web project will be implemented. The network consists of five segments. Four of those segments include client computers, which are divvied up across the segments by department. The fifth segment includes all of the company’s servers. All of the segments are connected to one another by a router. The fifth segment also includes a firewall, which provides access to the Internet for company employees.
Your existing network diagram may call attention to some design flaws. As networks grow and add services, the network design isn’t always revised to properly accommodate those changes. In the case of PBB’s network, for example, the firewall is connected to the fifth network segment. That means all Internet traffic will place traffic onto the server segment, which is inefficient. Also, the company’s public Internet Web servers are on the same segment as internal file servers—another unnecessary traffic burden on the server segment, as well as a security risk, since the file servers are more easily accessible to the Internet.
Prior to introducing any new services to your network, take the time to correct any existing design problems. For example, Figure 4.8 shows how PBB’s network could be revised to better separate different types of traffic. The firewall could be connected directly to the router, allowing the router to get traffic to and from the firewall without placing traffic onto an intermediary segment. Also, the Web servers can be moved to their own segment, which keeps them from impacting the internal network servers.
When you’re happy with the condition of your network, you can make a first pass at adding your new servers and technologies.
Tip
Don’t bother actually reconfiguring your network after each change to your design. Instead, get all of your changes down on paper. Once you’re happy with the design on paper, you can make a single set of actual changes to your network. This technique will reduce the impact of your design changes on your users, reduce network downtime, and reduce administrator headaches.
The goal of your first-pass design is to simply get all of the new servers and technologies on your diagram, so that you can examine their potential impact and evaluate any additional changes that might be needed on your network. Figure 4.9 shows the first-pass attempt for PBB’s network. New items are shown in boldface text, and include
A new Web server running Commerce Server, which will act as the company’s new internally hosted online store.
The addition of Application Center to the company’s existing Web servers.
The addition of SQL Server to support Commerce Server and the data consolidation project.
The addition of Content Management Server to address Web publishing workflow issues.
After completing your first-pass diagram, examine it for potential flaws. In general, you’re going to be looking at four major areas of concern:
Prerequisites. You need to make sure that the network contains all of the prerequisite items required by the servers that you just added.
Security. Examine the network to see how intruders might use your design against you. Also consider how you’ll protect sensitive information from internal intruders.
Administration. How will you administer the various services of your network? Will firewalls, segment issues, or other problems make administration difficult? How will end users on your network administer their portions of the new services? For example, will users be able to efficiently access new services?
Performance. Does your new design contain any obvious performance flaws? Will clients have to traverse an unnecessary number of network segments to access new services? Will new services place an undue amount of additional traffic on existing network segments?
You can probably examine Figure 4.9 and spot a number of potential design flaws in security, administration, prerequisites, and performance. Your next step is to modify your first-pass design to address those flaws.
Think carefully about how you plan to use your solution to address your business needs. For example, review the business needs that PBB is expecting to address:
Most of the regional bottlers rely on printed company newsletters to receive updated information about upcoming marketing campaigns and other news. This method is slow and unreliable, as the printed newsletters aren’t always disseminated throughout the bottlers’ offices.
PBB will address this issue by hosting a private Web site on their Commerce Server computer. They’ll create a separate Commerce Server site that uses Active Directory to authenticate bottlers, and use Content Management Server to publish content to the Web site.
The company uses a number of old, custom-developed applications for various purposes. These applications often duplicate data, which is inefficient. Even worse, many new projects could make use of the applications’ data were it available in a central location that was easily accessible from across the company’s network.
PBB will address this issue by using SQL Server DTS to consolidate data on a regular basis. New projects can use the consolidated, SQL Server-based database as a data source.
The process for publishing new content to the company Web site is overly complex. Content developers and editors start in Microsoft Word. Once approved, their content is sent to an HTML developer, who places the content into the company’s standard Web templates. The final Web page is sent back to the author and editor for approval, and then to the Web site manager for approval. Finally, the content is sent to a Web technician, who deploys the content to the production Web site.
PBB will address this issue by implementing Content Management Server, and using its workflow and publishing capabilities to manage the Web publishing process.
The company’s Web-based store is partially hosted by an outside company. While the store’s main Web pages are hosted by PBB, pages that actually complete sales transactions are hosted by the outside company, who maintains an e-commerce infrastructure. This process often results in customer confusion, and makes it difficult to update the transaction pages whenever the look of the main Web site changes.
PBB will address this issue by moving the Web store in-house, to a new Commerce Server computer. The Web store doesn’t currently receive a lot of traffic, so it will be collocated on the same server that hosts the online bottlers’ newsletter. However, the store will be set up as a separate Commerce Server site.
The PBB Web site features an email list, where visitors can sign up to receive email product discounts, news on upcoming promotions, and so forth. Currently, the Web site places new subscribers’ email addresses into a database. When an email needs to be sent to the subscriber list, it takes the efforts of a writer, editor, HTML coder, database administrator, and network administrator to get the list out on time.
PBB will address this issue by using Commerce Server’s Direct Mail system. The newsletter will be integrated with the new, in-house online store. Customers will be redirected from the main Web servers to the Commerce Server computer in order to subscribe to, or unsubscribe from, the email list.
PBB runs several Web servers. Managing and maintaining those servers consumes a lot of time. Also, since the Web site has occasional spikes in traffic, PBB might benefit from some way to easily and quickly increase the site’s capacity.
PBB will address this issue by adding Application Center to the environment. A single Application Center Web cluster will allow all four Web servers to be managed as one, and will allow new Web servers to be added to the Web farm to handle anticipated traffic spikes. Web content will be developed and tested on internal Application Center clusters and deployed to the production cluster.
Given that information, PBB’s first-pass design is missing some important prerequisites:
A domain controller will be needed to support bottlers who need to log on to the new online newsletter. This domain controller will probably be in a separate or child domain, so that the bottlers’ user accounts can be managed separately from PBB’s internal user accounts.
Given how Application Center will be used, two internal clusters—for development and testing—will be required. These clusters can consist of a single Web server.
Figure 4.10 shows the revised network, which includes the newly identified prerequisite items.
Your next step is to make a thorough evaluation of your new solution for potential security flaws. I’ve found that a lot of administrators tend to work on administrative and performance concerns first, and then address security. However, I’ve always felt that security should be the overriding factor, and that performance and administrative concerns should be addressed only within the context of a secure environment. Here are some security flaws to watch out for:
If you’re letting Internet traffic into your network, the segment it hits should contain as few private resources as possible.
Any segment that accepts traffic from the Internet should do so only through a firewall, and should be protected from the rest of the network by a second firewall.
Remember that firewalls can be configured with as many access rules as necessary to meet your needs. Don’t be afraid of splitting your network up and relying on a firewall to get traffic to the right spot.
With those considerations in mind, revisit the PBB network diagram in Figure 4.10. Where are the potential security flaws? Here are some of the obvious ones:
Internet traffic is being directed through the internal router to the segment containing public Internet servers.
Public servers—such as Web servers—and private servers—such as SQL Server and a domain controller—are located on the same segment, which exposes the private resources to potential attacks.
The segment that is accepting Internet traffic isn’t protected from the rest of the network by a separate firewall.
Figure 4.11 shows a revised PBB network, which corrects the major security flaws. Segment F, which contains the public Internet servers, is now connected directly to the firewall. The firewall can be configured with rules that only allow incoming traffic to go to Segment F, while still allowing internal client traffic to go to the Internet from the internal router. A new Segment G has been added to contain the private servers which support the public servers, and they are protected from the Internet traffic on Segment F by a new, independent firewall. That firewall can be configured to only permit traffic between the public Web servers and the appropriate private servers, but to not allow traffic directly from the Internet to pass through to the internal network.
Note
Creating a network segment which is accessible to the Internet and protected on either side by firewalls is a common security practice. The segment is sometimes referred to as a demilitarized zone, or DMZ, since it allows filtered Internet traffic to enter, but protects the main network from all Internet traffic.
Your next step should be to ensure that your new network design can be managed and used in the way it was intended. So far, PBB’s network design meets some administrative needs, but falls short on others. Reviewing the original business requirements will help make the current design flaws more obvious:
Users must be able to access the SQL Server computer in order to take advantage of the consolidated data. Also, SQL Server needs access to the existing file servers in order to perform the data consolidation. The current design should allow both types of access, since SQL Server is included on the main network.
Users need to be able to access the Content Management Server computer for Web publishing. Since that server is located on the internal network, there should be no problems. However, including the server on Segment E doesn’t make much sense, since the entire network may need to access the server.
Commerce Server needs to access SQL Server and the domain controller. This might represent a problem, because the firewall is currently blocking traffic between segments F and G. One solution might be to configure the firewall to allow the necessary traffic to pass between the servers on Segment F and the servers on Segment G.
Managing the resources on Segment F is going to be difficult because of the firewall separating Segment F from Segment G and the rest of the network. While you could configure the firewall to allow the necessary traffic, administration requires a number of different network protocols, and configuring the firewall to permit them all will be complex and time-consuming.
Figure 4.12 shows a potential solution: moving the CMS computer to Segment A, along with the rest of the servers, and adding a virtual private network (VPN) server to Segments A and F. Internal clients can direct traffic intended for Segment F at the new VPN server. The VPN server then tunnels the traffic though the firewall—requiring only a couple of ports to be opened—and delivers the traffic to the VPN server on Segment F, which un-tunnels the traffic and places it onto the segment. Return traffic takes the opposite path. Careful configuration of the client computers and the computers on Segment F will make the VPN work, while preventing Internet traffic—which won’t know the correct internal IP addresses to use—from entering the tunnel and the internal network.
| For more information on how VPNs work, see “Communications Security,” p. 642 |
Note
In Figure 4.12, I’ve reduced the size of the client segments—B, C, and D—to help make the diagram clearer.
Your final step should be to examine your network for any obvious performance flaws. PBB’s network looks like it’s in pretty good condition based on Figure 4.12, since all of the servers are located on a single high-speed segment, which is equally accessible to all network clients. One potential area of concern is Segment F. Application Center actually requires two network cards in each server in order for load balancing to work; selecting the correct network media for each network segment can therefore play a vital role in performance. Figure 4.13 shows the PBB network’s DMZ in more detail. Segment F actually consists of two network segments, F-1 and F-2. Segment F-1 connects the Web servers to the Internet, while Segment F-2 connects them to the internal network, in both cases through a firewall. Segment F-2 also houses the VPN server that allows internal traffic to come and go. While it makes sense for Segment F-2 to use a high-speed fiber-optic network (just as Segments A and G do), fiber might be overkill for Segment F-1. Segment F-1 isn’t going to be able to get traffic out any faster than 1.544MBps, which is the speed of the T1 line connecting the network to the ISP. Using a less-expensive 100MBps Ethernet network will provide more capacity than the T1 bottleneck. Even a very inexpensive 10MBps network can support more traffic than the T1 can.
With your finalized initial design in hand, go back over your original business needs. Make sure that your design seems to meet those needs. For example, how does PBB’s initial design address the company’s original business needs?
Most of the regional bottlers rely on printed company newsletters to receive updated information about upcoming marketing campaigns and other news. This method is slow and unreliable, as the printed newsletters aren’t always disseminated throughout the bottlers’ offices.
The design includes Commerce Server and an Active Directory domain controller. Together, these will allow bottlers to authenticate to a private Web site, which can be used to host an up-to-date electronic newsletter. Using Commerce Server to host the site—instead of just IIS—will allow the site to eventually grow to support electronic business-to-business transactions.
The company uses a number of old, custom-developed applications for various purposes. These applications often duplicate data, which is inefficient. Even worse, many new projects could make use of the applications’ data were it available in a central location that was easily accessible from across the company’s network.
Since Commerce Server requires SQL Server, this particular business need can be addressed by utilizing SQL Server for the additional purpose of data consolidation. SQL Server’s DTS features will have access to the file servers on Segment A of the network, allowing DTS to consolidate the distributed data into a single database. Since the SQL Server is also accessible to the rest of the network, the consolidated data can be used as the data source for the new projects.
The process for publishing new content to the company Web site is overly complex. Content developers and editors start in Microsoft Word. Once approved, their content is sent to an HTML developer, who places the content into the company’s standard Web templates. The final Web page is sent back to the author and editor for approval, and then to the Web site manager for approval. Finally, the content is sent to a Web technician, who deploys the content to the production Web site.
Content Management Server’s workflow features will streamline and automate the Web publishing process. CMS will publish to the development or testing clusters located on Segment E, which will then use Application Center to actually publish the content to the product Web servers.
The company’s Web-based store is partially hosted by an outside company. While the store’s main Web pages are hosted by PBB, pages that actually complete sales transactions are hosted by the outside company, who maintains an e-commerce infrastructure. This process often results in customer confusion, and makes it difficult to update the transaction pages whenever the look of the main Web site changes.
Commerce Server will be used to implement an internally hosted online store. Although only a single server will be used at first, the design can be easily scaled to support more traffic by simply adding additional servers and beefing up the back-end SQL Server computer.
The PBB Web site features an email list, where visitors can sign up to receive email product discounts, news on upcoming promotions, and so forth. Currently, the Web site places new subscribers’ email addresses into a database. When an email needs to be sent to the subscriber list, it takes the efforts of a writer, editor, HTML coder, database administrator, and network administrator to get the list out on time.
Commerce Server’s Direct Mail system will provide the necessary list management and email sending capabilities.
PBB runs several Web servers. Managing and maintaining those servers consumes a lot of time. Also, since the Web site has occasional spikes in traffic, PBB might benefit from some way to easily and quickly increase the site’s capacity.
Application Center will allow the production Web servers to be managed as a single unit, and will take care of deploying content to the servers from the internal development and testing Web servers, which will also run Application Center. In the event of a traffic spike, new servers can be added to the Web farm, and Application Center will automatically configure them with the necessary Web content to help handle the additional traffic.
If you can’t describe how each of your business needs are met by the initial design, spend some more time revising the design until all of your business needs are covered.
As I’ve mentioned, your initial design is just that: Initial. Preliminary. Not done. As you learn more about the products you’ve selected, you’ll tweak your design to make the best use of those products. For example, as you learn more about Commerce Server, you might feel that PBB’s Direct Mail needs won’t be ably met by a single server. That might mean adding one more Commerce Server computer, and possibly an additional SQL Server computer, to handle the Direct Mail function. If these email campaigns are important enough, it might make sense for PBB to implement a Windows cluster, so that a server failure won’t stop the email from going out. You may also want to re-evaluate the scope of your solution, and decide that additional capabilities offered by a particular product are worth implementing. Be careful, however, of scope creep, which occurs when a project just seems to get bigger, and bigger, and bigger. Keeping the project’s scope under control, and expanding it only for valid business reasons, will help keep the project on time and on budget.
| For more information on Windows clustering, see “Windows Enterprise Technologies,” p. 87 |
The point is that your design is always open to question and change until you’ve gotten the last detail nailed into place. Don’t be afraid to redo entire sections of your design as you learn more about the products you’re working with, since it’s far better to revise on paper—which is cheap—than to revise in real life—which is expensive and time-consuming.
In this chapter, I introduced you to a basic methodology for determining your business needs, evaluating technologies against your business needs, and selecting technologies that best meet those needs. You also learned how to create an initial network design that specifically addresses your business needs, and to keep those needs at the front of your mind as that initial design grows. Part of your design’s evolution will include security, performance, and administrative factors, ensuring that your new solution meets not only your business needs, but also provides a safe, manageable, and stable environment that your business can rely upon.