ActionScripting in Flash MX

1.2 An overview of the design process

1.2.1 The life cycle of a design

Network designs are predominantly living entities; they rarely stay the same. Even from inception to initial implementation, a design will often change—typically because of improvements in the quality of the data about the users, applications, and traffic flows, or design changes concerning the equipment selected and delivery technologies used. The point at which a network is installed often marks the start of a new phase of design rather than the end of the process. Consequently, it is useful to think of network design as a cyclic process, as illustrated in Figure 1.1.

Figure 1.1: Network design process.

Before the design process can begin, a clear set of requirements should be established to capture what the organization and its users expect from the network and the services to be offered. The requirements should also clearly identify what the budget is and any other constraints that impact the design. The network design process then naturally follows a set sequence:

Just as with any living organism, networks have a limited life span. Over time networks become increasingly unreliable, inflexible, and unable to cope with the pressures placed on them. Advances in network technology and increases in overall traffic levels render most technology obsolete within a few short years. The lifetime of a network may be extended with the aid of transplants to vital organs (upgrading routers, links, etc.); however, there generally comes a point where the network design itself requires a major overhaul, often resulting in total replacement (at which point the cycle starts over).

Some networks are destined to age much faster than others. Since networks are becoming increasingly inseparable from the organizations they are built for, a dynamic organization can put severe strain on a design, forcing radical changes over a much shorter time than a more stable organization. Massive growth, mergers, acquisitions, downsizing, or radical new ways of working can all result in a design that is obsolete or inadequate much faster than anticipated. Networks may even be dismantled and replaced for purely political reasons; it is not unusual for one company to take over another and have the absorbed network completely scrapped (this could simply be because the new decision maker does not like the installed technology, or it could be for strategic reasons). As companies expand and diverge, merge with other companies, and change their product focus and distribution methods, so too must the network.

1.2.2 Establishing requirements

To design and implement any new network or enhance an existing network, there must be two things: a requirement and a budget. At the early stages both elements may be quite loosely defined; without both in place and a willingness to expend effort in developing both, there is little point in proceeding. Large organizations that are very technology aware often have a rolling process of requirements and budgetary planning; to these organizations this comes as second nature and is fundamental to their business. Organizations that are less technically competent may have only the desire to improve matters and a willingness to spend money on it. Even so, in both cases the aims are the same—they just differ in the level of granularity. The job of the network designer is to cooperate with others in translating these wishes into a set of specific requirements, so that expenditure can be justified and appropriate technical choices can be made.

Engaging end users

Network engineering staff members often spend very little quality time with end users. The two groups may only interact when there is a serious problem, and then the engineer often feels outnumbered in a sea of angry users who are not the slightest bit interested in why the ISP router is down—they just expect service. On the other hand, users may have waited for hours to see any sign of progress, while business is being lost, commissions are being eroded, and angry customers are ringing in with complaints. Users often expect miracles; engineers often need them.

The design phase of any new network project is, however, a time for engaging user groups. It is important that the real users of the network and its services be involved from the start. Users are best placed to give feedback on how the applications should perform, what the current problem areas are, and what they like and don't like. Without user input you risk making fundamental errors with your design assumptions; by involving users throughout the transition you will achieve a much better buy-in (you really don't want to install a completely new infrastructure to find out that the users hate it). Having said this, user expectations need to be managed and prioritized. It is important that expectations are clearly defined, understood, and realistic. Before undertaking a design there should be a clear set of objectives visible to all interested parties.

Translating the requirements

Most reasonable-sized networks today are subject to a fairly formal process of specification. Requirements should ideally be specified from the top down. We start with the business objectives, and then refine these objectives by tighter specifications of what the business expects, what users expect, and any constraints that will be imposed on the designer. As part of the requirements specification process, it will become apparent that the requirement itself will be expressed in very different ways at different levels within the customer organization. At the board level, the requirement may simply be to increase adoption of client/server technology over the next three years to gain competitive advantage and achieve best practice.

While this may be the ultimate truth for a senior executive, it means very little to an engineer. The finance director may have his or her own requirement: to sustain a 35 percent return on investment while minimizing capital expenditure within this fiscal year.

We may have lost a few more engineers by this point. Joking aside, these are genuine requirements and must be translated and formulated into a set of specific requirements, aligned with the application strategy, user expansion plans, site geography, and available technology. The trick is to do all this without losing sight of the original business reasons for making the changes.

All too often the requirements come from the ground up. The network has been falling apart for several years, aided by an army of maintenance engineers performing artificial resuscitation on a daily basis, until new traffic levels and the loss of two key engineers finally bring the matter home. This is not a good start for a network design project, since the pressure is on to fix things quickly and there is unlikely to be a sensible budget in place (since clearly no planning has taken place). My advice here is to place a temporary bandage over the network while going through a full requirement and design process in parallel; otherwise, you could be throwing good money after bad.

Phasing the requirements

There is always a danger of overspecifying requirements too early, to the point where the requirements are simply unachievable. This is a particular problem if the authors of the requirements have very little knowledge of the networking technology. For example, a customer might express a requirement as follows: It is mandatory that all routers supplied should be supported and upgraded for the next ten years to incorporate new standards-based features and protocols.

Now, if you were investing serious money on this project, this might seem perfectly reasonable, but to most suppliers it appears impossible, or at least highly unattractive, for a number of reasons. Hence, requirements specification is generally a multistage process, starting with a fairly loose sense of direction and then progressively tightening the requirements as ideas firm up. It soon becomes apparent what is reasonable and what is achievable, as follows:

Once a final supplier is chosen, this supplier will be invited to finalize design and to produce final equipment lists and finished schematics for every location. There may be some adjustment of pricing based on functionality. For large networks the supplier is normally responsible for the entire project plan, specifying exactly how and when various components will be installed and tested.

Note that this is far from an exact science. Different organizations will approach the process in various ways. Some may require a long, drawn-out process with many intermediate phases (typically, government organizations); others will feel sufficiently comfortable to issue a detailed requirements specification to a small number of suppliers at the outset, and then go straight to final design with a chosen supplier.

Designing the requirements

The process of developing and gauging responses to requirements specifications is typically done either within the customer organization or between the customer and some third party (e.g., a consultancy group or in some cases even a potential supplier). In practice only large, well-funded organizations (e.g., large financial institutions, large retail organizations, or national service providers) tend to employ their own full-time design experts, who are capable of fulfilling this role. For those organizations that do not have the necessary skills in-house but have financial resources, there are many highly skilled consultancy groups able to take on the task as a contract project. For organizations that have neither the skills nor sufficient budget for external consultancy, often the answer is to pick the safest vendor (usually the largest) and use the vendor's internal design skills as part of the sales offering. Vendors will often provide a cut-price design service in order to win the business. In the latter scenario the customer is really at the mercy of the supplier, and it usually pays to get at least some independent advice during the process as a final sanity check, especially if you are not dealing one of the major suppliers. If the network design is suboptimal, the customer will end up paying for it over and over again.

Requirements should be structured in such a way that associated topics are grouped by function (e.g., network management, routing, cabling, etc.). Individual requirements should be concise, unambiguous, and measurable. All requirements should have a reference number. Once you have a complete set of requirements, go through each item and prioritize, according to following criteria:

Take care to ensure that all mandatory requirements are actually achievable; otherwise, you run the risk that no one will meet the basic requirement. In the short-list stage it is likely that the responses to the highly desirable questions will strongly influence who the preferred supplier will be (assuming that the responders meet all mandatory requirements and all responses are within budget). From a vendor perspective it is often instructive to pay particular attention to any requirements that appear implementation specific; they often indicate that a competitor has been overly helpful in the drafting of the document or that there is strong product bias, either with the customer or with the authors of the document. Customers should be aware that vendors, if allowed access, may use this process to disable the competition (hopefully with greater subtlety).

Assessing the requirements

In practice, the assessment phase is often part scientific and part instinctive. Aside from cases where the customer is required by law to choose the cheapest solution that meets all mandatory requirements, the process is normally a combination of assessing the true costs of deployment, some form of weighted evaluation matrix, and the much less quantifiable element of whether the customer feels comfortable with the supplier. For obvious reasons we cannot deal with the latter here; comfortable means different things in different parts of the world.

The true cost of the network needs to be fully explored in detail. Items for consideration include support and maintenance, depreciation, commissioning costs, project management fees, hardware and software upgrade costs, circuit bandwidth charges, ongoing consultancy charges, whether current prices are fixed against future changes in the price list, and so on. It is important to remember that this is not a one-off purchase; significant network costs are due annually, so when comparing solutions this needs to be done for a period of at least three, and ideally five, years. What may initially be the cheapest solution may be far from it when calculated over the lifetime of the network. We dealt with cost modeling in detail in Chapter 4 of reference [1].

In assessing the specific requirements you should create a weighted matrix (e.g., using a spreadsheet) to clarify the responses and provide a quantitative view of the various responses. A simple weighting scheme is shown in Figure 1.2. The supplier with the lowest rank and the highest score will be most compliant. Note that this example is purely for illustration. Superior statistical analysis techniques are widely available and recommended.

Supplier ID: KWPK Micronetworks Associates

Ref

Pri

Description

Status

Mfail

Weight

Mult

Score

1.1

M

Supplier must have approvals for shipping to Europe and USA

FULL

0

100

1.0

100

2.1

M

Routers must support RIP, OSPF and BGPv4

FULL

0

100

1.0

100

2.1

H

Router must support OSPF unnumbered links

FULL

0

10

1.0

10

2.2.1

M

Router must support Ethernet, ATM and Token Ring interfaces

PART

1

100

0.5

50

2.2.2

H

Router must support Load balancing over serial links

NONE

0

10

0.0

0

3.1

M

PPP and HDLC are required for wide area encapsulation

PART

1

100

0.5

50

3.2

M

Modem dialback to be supported for secure remote configuration

FULL

0

100

1.0

100

3.2

H

Support for software update mechanisms across the network

FULL

0

10

1.0

10

4.1

D

Statistics mainained on routing and spanning tree convergences

FULL

0

1

1.0

1

4.2

D

An audit trail must be supported

FULL

0

1

1.0

1

5.1

M

Management system must support multi-users plus access levels

FULL

0

100

1.0

100

TOTAL SCORES

 

2

632

9

522

RANK

    

17

Figure 1.2: Sample requirements analysis.

In the unfortunate event that all suppliers fail to meet all of the mandatory requirements you may have to consider whether the requirements were really achievable or whether to reissue the document to a wider set of potential suppliers. Either way, with this approach you will be able to measure the best responses systematically.

1.2.3 Information gathering

Once you are clear about the business and user requirements, you must initiate research to characterize the behavior of the users and applications and where they are to be located. Clearly, this information is vital for understanding traffic flows over the network and will ultimately impact cost. It is important, therefore, that you attempt to be as comprehensive and accurate as possible during this phase, since poor-quality data could lead to poor choices being made later on. Ideally we want to build a database of information, such as the following:

Depending upon whether this is a new design or a modified existing design, you will face different challenges when attempting to collate some of this information, as follows:

The list presented here is far from exhaustive, since the relevance of these data will vary by project. However, by starting to capture information concerning issues presented here it will quickly become clear which information is most important and the level of detail required. In Chapter 2 of reference [1] we worked through a process of systematically refining and presenting this information to create a formal database called the capacity plan.

1.2.4 Planning

By this stage you should have established what the requirements are, and there should be a database of all relevant information concerning users, services, hosts, and how those entities interwork. The process typically starts with a rough conceptual design, often using a whiteboard. At this point the designer must remain open to making changes later on, since firm decisions made at this stage generally result in a design that is far from optimal. The conceptual design is repeatedly analyzed and refined until it begins to make sense. It may be appropriate to consider a number of local and wide area technologies, different equipment vendors, and possibly different application vendors. Choices in any of these areas can completely change the direction of the design.

Technology choices may be directed by pragmatic issues, such as the geographic relationships between sites, services, and users or the region of the world where the network is to be deployed (e.g., a developing country may have only a single service provider offering low-bandwidth leased lines). Such factors often simplify the design, and, although the results are not optimal, such compromises are common in large-scale international network design.

Through an iterative process involving brainstorming sessions, design reviews, and possibly the use of modeling tools, a detailed design will eventually emerge that meets all (or at least most) of the performance and cost constraints and delivers the expected service levels outlined by the requirements specification. This is unceremoniously referred to as the final design (although in practice this tends to be the first draft of the real final design).

The design specification

A network design is just a bunch of ideas in somebody's head unless there is detailed documentation describing that design. The network design specification not only communicates that design, but it also acts as a benchmark for changes made to the design. If there were good reasons for the design choices made in the final design, then there must be equally good reasons for changing that design, so all modifications to the design specification need to be documented together with appropriate justification.

Changes are often made at the commissioning stage that are not reflected back into the design specifications. Failure to record the change history can have serious consequences for the maintenance staff later on. Strong project management can help, and all key personnel in the organization should be regularly updated with current network diagrams and configuration data, and these data should be archived and easily retrievable. Above all, an accurate network design specification must be maintained. The penalty for not maintaining knowledge is at best the cost of retraining all key staff and at worst the job of redesigning the entire network so that the new staff can make sense of it (and this does occasionally happen).

The early stage conceptual design might be fine to get things moving, but ultimately you need detailed documentation to support the design, and it needs to be in a format that can readily be archived and distributed electronically. The design should ideally be presented as a top-down series of schematics, with accompanying documentation explaining the overall design concepts and individual configuration aspects that are significant. Documentation should include the following:

Armed with a network design specification, we can now begin to implement the technology.

1.2.5 Implementation

Successful implementation of the design depends upon many factors. At the outset it is vital that there is a clear project plan identifying all key activities, who will perform them, and when they will take place. From the business perspective, and for many other pragmatic reasons, any new technology should be introduced in a phased approach, as follows:

Feedback must be taken at each level and either resolved by making explicit changes or by explaining what the limitations are and agreeing on possible future enhancements. It is important not to move between phases without getting consent from all interested parties. A clear head is required for the final deployment stage; on a large network installation, particularly when replacing existing infrastructure, there often comes a point of no return, and nerves may be stretched to the limit. There are no prizes for delivering a malfunctioning network regardless of how much effort has been put in to it.

Категории