Building Networks - Basic Design Guide
Welcome to Educational Networks by HSdataline
Designing a network is as complicated or as simple as the architect desires it to be. There are multiple methods for network design, ranging from “Get it Done!” to “The Equipment’s Here!” to a planned and defined approach using established methods and models. (Glossary of Terms)
A Basic Network - Flash Presentation - Click on Image Objects
Requires Flash V8 Download Here
There is no right or wrong methodology for designing a network or system. Each system or network is unique and requires different solutions and methods for design. Today, network and system architects generally use one of three methods to develop network architectures and system solutions: the Scientific Method, the Discovery Method, or the Requirements-driven Method. A fourth approach that meets all of the general design and architectural requirements is a merging of the three stated methods. This fourth approach is referred to as the Tried and True Method.
Scientific Method
The Scientific Method described here is the same method used for physical and theoretical scientific efforts. The process flow begins with the formation of a hypothesis, followed by testing the hypothesis, then revising the hypothesis based on experimentation, which results in a theory or stated fact. This method can be applied to a network or systems design using the same order of processes.
To fully design a system or network, the base hypothesis must be a suggested solution for the stated requirements. For example, the issue or problem involved may be the need to send and receive secure data between multiple locations at the same and differing times. The clear solution is a network of multiple nodes with a technology to control message traffic and delivery.
The next step is to assemble the information necessary to support this hypothesis. A Requirements Analysis provides an in-depth understanding of the problem and potential solutions. Multiple managers and workers reviewing the requirement may discover a rudimentary network or system. Conversely, further analysis of the requirements may identify no existing solution, but help to further define the problem by including batch data processes and financial reports.
An additional step is to survey current assets. This survey identifies existing equipment that may be re-used for the solution/hypothesis. The summary should then identify further details of the requirement, such as scheduled messages and routine messages with low priority of delivery.
The next step develops experiments, both “on paper” and in a laboratory environment. These experiments, sometimes referred to as “box and cloud” diagrams, depart from a typical scientific scenario, as they are specific to the telecommunications technologies and solutions. The designer seeks to solve all the technical and non-technical issues that surround the problem by applying equipment and system features. These diagrams and suggested solutions include equipment and operational costs.
The designer selects whichever solution and design scenario best supports the hypothesis, which is then reviewed by both the client and the engineers. If the solution does not meet the full requirements, or if the requirements have changed, then engineers must redefine the hypothesis, which includes an amended solution and set of components and costs.
Once arriving at an acceptable solution, engineers can construct a test network or system to apply the scenarios to the hypothesis for proofs. During this testing phase, they document modifications and changed requirements. These can then be used to refine the solution until it meets and resolves all requirements and issues.
This method takes the longest to implement and incurs the highest cost, because each solution is tested in a lab prior before being presented to the client. In this step alone, the designer or architect incurs a minimum set of operational and test equipment costs, which include expenses for test engineers as well as facilities. Time is another cost, as this method requires an extended period of time for the planning, testing, and review phases required to construct an acceptable solution.
Discovery Method
The Discovery Method is a very client-intensive and inclusive process. Generally, the client has an initial understanding of the problem or issue to be solved, but does not have the detailed knowledge to select or design the proper solution. This method is best when the client expects to be completely involved in a team situation.
The discovery process begins with management interviews to determine the direction and scope of the desired network solution. This step results in a business direction and solution, based on the business needs and costs. The design team documents, catalogs and reviews the interviews, keeping an eye out for commonalities to help determine a consensus for the solution. This step clearly identifies the problem and provides the design constraints necessary for implementation.
Management interviews typically overlook “on-the-ground” operational or inherent system processes that are implemented either informally or as stopgap measures. To capture the complete picture of how the existing systems and applications apply to the defined problem, engineers should also interview the operational staff and survey the existing equipment.
As the problem becomes more clearly defined and the management interviews provide the cost and operational design constraints, an equipment survey proves all the more necessary. The equipment survey identifies obsolete or less than optimum equipment implementations and processes. These results are compiled and reviewed against the originally defined problem. The findings may provide the primary solution for the defined problem/issue. Additionally, the survey and review further identify which full network or systems operations and processes are in use, which may need to be refined as part of the solution. These solution and survey finding refinements can drive a redefinition of the original problem.
Once all the interviews and surveys are complete, the designer then fully documents all findings, reviews them for consensus and/or similarities, then provides a high-level report to support or modify the proposed solution. In some ways, this is similar to the suggested solutions (experiments) of the scientific method. However, a major difference is that in the scientific method, the business constraints for cost recovery and savings drive the solution. Here, the designer then submits the suggested solution to the client for review. Additionally, they may repeat the step for management consensus.
In this method, the designer provides and develops application and business practice models. These draw primarily from the interviews and surveys, with the intent of using the existing computer assets.
This method is more time consuming, very client intensive, and results in a lower percentage of new equipment or applications that need to be purchased. The interviews and surveys depend on the availability of the staff and management. This places the implementation timeline somewhat outside of the designer’s control, which can significantly delay the design and ultimate solution implementation process. Additionally, reconfiguration and software/application updates can disrupt current operations, resulting in lost revenue to the client.
Requirements Driven Method
The third methodology for network and systems design is Requirements Driven. There are two scenarios in which this method is best applied: for an existing network with problems or a new network.
When an existing network has a clearly defined problem, a requirement in this scenario is generally defined as either a new or repair/fix of an existing network. In this case, the client determines specific cost parameters, business processes, and applications to be supported and adhered to.
The second scenario is more focused. A specific problem needs to be solved and a new business process, application, or network delivers the solution. Here the client provides the business case, direction, cost parameters, and processes to be used in implementation or design.
In either case, the requirements are clearly delineated and specified, and are documented as part of the initial planning. This method uses some of the same steps as those illustrated in the previous two methods. These include defining the problem, spelling out the requirement, documenting and analyzing existing resources and assets, performing replacements and applying updates, and adding minimum new equipment and applications.
Because the problem is clearly defined, designers can use surveys and inventories of the existing equipment and services to focus the design. This focus can prioritize the solution based on replacing obsolete equipment and assets.
Upgrading the applications and equipment is another aspect of this design method. Preserving the client’s equipment investments and operational processes is paramount to the solution design. The rule of thumb in using this methodology is to add new equipment only when necessary.
Designing a new network further reduces these steps to defining the requirements, developing a point-by-point solution for each requirement component, solution costing, and acceptance and implementation.
These steps focus exclusively on client requirements and restrictions, and there may not be any equipment or applications to draw from. Business processes may be in place as manual or standalone services. In the case of a requirement-driven design, the requirement becomes the baseline that drives the design.
This process is best implemented by breaking the requirement into component parts, developing and testing individual solutions before they are amalgamated into a network. In this scenario, the process flow is nearly the same as that of the scientific method, but because the requirement is clearly defined and can be directly resolved, multiple reviews and feedbacks are unnecessary.
Tried and True Method
The Tried and True Method for designing networks and systems draws from all three of the previously mentioned methods. This design method uses five components or phases: defining requirements; surveying existing systems and applications; reviewing “proven” products; testing equipment and application proof of concept; and developing an integrated design and tests. Here, the designer develops a high-level solution based on the requirement and a review of the technologies available.
The purpose of the initial requirements definition is to understand the business model and the cost constraints. These points drive the solution model to meet the requirements and can provide a revenue generator for the client. The steps leading to a requirements definition result in a hypothetical model for the solution. The first step defines the business needs and matches applications to the business needs in a prioritized manner. From this exercise, the designer selects new or upgraded equipment and applications to meet current and future business needs.
To support the high-level solution, the designer reviews the existing system and performs an applications survey. This presents a true view of the network, as well as the applications and processes it supports. The survey also reveals any weak points, such as obsolete equipment or outdated applications and processes.
By using the survey process for existing systems, applications, and processes, the designer obtains an existing hardware and systems inventory. This inventory identifies obsolete or outdated equipment and applications. The designer’s survey also results in an application list that includes all versions and revisions. This identifies whether the applications are current and includes the features for the client’s requirements.
The designer validates the equipment and application survey by interviewing current operations and application managers. This process must include interviews with focus groups of all users of the most critical applications and services. These interviews clarify the actual implementations and use of the resident applications and services. Additionally, the interviews identify ad hoc applications and work-arounds, which can then be included in the working model for the solution.
With the results of the equipment and application survey, the designer compares and reviews new “proven” products to update or replace obsolete or outdated equipment and applications. Proven products are those that are general release to consumers and use all the features the client needs. A general release product is that which has been through testing and acceptance trials by other consumers, has been approved, and is now deemed a completed product ready for delivery and installation.
The designer can prioritize existing hardware, systems, and applications by dates of installation and revisions. Based on this priority list, the designer evaluates new applications, equipment, and updates and should meet with product providers to determine the latest available and “proven” products. This includes enhancements to the existing systems as well as new products. The primary rule of thumb in this method of solution design is: NO BETAs. In essence, only accept what the product providers have available at the time of evaluation, not the next generation or release.
After selecting the necessary upgrades and updates, coupled with new products, the designer performs equipment and application proof-of-concept testing. The tests are specifically targeted to the requirements. The designer develops test criteria for new applications, systems, and hardware, reflecting the legacy integrations and enhanced features or new equipment and/or applications. The client should participate as the test drivers. These client tests apply known business problems to the solution model, which can reduce the test costs and time.
Completion of the product-to-requirement tests allows the designer to develop an integrated design using combined new and existing equipment and applications. This design incorporates adequate and “future- ready” existing systems, hardware, and applications. The key component for the solutions model design is providing for enhanced systems, hardware, and applications that incorporate new services and revenue prospects for the client.
The result of this method is a full design specification, which includes the line-item cost for each major component, subcomponent, and application. The designer produces block diagrams for application residencies, users, and processing. Sections in the design specification provide the definitions for the hardware, system, communications, and management interfaces and components.