Having a clear framework can make a big difference in the success of your infrastructure services. As a part of my career at companies like Netflix, Sun Microsystems, Complete Genomics and recently as a Partner of StrataFusion Group, I developed a toolkit to help get my head around all the aspects of IT infrastructure management to enable successful change for growth and higher efficiencies. The framework’s innovation is primarily around how to look at the ever-changing technology landscape but is complemented with organizational and process points of view.
To help others who may be struggling with this topic, I wanted to provide this overview.
To start, I define IT infrastructure by layer:
- Services: Think of identity (active directory), databases and common services like email and collaboration. Out of scope for this discussion would be the actual business apps like ERP and CRM, etc.
- Compute: All server and Operating Systems (e.g. Linux, Windows) components.
- Storage: Anything that holds data like Hadoop, SAN, NAS and is often shared between servers and applications.
- Network: All Wide Area and Local Area network components, including load balancers and firewalls.
- Data Center: Power, cooling and space to hold it all.
To make sure you manage all key aspects of each layer, ask yourself the following questions:
- Availability: What is the availability profile? MTBF and MTTR for hardware or a service, for example.
- Security: How do I ensure only authorized people and processes can affect the device or service?
- Performance: What are the latency requirements for any response from any device or service?
- Economics: What are the key cost metrics and how does that impact how I deploy new devices and services? Think of reserved instances vs. on demand in AWS terms.
- Change: What changes do I need to plan for: Operational (patching) and business (how long will the device or service exist? 1 hour or 5 years?).
Simplifying is always helpful when dealing with complexity and for the keen observer, you might have noticed that if you take the first letter of each aspect I get: ASPEC. Both the layers and ASPECs can be used in many different contexts. For example, when writing a project definition document, you can use these to describe all key and relevant requirements. From an operational management perspective, you can use this to define KPIs. From an organizational perspective, you can use it to find gaps in capability or focus.
To leave you with some examples below is a matrix that illustrates the types of considerations per layer and aspect.
I hope this framework can help you and your teams improve your infrastructure services and assist in driving the right decisions as you implement new Infrastructure paradigms, like cloud computing, during your transformation projects. Don’t hesitate to reach out if you have any questions or comments.