The Vendor Influence Curve (VIC) road map provides guidance on the implications of using the VIC process for enterprise networking. When using the VIC, network architects and other related network team members need to perform specific activities to gain the most benefit.

• The VIC road map will help tie network architecture decisions to business requirements by focusing attention on user requirements and defining a process to ensure that architectural decisions are justified by business needs.
• Adopting the VIC requires a deeper understanding of business requirements and forces the networking team to rethink its architectural decisions. Decisions should not be based on past (and often outdated) best practices.
• Failure to adopt VIC methodologies often leads to overspending on network technology that does not facilitate the business.

• Network architects should adopt the VIC and take control of their network architecture as a way of better meeting business requirements.
• Network architects need to define a set of independent building blocks separated by a layered open architecture.

On the surface, the Vendor Influence Curve (VIC; see Figure 1) appears to be predominantly concerned with procurement. Although our work with hundreds of clients points to a strong correlation between an enterprise's position on the curve and the price it pays for enterprise network equipment, we believe that adopting the VIC has implications beyond procurement and price. Even more important than the savings and the increased discounts derived from using the VIC is the significantly improved business alignment. Adopting the VIC forces the IT organization to rethink its role in delivering services to the business, and the result will be a significantly improved network architecture and services that can be used to deliver business value.

Looking at the definition of a "Level 3" organization helps illustrate why the VIC goes beyond a procurement exercise. Organizations at Level 3 have to understand their business requirements before they can start defining a technical architecture, designing the network, selecting the vendor and finally implementing the solution. By turning the process back to its fundamentals, the VIC forces IT organizations to focus on what's required, rather than making obvious and linear decisions. We find that network architects too often follow the easy path when planning for network upgrades.

Proven "rules of thumb," such as automatically upgrading bandwidth or migrating from frame relay to Multiprotocol Label Switching (MPLS), continue to be used, and these decisions are never questioned. However, given the significant shifts in network technologies, changing application architectures, and new regulatory and compliance issues, traditional design practices have become outdated. These design practices are not yet being challenged in most organizations, which will result in more than $100 billion in wasted network investments during the next five years (see "Toolkit: Tactical Guidelines for Rethinking Network Design Practices" for more details on this topic). More important than the wasted money and effort, however, is the lost opportunity to invest in technologies that have a greater effect on changing and improving organizational productivity. Wasting money at the front end of the process results in lost profit and poor service, which is, by far, the larger impact.

To use the tool to its best advantage, organizations that adopt the VIC for enterprise networking need to think about several technical and business implications. Figure 2 illustrates a high-level road map for organizations that want to adopt the VIC tool. The remainder of this research addresses the individual areas and provides guidance on getting started.

The technical considerations after adopting the VIC share a common thread — how to build an open, layered enterprise network architecture with the right set of features to improve business processes. The business considerations focus on understanding the business requirements and the financial effects of decisions that may be made in the design phase.

When first using the VIC, organizations often struggle with what appears to be a philosophical question: "What is a network?" Although the answer appears obvious, understanding the boundaries of what should and should not be included in design projects is an important first step. Large vendors (such as Cisco Systems) will have you believe that nearly anything they put their names on should be part of the "network." However, this isn't an appropriate approach to ensure the network will best meet the needs of your organization — technically or financially. Too many of the components that contribute to the network have significant impacts on the reliability, security and performance of mission-critical business applications. As a result, no single vendor can deliver leading products in all product areas or provide all functions in a homogeneous, all-encompassing solution.

In many of these key markets, there is significant differentiation among products that will affect the business, and no vendor — small or large — is the right fit for all enterprises It is important to define the network around a number of logical building blocks. The exact definition and make-up of these building blocks is less important than the existence of a plan and the adherence to the concept. Figure 3 shows one approach to thinking about networking building blocks.

Figure 3 shows building blocks of LAN, WAN, wireless, security, application acceleration, storage networking, voice and communications applications. In some cases, organizations combine LAN and WAN into a Layer 2 to Layer 3 connectivity building block; others will split the LAN into edge switching and core and aggregation.

One approach to defining the logical building blocks is to map the building blocks into the operational teams that manage the network. In large organizations, there will be operational specialists for LAN, WAN, security and other areas. These delineations are obvious dividing lines between at least some of the major building blocks. The building block definition may shift, or a function that is in one building block may transition to another.

Organizations can use the building block approach for two types of projects. In one case, there is little differentiation among a number of players in a market with a relatively simple ability to substitute one vendor for another (workgroup switching is one example). In this case, enterprises will be looking for operational and cost advantages when using this approach. In other cases, there will be significant differentiation among the vendors in a market, and the approach ensures that enterprises do not lose sight of the business requirements when making technology decisions.

Defining building blocks also protects organizations from the large "vendor creep" trap. As vendors acquire small providers in adjacent markets, enterprises often add these new products to the "standardized" solution, rather than going through the required analysis that the building block approach demands.

Once the appropriate building blocks have been defined, the most important technical consideration is to ensure that there are no proprietary or other forced link between the building blocks. Networking emerged as a set of layered technologies for a reason — there are different functions required, and a layered architecture ensures innovation, choice and an ability to meet various business requirements. Within building blocks, it is acceptable to use proprietary technologies, as long as organizations compare vendors against their requirements.

It is important to make the function a requirement, rather than making a specific proprietary technology a requirement. That keeps alternatives open. Between building blocks and between the network and end devices it is not appropriate to enforce proprietary protocols during the evaluation process. If a decision is made to use a proprietary protocol that contradicts this philosophy, then it's critical that these protocols be reviewed regularly and that they not be propagated into new buying criteria over the long term.

One "school of thought" is that proprietary protocols can be used in the early stages of a market, before standards have caught up to innovation. However, once standards are in place, or the technology has started to move down the commodity curve, it is imperative that network architects migrate from reliance on proprietary technology. Figure 4 shows a conceptual view of appropriate and inappropriate uses of proprietary technology.

The idea behind using the VIC is not that you should arrive at a network architecture with a random set of vendors scattered throughout the network, or more than one vendor in a building block, or even a different vendor for every building block. However, the other extreme case — requiring that a single vendor be used across all building blocks — is equally inappropriate. Network architects need to consider how to build a network with more than a single vendor. There are different conceptual approaches to this, but all center on understanding key business requirements and using a building block strategy to logically segment major network components and projects.

Some organizations will end up with a strategy that is heavily best-of-breed across all aspects of their networks; others may take an approach that results in many building blocks being standardized on one vendor (often Cisco Systems), but will use the VIC process to select other vendors where technology really affects the business from a technology or financial perspective. Both approaches work, as long as all major projects take the VIC methodology into consideration and never dictate that the incumbent vendor be the only choice for new purchases. Doing so ensures that all vendors, even those that have significant amounts of business with an organization, will be responsive when major projects decisions are taking place.

No area in enterprise networking should be designed without considering vendor alternatives. By breaking up the networking into logical building blocks, and understanding the specific business requirements that apply in that building block, the network team should be able to arrive quickly at a reasonable shortlist of vendors to evaluate. The first step to ensure this happens is to understand the technology markets and how the various players could contribute to the network building blocks. Too often, network staff become vendor specialists, rather than network specialists, and they lose the capacity to be strong advisors to the business.

The technical evaluation should include:

• Ensuring a match to the most important features that will drive the business
• Assessing the operational capabilities of the products
• Ensuring that products adhere to open, standards-based interfaces
• Assessing the support and engineering capabilities

No single criteria should dominate, and the technical assessment must be integrated into an overall business decision that includes an economic evaluation of the proposals. A vendor that is ahead in the technical evaluation isn't necessarily the best solution for the organization. In markets where there is a strong level of substitutability, a vendor marginally ahead on technology but charging twice as much is unlikely to be the winner when following the VIC methodology. On the other hand, in areas where technology makes a big difference in business productivity, technical capabilities will be more important, and a higher-priced product could be the right choice.

Many decisions to upgrade network infrastructure are made without considering the business requirements. For a network architect to be successful, they must work more closely with other parts of IT and stakeholders. As part of their regular work activity, network architects need to have regular dialogue with the counterparts working on applications and business processes and also be connected to business stakeholders that are looking to IT to help improve the business. A focus on meaningful business requirements, rather than a set of perceived technical requirements, will ensure a better solution. A network architect that is well-connected can be seen as a facilitator for new opportunities.

At a more-tactical level, the network architect should map these requirements into specific functional requirements for the network. The most important part of this task is clearly defining the technologies needed for the job functions. This will help with the traditional problem of buying technologies "just in case"' (a good current example is Gigabit Ethernet to the desktop). Years of experience have taught us that “just in case” rarely, if ever, comes, and these additional expenditures are wasted. On the other hand, a solid understanding of the business user requirements could drive investments in technologies that can make a significant difference — for example, investments in unified communications (UC) or application acceleration (for more insight on this topic, see "Toolkit: Best Practices for Aligning Networking and Business Needs").

Building a strategic plan enables the organization to take back control of its future and to ensure that the network becomes an enabling asset for the organization. The strategic plan will demand an understanding of the business requirements, as well as input from vendors and other outside advisors, to prioritize the layout and the direction of activity for the network organization.

The strategic plan becomes the high-level road map and timetable for major network projects whether new initiatives — such as UC or application fluency — or defines logical upgrade cycles for major building blocks (such as upgrade edge switching to prepare for UC implementation or, in some cases, just technology refresh). The intent of the strategic plan is to provide high-level direction, identify key projects and map key business initiatives to enabling technologies in the network. It should not include all the details of products/vendors — that's for other stages and activities.

At its basic level, total cost of ownership (TCO) is made up of three main elements: the capital cost of the equipment (and associated software licenses), the ongoing maintenance contracts and the operational costs (labor costs) that it takes to run the network. Vendors that charge a premium for their products will always point to the fact that operations (generally the labor) is the largest portion of TCO and that capital costs don't matter. However, all the extra funding spent on equipment and maintenance services is less budget available for head count. When the difference between equipment alternatives is small (less than 10%), the labor impact will be negligible. However, any larger delta will quickly affect the network operations team's ability to deliver service at an equivalent TCO.

One topic that comes up a lot in respect to network TCO is whether there is a single vendor advantage. Within a building block, there is a clear, single vendor advantage in most organizations — simplified operations, training, sparing and consistency of features all help reduce costs. However, between building blocks is another matter. No vendor has tackled the operational challenges of building an integrated network. Most of the operational complexity is the responsibility of the IT organization, and there is little or no operational advantage to using a single vendor across building block boundaries. For larger organizations, any single-vendor advantage is further mitigated, because these larger organizations often have specialized operations groups for their building blocks.

Organizations that find themselves between Level 4 and Level 5 on the VIC have generally lost the discipline added through an open procurement policy. We have often heard procurement management use the phrase "we can't do our jobs" when dealing with a situation that is approaching Level 5 on the VIC. Using the VIC methodology ensures that procurement becomes part of the process. At a macro level, the VIC will save at least 25% of the capital spent on network technology. Equally important, it will ensure that the role price and procurement play in any decision is clearly tied to the business impact of each project.

This document has focused on the activities resulting in adopting the VIC. However, it is worthwhile to explore the consequences of not taking this approach.

At a technical level, things may appear easier. Little time need be spent evaluating technology. The primary decision being made is when to migrate to a newer version of your architecture. We have explored this topic in great detail in "Toolkit: Tactical Guidelines for Rethinking Network Design Practices" and have concluded that this leads to massive overexpenditures. However, more importantly, organizations miss out on many opportunities to invest in technologies to improve business processes. Further problems will arise from this approach. Enterprises will begin to lose network architecture skills, because little re-architecting is done, and, in many cases, enterprises will start to rely on their vendor to perform this function. Network staff will become outdated and miss the chance to explore more-innovative areas, because they're no longer geared to understanding emerging requirements. Networking staff will also become vendor specialists, rather than networking specialists, again narrowing their view of opportunities

On the business side, procurement functions become superfluous. If there are no vendor comparisons, no true requests for proposal (RFPs) and no negotiations, the procurement function can no longer add value to the process. One of the traps that organizations often fall into, especially organizations with well-defined procurement practices, is sending out competitive requests for quotation (RFQs) to multiple reseller channels representing their chosen vendor in an attempt to hide a sole-source approach to procurement. This clearly contradicts the intent of the original procurement practices and does little to enhance their financial position. In these types of situations in mainstream networking technologies, the bids will typically differ by less than 5%. In a truly competitive situation, bids will vary by 50% or more, and all bids will be noticeably less than taking the sole-source approach.

On the surface, not using the VIC may seem easy. However, the reality is this will make doing business more difficult.