Designing for Business Success
Overview
Every network design decision ultimately traces back to the business it serves. Understanding what a business needs, why it needs it, and what success looks like is the foundation of any effective design. This chapter examines the business elements that sit at the top of the design hierarchy and explores how each one cascades down to influence network decisions at the lower layers.
Business Success
The best place to start understanding the business needs and requirements is to look at the big picture of a company or business and understand its associated business priorities, business drivers, and business outcomes. This enables network designers to steer the design to ensure business success. As outlined in Figure 1, with a top-down design approach, it is almost always the requirements, constraints, and drivers at higher layers, such as business and application requirements, that drive and set the requirements and directions for the lower layers.
Business Priorities
Each business has a set of business priorities that are [typically based on strategies adopted for the achievement of goals. Network designers must be aware of these business priorities to align them with the design priorities, which ensures the success of the network they are designing by delivering business value.
For example, suppose a company’s highest priority is to provide a more collaborative and interactive business communications solution, followed by the provision of mobile access for end users. In this case, the collaborative communications solution must be satisfied first before extending it over any mobility solution. It is important to align the design with the business priorities, which are key to achieving business success and transforming IT into a business enabler.
An example business priority would be security. There are a number of terms used for this priority, such as Zero Trust Architecture](network-design.qmd#pervasive-security), cybersecurity modernization, and risk management framework, but the intent is the same: secure the network and maintain data integrity. If a business’s data is compromised, that business is out of business.
Business Drivers
[A business driver is usually the reason a business must achieve a specific outcome. It is the “why” the business is doing something. Business drivers are what organizations must follow: the constraints and challenges that apply to the business.
The word “constraints” here refers to the three constraint categories defined in Network Design](network-design.qmd#constraints): business constraints, application constraints, and technology constraints. A compliance requirement like HIPAA is a business constraint because it is a hard rule imposed on the organization from the outside.
An example of a business driver would be a constraint to follow a specific compliance standard like HIPAA or PCI DSS. This aligns with the business priority of security. If the business does not adhere to this constraint, depending on the compliance standard in question, the business can be fined or even shut down. For this example, the business driver could be worded as: “Required to follow HIPAA compliance standards.”
Business Outcomes
[A business outcome equates to the end result, such as saving money, diversifying the business, increasing revenue, or filling a specific need. Essentially, a business outcome is an underlying goal a business is trying to achieve, and it will specifically map to a business driver.
Returning to the security example:
- Business priority: Security
- Business driver: “Required to follow HIPAA compliance standards”
- Business outcome: “Properly maintain HIPAA compliance to stay in business”
At a minimum, there will be one outcome per driver, but there can be multiple outcomes mapping to the same driver. This is perfectly fine. If, and when, an organization achieves its business outcomes, then its business drivers are met, which ensures the organization’s business success.
Business Capabilities
Before going down the “solutionizing” path, which most engineers tend to do too early, it is important to understand what business capabilities are and how they apply to network design. Business capabilities are not solutions. Business capabilities are what you get from a solution. Most solutions provide multiple capabilities. Some solutions provide parts of multiple capabilities, and when combined with other solutions, the business can obtain a number of capabilities that will make them successful.
Session-based security is a great example of a capability that a business might need to meet compliance standards. A vendor-agnostic solution that provides this capability would be a network access control (NAC) solution. There are many different vendor-specific NAC solutions, but all of them, regardless of vendor, provide the capability of session-based security. Cisco Identity Services Engine (ISE) is an example of a vendor-specific solution that provides the capability of session-based security, and it actually provides multiple capabilities beyond session-based security.
Business capabilities map directly to business outcomes. Multiple capabilities often map to the same outcome, and multiple outcomes often map to the same capability. This is expected and perfectly fine. Table 1 shows the relationship between business priorities, drivers, outcomes, and capabilities.
When capabilities are translated into design work, they become the requirements the network must satisfy. Those requirements fall into the three types defined in Network Design](network-design.qmd#requirements): functional requirements (what the system must do), nonfunctional requirements (security, availability, integration), and application requirements (quality of experience for end users).
| Priority | Driver | Outcome | Capabilities |
|---|---|---|---|
| Priority 1 | Driver 1 | Outcome 1 | Capability 1, Capability 2 |
| Priority 1 | Driver 2 | Outcome 2 | Capability 1 |
| Priority 2 | Driver 3 | Outcome 2 | Capability 1 |
| Priority 3 | Driver 3 | Outcome 3 | Capability 3, Capability 4 |
| Priority 4 | Driver 4 | Outcome 4 | Capability 4 |
Think of each row as a story that flows left to right:
Priority (what the business wants) → Driver (the reason it must act) → Outcome (the result it is after) → Capabilities (what a solution delivers to get there)
A few things to notice in the table:
- The same driver can appear under different priorities (Driver 3 maps to both Priority 2 and Priority 3), meaning one constraint can push multiple parts of the business at once.
- The same outcome can be reached from different drivers (Outcome 2 appears in two rows), meaning there can be more than one reason to pursue the same goal.
- The same capability can satisfy multiple outcomes (Capability 1 appears in three rows), meaning one technical solution can deliver value across several business goals at the same time.
The key distinction that trips most people up is outcome vs. capability. The outcome is what the business wants to achieve. The capability is what a technical solution actually delivers. You do not buy a capability directly; you buy a solution that gives you capabilities, and those capabilities are what enable the outcomes.
Business Continuity
[Business continuity (BC) refers to the ability to continue business activities following an outage, which might result from a system failure or a natural disaster such as a fire that damages a data center. Businesses therefore need a mechanism or approach to build and improve the level of resiliency to react to and recover from unplanned outages.
The level of resiliency is not necessarily required to be the same across the entire network, because the drivers of BC for different parts of the network can vary based on different levels of impact on the business. These business drivers may include compliance with regulations or the level of criticality to the business in case of any system or site connectivity outage.
For instance, if a retail business has an outage in one of its remote stores, this is of less concern than an outage to the primary data center. If the primary data center were to go offline for a certain period of time, this would affect all other stores (higher risk) and could cost the business a larger loss in terms of money (tangible) and reputation (intangible). Therefore, the resiliency of the data center network is of greater consideration for this retailer than the resiliency of remote sites.
Similarly, the location of the outage sometimes influences the level of criticality and design consideration. An outage at a small store in a remote area might not be as critical as an outage in a large store in a major city. BC considerations based on risk assessment and its impact on the business can be considered one of the primary drivers for many businesses to adopt network technologies and design principles to meet their desired goals.
Recovery Point Objective
The amount of data that can be lost during an outage at peak business demand before harm occurs to the business is called the recovery point objective (RPO). The harm to the business can be monetary or reputation based. In other words, RPO focuses on the amount of data loss acceptable to the business.
RPO is expressed as a time value and is calculated as the gap between the last successful backup and the moment the failure occurred:
\[RPO = T_{failure} - T_{last\_backup}\]
Where \(T_{failure}\) is the time the outage started and \(T_{last\_backup}\) is the time of the most recent successful backup. The result represents the maximum window of data that could be lost.
For example, if a server fails at 2:00 AM and the last successful backup completed at 9:00 PM the previous day, the data loss window is:
\[RPO = 2{:}00\text{ AM} - 9{:}00\text{ PM} = 5\text{ hours of data loss}\]
If the business has defined an RPO of 6 hours, this scenario is within tolerance. If the RPO were 4 hours, it would not be — meaning the backup frequency must increase to close the gap.
The amount of data that can be lost from an RPO perspective is given a specific time value, measured against the last backup that took place. In most cases the RPO is less than an hour, with the average value being 10 minutes. This means a company with an RPO of 10 minutes must ensure backups occur at least every 10 minutes, so that no more than 10 minutes of data can ever be lost in a failure scenario.
Different organizations will have different RPO tolerances. A bank dealing with customer transactions may tolerate near-zero data loss, while an online retailer may tolerate a few minutes since orders can potentially be recreated through other means.
Recovery Time Objective
The length of time an application, system, network, or resource can be offline without causing significant business damage, as well as the time it takes to restore the service, is called the recovery time objective (RTO). The RTO is focused on the time to recover from a failing system or network outage.
RTO is calculated as the time between the moment of failure and the moment the system is fully restored:
\[RTO = T_{restored} - T_{failure}\]
Where \(T_{restored}\) is the time the system is back in service and \(T_{failure}\) is the time the outage began. The result must be less than or equal to the business-defined RTO threshold.
For example, if a system fails at 2:00 AM and is restored by 2:45 AM:
\[RTO = 2{:}45\text{ AM} - 2{:}00\text{ AM} = 45\text{ minutes}\]
If the business has defined an RTO of 1 hour, this is within tolerance. If the RTO were 30 minutes, the recovery would have exceeded the threshold and caused business harm.
Returning to the cloud-based infrastructure company example, suppose it had a critical outage for 10 minutes that affected all online access. The company has an RPO of 15 minutes and an RTO of 20 minutes, so the company was within both metrics. Later that week, the company had another outage that lasted 2 hours during peak business demand. With the RPO only allowing for 15 minutes of data loss and the RTO only allowing 20 minutes of downtime, 1 hour and 40 minutes of the outage was not accounted for. This example shows that the loss of data was exponential, as it occurred during peak business demand.
RPO and RTO are inversely related to cost. A shorter RPO requires more frequent backups and faster storage, and a shorter RTO requires more redundancy and faster recovery infrastructure. Both drive up cost significantly. Business leaders must be involved in defining these values because the decision is ultimately a trade-off between risk tolerance and investment.
Review Questions
1. Which business term has the definition “typically based on strategies adopted for the achievement of goals”?
- Capability
- Outcome
- Driver
- Priority
d. Each business has a set of priorities that are typically based on strategies adopted for the achievement of goals. These business priorities can influence the planning and design of IT network infrastructure. Therefore, network designers must be aware of these business priorities to align them with the design priorities, which ensures the success of the network they are designing by delivering business value.
2. Which business term is referenced as the “why” the business is doing something?
- Capability
- Outcome
- Driver
- Priority
c. What does this business have to do and why? This is what we call a business driver. Business drivers are what organizations must follow. A business driver is usually the reason a business must achieve a specific outcome. It is the “why” the business is doing something. Being required to maintain a specific compliance standard is a perfect example.
3. Which business term equates to the end result, such as saving money, diversifying the business, increasing revenue, or filling a specific need?
- Capability
- Outcome
- Driver
- Priority
b. A business outcome equates to the end result, such as saving money, diversifying the business, increasing revenue, or filling a specific need. Essentially, a business outcome is an underlying goal a business is trying to achieve. A business outcome will specifically map to a business driver.
4. Which business term refers to what a solution provides, and most times you get multiple of them?
- Capability
- Outcome
- Driver
- Priority
a. Business capabilities are not solutions. Business capabilities are what you get from a solution. A network access control solution provides a business the session- and transaction-based security capability, for example. Most solutions provide multiple capabilities. Some solutions provide parts of multiple capabilities, and when they are combined with other solutions, the business can get a number of capabilities that will make it successful.
5. An architect receives a business requirement from a CTO that states the RTO and RPO for a new system should be as close as possible to zero. Which replication method and data center technology should be used?
- Asynchronous replication over dual data centers via DWDM
- Synchronous replication over geographically dispersed dual data centers via MPLS
- Synchronous replication over dual data centers via Metro Ethernet
- Asynchronous replication over geographically dispersed dual data centers via CWDM
c. When both RTO and RPO must be as close to zero as possible, synchronous replication is required to ensure no data loss. Metro Ethernet provides high-speed, low-latency connectivity between geographically close data centers, minimizing the latency impact that would otherwise make synchronous replication impractical.
6. Company XYZ is planning to deploy primary and secondary disaster recovery data center sites 100 miles apart. Target RPO and RTO are 3 hours and 24 hours respectively. Which two considerations must the company bear in mind when deploying replication? (Choose two.)
- Target RPO/RTO requirements cannot be met due to the one-way delay introduced by the distance between sites
- VSANs must be routed between sites to isolate fault domains and increase overall availability
- Synchronous data replication must be used to meet the business requirements
- Asynchronous data replication should be used in this scenario to avoid performance impact on the primary site
- VSANs must be extended from the primary to the secondary site to improve performance and availability
b and c. VSANs must be routed between sites to isolate fault domains, which increases availability. With an RPO of 3 hours, synchronous replication is appropriate and achievable at 100 miles distance. Asynchronous replication would introduce data loss risk beyond the RPO target.
7. In the case of outsourced IT services, the RTO is defined within the SLA. Which two support terms are often included in the SLA by IT and other service providers? (Choose two.)
- Resolution time
- Network reliability
- Network size and cost
- Network sustainability
- Support availability
a and e. Resolution time defines how long it takes to resolve an incident, and support availability defines when support can be reached. These are the two most common SLA terms alongside RTO. Network reliability, size, cost, and sustainability are not standard SLA support terms.
8. An architect receives a business requirement stating the RTO for a new system should be 4 hours and the RPO should be less than 1 hour. Business continuity must also be ensured in the event of a natural disaster. Which replication method and data center technology should be used?
- Asynchronous replication over dual data centers via DWDM
- Asynchronous replication over geographically dispersed dual data centers via CWDM
- Synchronous replication over dual data centers via Metro Ethernet
- Synchronous replication over geographically dispersed dual data centers via MPLS
d. Natural disaster protection requires geographically dispersed data centers. An RPO of less than 1 hour requires synchronous replication to minimize data loss. MPLS provides the reliable, low-latency WAN connectivity needed to support synchronous replication over distance.
9. A company requires an RPO of less than 10 seconds to ensure business continuity. Which technology should be deployed?
- A single data center with duplicated infrastructure, dual PSUs, and a UPS
- Geographically dispersed data centers with asynchronous replication
- Geographically dispersed data centers with synchronous replication
- A single data center with duplicated infrastructure and dual PSUs
c. An RPO of less than 10 seconds means virtually no data loss is tolerable. Only synchronous replication guarantees that data is written to both sites simultaneously before the write is acknowledged. Asynchronous replication introduces a lag that would exceed a 10-second RPO. Geographic dispersion also ensures protection against site-level disasters.
10. Which two factors must be considered when calculating the RTO? (Choose two.)
- Importance and priority of individual systems
- Steps needed to mitigate or recover from a disaster
- Cost of lost data and operations
- How often backups are taken and how quickly these can be restored
- Maximum tolerable amount of data loss that the organization can sustain
a and b. RTO is about how quickly systems must be restored. The importance and priority of individual systems determines the order of recovery, and the steps needed to recover define how long that recovery takes. Options d and e relate to RPO, not RTO, since they concern data loss rather than recovery time.
11. Data replication is being designed as part of a data protection setup. Which replication strategy is best suited when the primary and secondary systems are physically close to each other?
- Synchronous replication
- Snapshot replication
- Transactional replication
- Direct replication
a. Synchronous replication is best suited when systems are physically close because the low latency between sites makes it practical to wait for the remote write acknowledgment before confirming the local write. This guarantees zero data loss. Snapshot and transactional replication introduce data loss windows and are better suited for distant or asynchronous scenarios.
12. Backups and mirror-copies of data are an essential part of RPO solutions. If a business wants to reduce their CAPEX for disaster recovery, which solution is applicable?
- Perform an annual cybersecurity assessment or penetration test
- Renew backup software annually to stay protected
- Migrate parts of or all the infrastructure to the cloud
- Build a redundant infrastructure for business continuity at another location
c. Migrating infrastructure to the cloud reduces CAPEX for disaster recovery by replacing owned hardware with pay-as-you-go cloud resources. Building a redundant physical site increases CAPEX. Annual assessments and software renewals are OPEX items and do not address the CAPEX reduction goal.
13. For a company that offers online billing systems, which strategy ensures the RPO is kept as low as possible?
- Cloud backup to mirror data
- Spare onsite disks
- Periodic snapshot of data
- Backup on external storage
a. Cloud backup that continuously mirrors data keeps the RPO as close to zero as possible because data is replicated in near real time. Periodic snapshots, spare disks, and external storage all introduce a time gap between the last backup and a potential failure, increasing the RPO.
Elasticity to Support Strategic Business Trends
Elasticity refers to the level of flexibility a certain design can provide in response to business changes. A change in this context refers to the direction the business is heading, which can take different forms such as organic business growth, a decline in business, a merger, or an acquisition.
To illustrate the concept of elasticity in network design, consider the higher education campus architecture from Network Design](network-design.qmd). This architecture has four locations interconnected directly, as illustrated in Figure 2. Any organic growth that requires the addition of a new location will introduce significant complexity in terms of cabling, control plane, and manageability. These complexities result from an inflexible design that is incapable of responding to the business’s natural growth demand.
To enhance the level of flexibility of this design, a core module can be added to optimize overall design modularity and support business expansion requirements. As a result, adding or removing any module or location will not affect other locations and does not require any change to other modules, as illustrated in Figure 3. In other words, [the design must be flexible enough to support the business priorities, drivers, and outcomes. If network designers understand business trends in this area, such understanding may influence design choices to a large extent.
Similarly, a flexible network design must support the capability to integrate with other networks, for example when mergers and acquisitions occur. With mergers and acquisitions, the network can typically grow significantly in size within a short period of time. The biggest challenge in both scenarios is that network designers have to deal with different design principles, the possibility of overlapping IP address space, different control plane protocols, and different approaches.
The same modularity principle applies in reverse during divestment. When an organization sells parts of its business, a modular design allows the affected modules to be cleanly detached without disrupting the rest of the network. This is the key reason modular design minimizes impact and risk during divestment. Each module is self-contained, so removing one does not cascade changes into the remaining architecture.
IT as a Business Innovation Enabler
In today’s market, many businesses understand how IT technologies enhance their services and provide innovation to their customers. When a certain technology can serve as a business enabler that helps the organization compete in the market or increase customer satisfaction, the adoption of that technology will be supported by the business.
For example, cloud-based data centers have been opening new opportunities for hosting service providers to generate more revenue. To offer cloud-based services, a business requires a reliable, flexible, and high-performance data center infrastructure. Consequently, this drives the business to build a high-performance, next-generation data center network. The network, by acting as a basis for cloud services, becomes the enabler of the business’s revenue-generation solution.
IT as a New Utility
Over the last decade, IT and networking specifically have become more akin to a utility provider such as an electricity or water provider. Identifying the network as a utility is important today because most businesses assume that the network is just going to work and that a business application will always be accessible for its end users. Everywhere we go, hotels, airports, restaurants, some form of wireless connection is available. We have come to expect it, just like we expect lights to come on when we flip a switch.
This assumption of the network always being available and properly providing whatever the business needs at any specific time is the concept of unstated requirements](network-design.qmd#unstated-requirements) introduced in Network Design. As a network designer, you will have to identify how far to take this expectation. Table 2 shows how to compare the associated business risk, reward, and cost of different availability options.
| Design Decision | Associated Cost | Design Complexity | Business Risk | Business Reward |
|---|---|---|---|---|
| Single points of failure | Low; no additional cost for redundancy | Low | Very high; outages are more likely to occur that would directly bring the business offline, causing loss of revenue and market reputation | Low; initial cost savings only |
| No single points of failure | Medium; solution cost increases to allow for redundant components | High | Low; the solution has been designed to allow for single failures while the business continues to function | High; the business can continue to make money during a single failure, though the complexity must be properly managed |
| No dual points of failure | High; a much higher initial cost is needed | Very high | Very low; the solution can withstand dual failures while the business continues to function | Very high; the solution is more robust and can withstand a higher degree of failures, but requires a highly skilled team to manage and maintain it |
[No single points of failure is the best design option to allow for a redundant solution, increasing overall business availability while limiting monetary cost to the business. As network designers, we should be able to present this information to business leaders to allow them to make properly informed decisions. Business risk versus reward and cost analysis are extremely important concepts for network designers to understand.
Money, Money, Money
Two common business goals that directly influence network design are minimizing operational costs and reducing complexity. A simpler, less complex network is easier to manage and troubleshoot, and lower operational costs directly improve business profitability.
Approximately 90 percent of business organizations are for-profit companies, meaning the business is focused on making money through a combination of increasing revenues while concurrently decreasing costs. This could be as simple as a reduction in capital expenses (CAPEX) by consolidating wholly owned data center locations from four to two, which reduces the number of buildings (fixed assets) the company owns. On the other hand, the company could focus on reducing operating expenses (OPEX) by reducing advertising and marketing budgets.
Both CAPEX and OPEX reductions can also take the form of investment. Completing a new application upgrade can provide a direct investment return by either lowering costs or increasing revenue through new features and functionality. This is called return on investment (ROI): the concept of identifying what the perceived potential benefit is going to be for the business if it takes a specific action. ROI is not always tied to a monetary return. A perfect example is the CCDE certification. Investing time in this certification journey has an extremely high ROI in the form of knowledge, mindset, and becoming a certified network designer.
The Nature of the Business
Classifying the industry in which the business belongs, or identifying the business’s origins, can aid in understanding the unstated requirements](network-design.qmd#unstated-requirements) introduced in Network Design. [For example, information security is almost always a must for a banking business whenever traffic crosses any external link. So by default, when planning a design for a business in the banking industry, the design must support or offer security capabilities to gain acceptance from the business. In addition, industry-specific standards that apply to IT infrastructure and services need to be considered. For instance, healthcare organizations may consider complying with the IEC-80001-1 standard.
Planning
An enduring adage is: “if you do not have a plan, you are planning to fail.” This is accurate and applicable to network design. Many network designers focus on implementation after obtaining requirements and putting them in design format, sometimes relying on best practices rather than focusing on planning what are the possible ways of getting from point A to point B. This planning process can help the designer devise multiple approaches or paths (design options). At this point, the designer can ask the key question: Why? Asking why is vital to making a business-driven decision for the solution or design that optimally aligns with the business’s short- or long-term strategy or objective.
Reliance on best practices is more common when designing a network from scratch (greenfield](network-design.qmd#greenfield)), which is not common with large enterprises and service provider networks. IT network architectures and building constructions are quite similar in the way they are approached and planned by designers.
For example, several years ago a Software as a Service (SaaS) company built a new headquarters location based on the business priorities, drivers, outcomes, and requirements at that time. Recently, this SaaS company acquired a number of other companies and is in the process of merging them. The stakeholders have requested that network designers review the design and make suggestions for modification to address the increased number of people accessing the headquarters location, because this increase was not properly projected and planned for during the original design five years ago.
Typically, architects and engineers will evaluate the situation, identify current issues, and understand the stakeholders’ goals. They gather the business priorities, drivers, and outcomes, then work on optimizing the existing infrastructure rather than rebuilding from scratch. However, this time they need proper planning to provide a design that fits current and future needs.
Similarly, with IT network infrastructure design, there are always new technologies or broken designs that were not planned well to scale or adapt to business and technology changes. Therefore, network designers must analyze business issues, requirements, and the current design to plan and develop a solution that optimizes the overall existing architecture. [Ultimately, the planning approach leads to the linkage of design options and technologies to the gathered requirements and goals to ensure that the design will bring value and become a business enabler rather than a cost center. Typical tools network designers use at this stage are the decision tree and the decision matrix.
Creating a network that functions as a strategic part of the business rather than simply a cost center starts with understanding business requirements and processes. The specific knowledge that enables a designer to create high-level LAN, WAN, and data center designs that support the business is an understanding of data flows meaning knowing how data moves across the network allows the designer to make informed decisions about topology, capacity, and segmentation.
Decision Tree
A decision tree is a helpful tool that a network designer can use to compare multiple design options or protocols based on specific criteria. For example, a designer might need to decide which routing protocol to use based on a certain topology or scenario, as illustrated in Figure 4.
Decision Matrix
Decision matrices serve the same purpose as decision trees; however, with the decision matrix, network designers can add more dimensions to the decision-making process. Table 3 presents two dimensions a network designer can use to select the most suitable design option. Both business requirements and priorities can be taken into account to reach a final decision based on a multidimensional approach.
| Business Requirement | Priority | Design Option 1 | Design Option 2 |
|---|---|---|---|
| Cost Savings | 4 | Moderate | Low |
| Scalable | 1 | High | High |
| Secure | 2 | Low | High |
When using the decision matrix in the preceding example, design option 2 is more suitable based on the business requirements and priorities. The decision matrix is not solely reliant on business requirements to drive the design decision; priorities from the business point of view were considered as an additional dimension in the decision-making process, which makes it more relevant and focused.
Planning Approaches
To develop a successful network design, a proper planning approach is required to build a coherent strategy for the overall design. Network designers can follow two common planning approaches to develop business-driven network designs and facilitate design decisions:
- Strategic planning approach: Typically targets long-term business outcomes and strategies. For example, a service provider needs to migrate its core from legacy ATM to MPLS. The design decision in this approach has to cater to long-term goals and plans.
- Tactical planning approach: Typically targets overcoming an issue or achieving a short-term goal. For instance, an enterprise might need to provide remote access to some partners temporarily over the Internet until dedicated extranet connectivity is provisioned. Design decisions in this approach generally need to provide what is required within a limited period of time and are not necessarily required to consider long-term goals.
Strategic Balance
Within any organization, there are typically multiple business units and departments, all with their own stakeholders. Each has its own strategy: some are financially driven, while others are more innovation-driven. For example, an IT department is more of an in-house service provider concerned with ensuring service delivery is possible and optimal, whereas the procurement department is cost-driven and always prefers cheaper options. The marketing department, in contrast, is almost always innovation-driven and wants the latest technology.
A good understanding of the overall business strategy and goals can lead to a compromise between the different aims of different departments. Each business unit or entity within an organization must have its requirements met at a certain level so that all can collectively serve the overall business priorities, drivers, outcomes, and strategies.
As an example of achieving strategic balance, consider a retail business wanting to expand its geographic presence by adding more retail shops across the globe with low CAPEX. The main goal is to increase the number of remote sites with minimal cost. The perspectives of each department are as follows:
- IT point of view: The point of sales (PoS) application does not support offline selling or local data saving, so it requires connectivity to the data center to operate. The required traffic volume from each remote site is small but is real-time application traffic requiring guaranteed treatment. Many sites are to be added within a short period of time. Optimum solution: an MPLS VPN as a WAN.
- Marketing point of view: If any site cannot process purchases due to a network outage, this will impact the business’s reputation. Optimum solution: high-speed, redundant links.
- Financial point of view: Cost savings. Optimum solution: one cheap link, such as an Internet link, to meet basic connectivity requirements.
It is clear that WAN redundancy is required for the new remote sites, but cost is a constraint that must also be considered.
When applying the strategic balance concept, each department’s strategy can be incorporated to collectively achieve the overall optimum business goal through a suboptimal approach from each department’s perspective. In this particular example, the retail business can use two Internet links combined with a VPN overlay solution to achieve the business goal through a cost-effective solution that offers link redundancy, increases the availability level of remote sites, meets application bandwidth requirements, and maintains brand reputation in the market at the desired level.
Review Questions
14. Which design tool adds multiple dimensions to the design-making process?
- Decision tree
- Tactical planning approach
- Decision matrix
- Strategic planning approach
c. A decision matrix serves the same purpose as a decision tree, but with the matrix, network designers can add more dimensions to the decision-making process.
15. What type of financial savings does a business achieve by consolidating its wholly owned data center locations from four to two?
- OPEX
- ROI
- CAPEX
- TCO
c. Capital expenses (CAPEX), or expenditures, are the major purchases a business makes that are to be used over a long period of time. Examples of CAPEX include fixed assets, such as buildings and equipment.
16. What type of financial savings does a business achieve by reducing its advertising and marketing budget?
- OPEX
- ROI
- CAPEX
- TCO
a. Operating expenses (OPEX), or expenditures, are the day-to-day costs incurred by a business to keep the business operational. Examples of OPEX include rent, utilities, payroll, and marketing.
17. What business financial concept does spending $5,000 on a new application upgrade that includes new features and functionality that allow the business to charge a premium represent?
- OPEX
- ROI
- CAPEX
- TCO
b. Return on investment (ROI) is the concept of identifying what the perceived potential benefit is going to be for the business if the business makes an investment in a new technology, solution, or capability. Completing that application upgrade costs the business $5,000 in time and labor. At some point, the business wants to recoup its investment. Included with this upgrade are new features and functionality that the business can charge a premium for. These premium services are how the business is going to recoup its initial $5,000 investment.
18. Which two types of planning approaches are used to develop business-driven network designs and to facilitate design decisions? (Choose two.)
- Cost optimization approach
- Strategic planning approach
- Modular approach
- Tactical planning approach
- Business optimization approach
b and d. The two planning approaches used to develop business-driven network designs are the strategic planning approach, which targets long-term business outcomes, and the tactical planning approach, which targets overcoming a short-term issue or achieving a near-term goal. The other options are distractors.
19. What are two examples of business goals to be considered when a network design is built? (Choose two.)
- Integrate endpoint posture
- Faster depreciation
- Minimize operational costs
- Reduce complexity
- Standardize resiliency
c and d. Minimizing operational costs and reducing complexity are clear business goals that directly influence network design decisions. They improve efficiency and simplify management. The other options are either technical implementation details or financial accounting concepts, not business goals in the design context.
20. Creating a network that functions as a strategic part of the business rather than simply being a cost center starts with a good understanding of business requirements and processes. What specific type of knowledge helps to create high-level LAN, WAN, and data center designs that support and enable the business?
- Risk assessment
- Monitoring and management of data
- Understanding of data flows
- Recovery time of system functionality
c. Understanding data flows is the specific knowledge that enables a designer to create high-level designs aligned with business needs. Knowing how data moves across the network allows the designer to make decisions about topology, capacity, and segmentation that directly support business operations.
21. Network changes because of mergers, acquisitions, and divestment can be very disruptive. When an organization sells parts of its business, it must detach the affected parts of the network. Which network design approach minimizes the impact and risks as the divested parts are detached?
- Redundant design
- Modular design
- Less complex design
- Routed access design
b. A modular design allows individual modules to be detached or added without affecting the rest of the network. This is exactly what is needed during a divestment, where the sold portion of the business must be cleanly separated. Redundant and routed access designs do not inherently support clean separation of network segments.
Project Management
As a network designer, it is important to understand how projects are managed. This does not mean we need to be a project manager, nor do we actually have to manage the projects in question. We need to understand the process each project will go through and the associated advantages and disadvantages of the methodology being used. This section covers the most common project management methodologies and their associated advantages and disadvantages.
Waterfall Methodology
The waterfall project management framework follows a sequential, linear process and historically has been the most popular version of project management for software engineering and IT projects. The waterfall project management framework is sometimes planned using a Gantt chart that shows the start dates, end dates, assigned resources, dependencies, and overall status for each project task.
Once one of the stages is complete, the project team moves on to the next step. The team cannot go back to a previous stage without starting the whole process from the beginning. Before the team can move to the next stage, requirements may need to be reviewed and approved by the customer. This is why the waterfall project plan is a linear process.
Advantages of Waterfall
The waterfall project management framework is best used for simple, unchanging projects. Its linear, rigid nature makes it easy to use and allows for in-depth documentation.
- Ease of manageability: Because the waterfall methodology follows the same pattern for each project, it is easy to use and understand. The project team does not need any prior knowledge or training before working on a waterfall managed project. The waterfall project management model is very rigid; each phase has specific deliverables and a review process, so it is easy to manage and control.
- Structure: Every phase in waterfall has a start and endpoint, so sharing progress with stakeholders and customers is easy. By focusing on requirements and the overall network design before implementation, the team can reduce the risk of a missed deadline.
- Documentation: Waterfall requires documentation for every phase, resulting in a better understanding of the network design and the specific design decisions. Within this documentation, it is critical to highlight why a design decision is being made. This process also leaves a paper trail for any future projects or if stakeholders need to see more detail about a certain phase.
Disadvantages of Waterfall
The biggest limitation of the waterfall project management model is its adversity to change throughout the project. Because waterfall is linear, you cannot bounce between phases, even if unexpected changes occur. Once you are done with a phase, the project team moves on to the next phase and cannot go back.
- Change adverse: Once the project team completes a phase, they cannot go back. If they reach the testing and verification phase and realize that a specific business capability is missing, it is very difficult and expensive to go back and fix it.
- Solution delivery is late: The project has to complete multiple phases before the solution implementation can begin. As a result, business leaders will not see a working solution until late in the entire process.
- Requirements gathering is difficult: One of the first phases in a waterfall project is to complete requirements gathering with the business stakeholders. The problem is that it can be extremely difficult to properly identify what the stakeholders truly need and want this early in the process. In most cases, business leaders learn and identify requirements throughout the process as the project moves forward.
Agile Methodologies
Agile methodologies are based on an incremental, iterative approach. Instead of in-depth planning at the beginning of the project like the waterfall model, the agile methodologies are open to changing requirements over time and encourage constant feedback from the different business leaders and stakeholders. Cross-functional teams work on iterations of a product over a period of time, and this work is organized into a backlog that is prioritized based on business or customer value. The goal of each iteration is to produce a working product. This iterative, feedback-driven approach is known as the evolutionary delivery model.
Agile methodologies were built for software development, so why are we focusing on them here? With the industry shift to automation and orchestration within networking, there have been a number of development-focused adoptions within the networking industry, such as infrastructure as code, network as code, leveraging APIs to complete networking tasks at scale, and reworking manual workflows into a continuous integration/continuous delivery (CI/CD) pipeline process. Because of this market shift, network designers need to understand how an Agile methodology works to make proper design decisions when businesses are leveraging the different Agile methodologies.
12 Principles of Agile Methodologies
The Agile Manifesto defines four core values: working software over comprehensive documentation, customer collaboration over contract negotiation, individuals and interactions over processes and tools, and responding to change over following a plan.
The Agile Manifesto lists the following 12 principles to guide teams on how to execute with agility:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity, the art of maximizing the amount of work not done, is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Advantages of Agile
An Agile methodology is focused on flexibility, continuous improvement, and speed. Unlike the waterfall methodology, change is fully embraced and welcomed.
- Change is welcomed: With a shorter process and cycles of work, it is easier to add changes throughout the project. The goal is to always refine and reprioritize the work, including recent changes that have been added to the backlog. This allows a project team to add changes to the project in a matter of weeks or days.
- Unknown future state: Agile is very beneficial for projects where the future state is not clearly defined. As the project progresses, the future state comes to light and network designers can easily adapt to these evolving requirements.
- Faster delivery: Breaking down the project into an iterative process allows the project team to focus on higher-quality work that is collaborative.
- Feedback loop: Agile projects encourage feedback from users and team members throughout the whole project, so lessons learned are used to improve future iterations.
Disadvantages of Agile
An Agile methodology has some disadvantages and trade-offs. With all of the changes being added throughout the project, the project end date can be hard to predict, and documentation is not prioritized and can be forgotten altogether.
- Lack of scheduling: It can be hard to identify a completion date. Because Agile methodologies are based on time-bound delivery and tasks can be reprioritized based on new additions to the project, it is very likely that some tasks may not be complete in the original time. Additional sprints may be added at any time, adding to the overall timeline.
- Highly skilled teams: The team makeup must include highly skilled self-starters who do not require micromanagement. They must also know and understand the specific Agile methodology being leveraged.
- Time commitment: Agile is most successful when all team members are completely dedicated to the project. Consistent active involvement and collaboration from all team members is required throughout the Agile process.
- End solution creep: In most cases, an Agile project does not have a definitive plan at the beginning, so the end product or solution can look very different from what was intended. New iterations will most likely be added based on customer feedback, which can lead to a very different end solution. As network designers we need to be aware of solution creep that can introduce never-ending projects and a significant reduction in profitability for the parties involved.
Scrum Methodology
Scrum is a subset of Agile and one of the most popular process frameworks for implementing Agile. Scrum was built to be an iterative model used to manage projects. With Scrum, there are roles, responsibilities, and meetings that never change. The Product Owner acts as the interface between the business, customers, and their product-related needs on one side, and the development team on the other. For example, Scrum leverages four ceremonies that provide a process structure to each sprint: sprint planning, daily stand-up, sprint demo, and sprint retrospective.
Advantages of Scrum
Scrum is a prescriptive framework with specific roles, responsibilities, and meetings.
- Increased transparency: With consistent daily stand-up meetings, the entire project team knows who is doing what and when, so there is full transparency. Problems are found and discussed as a team, which leads to real-time resolutions before they become larger issues.
- Increased team accountability: With a Scrum team there is no micromanagement being done by a project manager. Instead, a team of highly skilled self-starters collectively decide what should be included in each sprint, and the entire team works together to complete it.
- Easy to accommodate changes: With short sprints and constant feedback, it is easier to cope with and accommodate changes. If the team discovers a new user story during one sprint, they can easily add that feature to the next sprint during the backlog refinement meeting.
- Increased cost savings: Real-time consistent communication ensures the team is aware of all issues and changes as soon as they arise, helping to lower expenses and increase the overall quality of the solution. By testing functionality in smaller chunks, mistakes can be corrected early on before they get too large to resolve.
Disadvantages of Scrum
While Scrum offers concrete benefits, it also has some downsides. Scrum requires a high level of experience and commitment from the team, and projects can be at risk of scope creep.
- Scope creep: Most Scrum projects experience scope creep at some point. This is due to a lack of a specific project completion date. With no end date in sight, customer stakeholders and business leaders can keep requesting additional functionality.
- Requires Scrum experience: With defined roles and responsibilities, the team needs to be familiar with Scrum principles to succeed. Because there are no defined roles in the Scrum team (everyone does everything), it requires team members with technical experience who commit to the daily Scrum meetings for the duration of the project.
- The wrong Scrum Master can ruin everything: The Scrum Master is very different from a project manager. The Scrum Master does not have authority over the team and needs to trust the team they are managing and never tell them what to do. If the Scrum Master tries to control the team, the project will fail.
- Poorly defined tasks can lead to inaccuracies: Project costs and timelines will not be accurate if tasks are not well defined. If the initial goals are unclear, planning becomes difficult and sprints can take more time than originally estimated.
Kanban Methodology
Kanban is a Japanese term meaning “visual sign” or “card.” The Kanban methodology is a visual framework used to implement Agile that shows what to produce, when to produce it, and how much to produce. It encourages small, incremental changes to your current system and does not require a certain setup or procedure. Kanban can be easily overlaid on top of the other project management methodologies discussed so far.
When looking at Kanban versus Agile, it is important to remember that Kanban is one flavor of Agile. A Kanban board is a tool to implement the Kanban method for projects. It is made up of different swim lanes or columns. The simplest boards have three columns: To Do, Work In Progress (WIP), and Done. Figure 5 shows an example of a Kanban board (source: Atlassian Jira Kanban Template).
Kanban cards represent the work, and each card is placed on the board in the swim lane that represents the status of that work. These cards communicate status at a glance. Different color cards can be used to represent different details, such as different teams, priorities, or types of work.
Advantages of Kanban
Kanban’s visual nature offers a unique advantage when implementing Agile. The Kanban board is easy to learn and understand, it improves the flow of work, and minimizes cycle time.
- Increases flexibility: Kanban is an evolving, fluid model. There are no set phase durations or times. As a new item of work is added to the board, it is prioritized along with the rest of the board items.
- Reduces waste: Kanban revolves around reducing waste, ensuring that teams do not spend time doing work that is not needed or doing the wrong kind of work.
- Easy to understand (KISS): The visual nature of Kanban helps to make it incredibly intuitive and easy to learn. The team does not need to learn a completely new methodology, and Kanban can be easily implemented on top of other systems already in place.
Disadvantages of Kanban
Many of the disadvantages associated with Kanban come with misuse or mishandling of the Kanban board. An outdated or overcomplicated board can lead to confusion, inaccuracies, or miscommunication.
- Outdated board: The team must be committed to keeping the Kanban board up to date; otherwise, they will be working off inaccurate information. Once work is completed based on an out-of-date board, it can be hard to get things back on track.
- Overcomplicate the board: The Kanban board should remain clear and easy to read. Adding too many columns or options buries the important information. Keep your Kanban boards simple, clear, and concise.
- Lack of timing: A frequent complaint about Kanban is that you do not know when things will be done. The columns on the Kanban board are only marked by phase (To Do, WIP, Done). There are no timeframes associated with each phase, so you really do not know how long the to-do phase could last.
Kanban Rules
Every Kanban project should follow these rules:
- Visualize: Visually seeing the work on the board allows the team to fully understand the entire project and how it will move forward. By seeing it all, the team can find problems quicker in the process and resolve them before they become larger issues.
- Limit work: Work in progress limits (WIP limits) determine the minimum and maximum amount of work for each column on the board. By putting a limit on WIP, you can increase speed and flexibility, and reduce the need for prioritizing tasks.
- Manage the card flow: The movement of work (cards) throughout the Kanban board should be monitored and improved upon. Ideally, you want a fast, smooth flow, which shows that the team is creating value quickly.
- Reserve the right to improve: As the team leverages the Kanban method, they should be able to identify and understand any issues that come up. The group should reserve the right to improve the process anytime that will help the flow of work, the overall cycle of time, and increase the work quality being delivered.
Project Management Methodology Comparison
Table 4 compares the different project management methodologies covered in this section.
| Criteria | Waterfall | Agile | Scrum | Kanban |
|---|---|---|---|---|
| Scope creep | Not likely to happen | Happens often | Happens often | Depends on WIP limits |
| Manageability | Easy | Hard | Hard | Easy |
| Structure | Very structured | Not structured | Not structured | Structured |
| Documentation | Required in each phase | Not required | Not required | Not required |
| Changes | Change adverse | Change is welcomed | Easy to include changes | Easy to include changes |
| Solution delivery | Late in process | Faster delivery | Faster delivery | Fastest delivery |
| Requirements gathering | Identified early | Hard to identify all upfront | Easy to include changes throughout | Identified throughout the project |
| Future/end state | Clearly defined at beginning | Not defined at beginning; comes to light as project moves forward | Not defined at beginning; comes to light as project moves forward | Not defined at beginning |
| Stakeholder feedback | Not normally requested after requirements gathering | Constant feedback requested and incorporated | Constant feedback requested and incorporated | Constant feedback requested and incorporated |
| Project completion date | Easy to identify and schedule | Can slide; hard to identify a realistic date | Can slide; hard to identify a realistic date | Hard to identify; time is not tracked |
| Teams | Mix of skill levels; no team accountability | Highly skilled; limited team accountability | Highly skilled; increased team accountability | No methodology knowledge required; work must be visible |
| Time commitment | Resources can be shared with other projects | All resources should be completely dedicated | All resources should be completely dedicated | Resources dedicated to a card until completed or pending |
| Work transparency | No transparency | Semi-transparency | Full transparency | Full work visibility |
PPDIOO Lifecycle
PPDIOO (Prepare, Plan, Design, Implement, Operate, Optimize) is Cisco’s proprietary network lifecycle framework and the leading structured approach to network design and implementation. Unlike general software development methodologies such as Waterfall or Agile, PPDIOO was purpose-built for network infrastructure, covering the full journey from initial business justification through ongoing optimization. Each phase has a distinct role: Prepare establishes the organizational and technical requirements; Plan assesses the network and creates a project plan; Design produces a detailed design aligned to those requirements; Implement deploys the solution according to the design; Operate maintains day-to-day network health; and Optimize proactively improves performance and resolves issues before they impact the business. The framework is iterative in nature, as insights from the Operate and Optimize phases feed back into future Prepare and Plan cycles, making it well suited to the evolving demands of enterprise networks. For CCDE candidates, PPDIOO is significant because it provides the structured lifecycle context within which all network design decisions are made.
PPDIOO is the leading lifecycle approach to network design and implementation, providing a structured framework that aligns network design with business requirements throughout the entire lifecycle.
Review Questions
22. Which of the following is not a characteristic of the waterfall project management framework?
- Linear
- Change adverse
- Structured
- Minimal documentation
d. The waterfall project management framework is linear, adverse to change, structured, and requires documentation at the end of each phase. Minimal documentation is therefore not a characteristic of waterfall.
23. Which of the following is a characteristic of the Agile project management framework?
- Change adverse
- End state is defined
- Faster delivery
- Feedback not welcome
c. The Agile project management model is based on an incremental, iterative approach. Instead of in-depth planning at the beginning of the project like the waterfall model, Agile methodologies are open to changing requirements over time and encourage constant feedback from the different business leaders and stakeholders. Agile welcomes change and, because of that, the end state is oftentimes not known at the beginning of the project. Breaking down the project into an iterative process allows the project team to focus on higher-quality work that is collaborative and also promotes faster delivery.
24. A small organization of 20 employees is looking to deliver a network design service for modernizing customer networks. The project scope and weekly progress should be visualized by management, feedback must always be considered, and flexibility to change scope at any point in time is required. Which project methodology meets the requirements and has the least impact on the outcome?
- Scrum
- LEAN
- Kanban
- Six-Sigma
c. Kanban is a visual framework that supports ongoing flexibility, continuous feedback, and scope changes at any time without disrupting the overall flow. It is well suited for small teams that need management visibility through a board and want to incorporate changes with minimal process overhead.
25. Various teams are preparing low-level design documents using a Waterfall project model. Input from stakeholders was captured at the start and the project scope has been defined. What impact will it have on documentation and project deliverables if stakeholders ask for changes before the information has been captured?
- Significant effort and time are required
- Rework is expected before the delivery
- This provides more opportunity to think outside the box
- This provides a flexible approach to incorporate changes
a. Waterfall is a linear, change-adverse methodology. Once a phase is complete, going back requires restarting the process. Changes requested before information is fully captured introduce significant rework, effort, and time, which is one of the core disadvantages of the Waterfall model.
26. Which development model is closely associated with Agile project management?
- Lifecycle model
- Starfish model
- Static model
- Evolutionary delivery model
d. The evolutionary delivery model is closely associated with Agile because it delivers working increments iteratively, evolving the solution based on feedback. The lifecycle model is associated with traditional Waterfall project management.
27. Which development model is closely associated with traditional project management?
- Agile model
- Lifecycle model
- Static model
- Evolutionary delivery model
b. The lifecycle model is closely associated with traditional Waterfall project management, following a sequential set of defined phases from requirements through implementation and closure. The evolutionary delivery model is associated with Agile.
28. Agile and Waterfall are two popular methods for organizing projects. What describes any Agile network design development process?
- Working design over comprehensive documentation
- Contract negotiation over customer collaboration
- Processes and tools over individuals and interactions
- Following a plan over responding to change
a. The Agile Manifesto values working software (or in this context, a working design) over comprehensive documentation. The other options describe the opposite of Agile values — Agile prioritizes customer collaboration over contract negotiation, individuals and interactions over processes and tools, and responding to change over following a plan.
29. Which methodology is the leading lifecycle approach to network design and implementation?
- Waterfall model
- PPDIOO
- Spiral model
- V model
b. PPDIOO (Prepare, Plan, Design, Implement, Operate, Optimize) is Cisco’s leading lifecycle approach to network design and implementation. It provides a structured framework that aligns network design with business requirements throughout the entire lifecycle.
30. What is one of the key values of the Agile Manifesto?
- Comprehensive documentation over working software
- Contract negotiation over customer collaboration
- Individuals and interactions over processes and tools
- Following a plan over responding to change
c. One of the four key values of the Agile Manifesto is individuals and interactions over processes and tools. The Manifesto values the left-hand side of each pair more than the right, so working software, customer collaboration, and responding to change are also valued over their counterparts.
31. A consultant needs to evaluate project management methodologies for a new service deployment. The customer wants to be involved in the end-to-end project progress, receive frequent updates, and have the ability to change requirements as the project progresses. Which project management methodology should be used?
- Three principles
- Phased
- Agile
- Waterfall
c. Agile is the correct choice when the customer wants continuous involvement, frequent updates, and the flexibility to change requirements throughout the project. Waterfall does not support changes after requirements are locked, and phased approaches do not inherently support ongoing customer collaboration.
32. Which role in Scrum becomes the interface between the business, the customers, and their product-related needs on one side and the team on the other?
- Product Owner
- Program Manager
- Scrum Master
- Product Manager
a. The Product Owner is the bridge between the business stakeholders and the development team. They define and prioritize the backlog based on business value and customer needs, ensuring the team is always working on the most important items.
33. Which project management methodology is characterized by having low client involvement?
- LEAN project management
- Agile project management
- Traditional project management
- Kanban project management
c. Traditional (Waterfall) project management is characterized by low client involvement after the initial requirements gathering phase. Once requirements are locked and the project begins, clients typically do not participate until delivery. Agile and Kanban both emphasize continuous client feedback throughout the project.
34. A network operations team is developing a network automation solution. The team organizes the project into iterations and structures its quick daily meetings around three questions: what did I work on yesterday, what am I working on today, and which issues are blocking me. Which project management methodology is the team using?
- Lean
- Waterfall
- Scrum
- Kanban
c. Scrum uses iterative sprints and daily stand-up meetings structured around exactly those three questions. This is the defining ceremony of Scrum and distinguishes it from Kanban, which does not prescribe daily stand-ups or fixed iterations.
35. What are two benefits of using an Agile execution methodology for network design? (Choose two.)
- Dedicated resources can work in parallel for their specific tasks
- Results in better network designs using a holistic approach
- Straightforward planning due to agreement on deliverables at the start
- Customer-focused, resulting in increased customer satisfaction
- Flexibility in accepting and honoring ongoing changes as the project progresses
d and e. Agile is customer-focused, emphasizing collaboration and feedback that leads to higher satisfaction. It also allows flexibility to incorporate ongoing changes throughout the project lifecycle. Options a, b, and c are more characteristic of Waterfall or structured methodologies.
Summary
In this chapter, we focused on the business elements, terminology, and project management styles that all network designers need to know. We discussed business priorities, drivers, outcomes, and capabilities, and how each relates to the other to drive the requirements for the design. We highlighted how risk versus reward, ROI, CAPEX, OPEX, and business continuity all impact the design decisions we have to make as network designers. We labeled IT, including networking, as the new utility that everyone expects to be online and available all the time, just like running water and electricity. Understanding the business is critical to ensuring the design decisions will directly increase business success. Finally, we covered the most common project management methodologies of today: waterfall, Agile, Scrum, and Kanban, the advantages and disadvantages of each, and how they compare to each other based on various criteria.
Previous: Network Design | Next: What’s the Purpose of the Network?