When technology managers talk about infrastructure, they are referring to foundational elements such as network switches, servers, backup systems and security devices. There is also the software infrastructure of databases and core applications, such as order entry, which must stay up 24×7 to support the business. As these infrastructure elements age, you should start planning for when they will be updated or replaced. We will investigate three main areas of achieving this – making decisions, designing success, and selecting vendors.
Making Decisions
The Infrastructure Platform Risk Calculator below (Table 1) provides broad guidance on how to approach these decisions.
Instructions
Go to the right-hand column labeled “Your Platform” and enter selected Platform name. Answer each category question by entering (1 = Low, 3 = Moderate or 5 = High) to help you assess the right Risk Scale. Add up your values to get your Risk Total and Risk Level.
Design Success
Application infrastructure design is a tricky business: A poorly designed infrastructure could cause a loss of performance, and even loss of information. A well-defined and designed infrastructure should improve application availability, reliability, maintenance, and future growth. Proven design solutions should be able to be reused within organizations to reduce process time.
Developing an in-house template or model for your organization will help you determine the probability of success of your infrastructure design by rating it across three levels. It will also be useful in compiling highly detailed documentation of your infrastructure, which will come in handy if hardware or software components go down.
Level 1: Conceptual Infrastructure Design
The first level outlines project infrastructure scope.
The following conceptual dimensions should be considered with suggested maximum weighted values added to overall design. Your job is to rate (0% – maximum %) each dimension for your organization and add up the total (maximum total is 25%).
- Project strategic agenda – 3%
- Service-level requirements: outline of expectations about performance, uptime, and disaster recovery (DR) – 7%.
- Component solution diagram: a high-level architectural diagram that includes key hardware and software components with their individual and collective purposes – 5%.
- Hardware capacity footprint: a prediction of sizing requirements, such as number of servers and databases needed – 5%.
- Environment list: defines the purpose of hardware and software components and their relationships to each other in the phases of development – quality assurance, pre-production, production, deployment, and DR – 3%.
- Development agenda: a statement articulating the degree to which applications will be developed – out of the box, moderately configured or extensively customized – 2%.
Level 2: Logical Infrastructure Design
The second level identifies project infrastructure requirements.
The following logical dimensions should be considered with suggested maximum weighted values added to overall design. Your job is to rate (0% – maximum %) each dimension for your organization and add up the total (maximum total is 60%).
- Software architecture design objectives: a detailed account of software performance expectations – 12%.
- Software architecture design diagram: a detailed diagram of components, including requirements for networking, load-balancing, and firewalls – 24%.
- Estimated load profile and sizing: a full breakdown of infrastructure expectations for load profiles, current users, equipment locations and expected response times – 12%.
- Hardware environment design and diagrams: lays out detailed hardware and software components for each development environment – 12%.
Level 3: Physical Infrastructure Design
The final level provides a map of infrastructure specifications.
The following physical dimensions should be considered with suggested maximum weighted added values to overall design. Your job is to rate (0% – maximum %) each dimension for your organization and add up the total (maximum total is 15%).
- Architectural diagram for servers: a map of all physical components, including name, make and model of server with its location and IP address, as well as storage size and type – 7%.
- Architectural diagram for databases: a map of databases and any configuration or customization detail that applies – 3%.
- Architectural diagram for networking switching/routing layer – 3%.
- Architectural diagram for protocol security mappings – 2%.
Understanding Your Grand Total Score:
- 80 – 100%: High probability of success. Work on your weak areas, if any.
- 0 – 79%: Re-evaluate your total infrastructure design. Failure to do so may impede project success.
Selecting Vendors
Before sending out a proposal request for hardware to selected vendors, you need to have an agreed-upon rating/ranking system that is fair and objective, to help remove any bias or politics during the selection process. Using the matrix below (Table 2) can help you identify which vendor offers the best solution for your enterprise, by comparing its strengths and weaknesses by category. Keep in mind that your main objective in choosing a vendor is to select the best overall solution based on your organization’s most important criteria.
Instructions
The weighted proposal ranking matrix example for UNIX servers shows nineteen key criteria, their assigned scores (0 – 4), rankings (0 – 4), weighted scores (weight x ranking), and corresponding for vendors X and Z. Since Vendor X has the highest weighted proposal score (135), it is best vendor to select. Your organization could decide over time to update the weight values and criteria depending on needs. Also, the criteria and corresponding weights could be modified for other types of hardware proposals, such as Intel or storage systems.
Summary
The mentioned infrastructure improvements will be helpful for guiding your decision making, design success and vendor selection. This can be used for small, medium, and large corporations.
The winds are changing for large corporations who are moving part or all their infrastructure to cloud services, to lower overall IT costs. Public cloud services mean multiple organizations could be sharing the same server. Private cloud services mean an organization has their own dedicated server(s). So, if your organization is moving to cloud services, it’s extremely important to have an optimized cloud strategy. Many of the mentioned infrastructure improvements can be used in selecting a cloud vendor. For example, when to move from in-house aging platforms to cloud services, performance, service-level requirements, and estimated load profile. Also, it’s desirable if you use cloud services for production applications and services where you would want DR located on a different cloud, with the servers “housed” in a different part of the country as your production backup. In case of a disaster, DR will minimize the downtime, data loss, and the disruption of operations. Your thoughts on this topic and feedback on these tools would be much appreciated.
