Are You Global or International?

Is your organization global or international? Do you know the difference? Does it matter in terms of how you plan for and carry out technology operations such as support, procurement, hosting or messaging? You should know and yes, it makes a huge difference to the structure of your technology operations. Trying to operate a global technology strategy at a company who is truly an international entity will surely pit business needs against your technology goals, setting the stage for failure. So are you global or international? I am sure there are volumes of business school literature on this topic but here is a simplified distinction that is immediately relevant to your technology planning efforts.

Global companies will produce standard products or services that are not tailored to the specific tastes or needs of specific country markets. Usually, such products or services will not be differentiated by brand recognition and may represent either commodities that serve as inputs to other products or services or as standard outputs that don’t vary across markets. An example could be an organization who produces chemicals that go into other industrial products to produce a final result. While certain aspects such as specific packaging or regulatory considerations may vary from market to market, there is more commonality across markets than differences. This has a huge impact on how you are able to design and structure your technology systems and associated services. There will likely be a single set of business systems that have been slightly customized to fit the needs of specific markets. A centralized infrastructure and associated support model may function well in a global organization. Such centralized services could potentially go beyond commoditized IT services such as email hosting to include more advanced services such as centralized Service Desks. Can all technology services be centralized in a global organization? Of course not, local market needs will always dictate some degree of local flexibility. In a global organization however, the technology synergies across operations in different regions around the world will outweigh the need for local differentiation.

International companies may operate in markets around the globe, but tend to offer distinct products or services in each market that are customized to local tastes or market requirements. Products or services such as consumer goods that rely heavily on brand recognition tend to be heavily tailored to local tastes, customs and trends. For example, a packaged meat company operating in Asia, Europe, Latin America and the US will likely have highly differentiated SKU’s for each specific market. In addition to product differentiation, consumer goods often have very distinct and varying methods of distribution across global markets. For example, in the US, consumer goods may be delivered to central warehouses of large big box retailers who then ship products through their own logistics chains to grocery shelves. In some Asia markets, the dominance of the small, local shops may dictate a Direct Store Delivery (DSD) model where product is delivered straight from the manufacturer to the store shelf. In International organizations, the need for local market flexibility will dictate a need for market specific technology services. This does not mean there are no technology synergies to be had at international organizations. Again, commodity services such as email hosting or centralized infrastructure support along with leveraging buying power through centralized procurement may represent true opportunities for working globally while acting locally.

I have obviously painted this topic with a wide brush but hopefully the point is clear. Understand the needs of your organization in terms of its operations around the world. Don’t try to centralize services where local flexibility is needed in order to win in the local market. Don’t leave services local that represent cost saving or opportunities for scale when managed centrally. Understand that there are times when being global and being international are not the same and that a misaligned technology strategy can hamper your organizations success in either case.

You Don't Understand Your IT Costs

Do you know what your IT costs are? I hear many technology Directors now saying, absolutely! They will rattle off their IT CAPEX budget for the current year and perhaps the last two or three years. They probably have a line item view of the IT P&L with a deeper view into some areas such as maintenance contracts, consulting expense and supplies. For the majority of technology directors however who came up through the ranks of network engineering, data base administration or something equivalent, that is where the understanding ends. Many do not understand how CAPEX ultimately ends up on their P&L (through depreciation) and will struggle when asked to classify their total IT spending into categories such as business application expense versus collaboration application expense. Ultimately however being able to classify your total IT spending into categories that you can then easily use to bench mark your spending levels against industry standards is fundamentally what is meant by “understanding” your IT spend. Below are three practical tips that can be used by Directors just trying to get a handle on overall IT spend or by new comers trying to truly understand how his or her new IT operation functions.

Know Your Asset Classes

Every company will categorize capital spending into classes. These classes are used by accounting for grouping specific assets together for depreciation purposes. For example, IT may have the asset classes “PC's”, “Servers” and “Software”. The depreciation on your P&L is the sum of the depreciation from each of these asset classes. The more detailed your asset classes the better, this will enable you to answer more specific questions about how your IT OPEX breaks down. For example, the total amount of your IT OPEX dedicated to PC's for 2009 may be equal to the amount of your total maintenance contracts dedicated to PC hardware & software PLUS the amount of depreciation carried on your P&L that is directly attributable to PC purchases. To know the amount of depreciation directly attributable to PC purchases you must of course have an asset class specific to PC's. So, go to your accounting department and ask for an IT depreciation report by asset class. See if you get the level of detail you need to make sense of the depreciation on your P&L, if not talk to your accounting manager and ask about creating IT asset classes that match your desired categorization strategy.

Know Your Maintenance Costs

Anyone who has had responsibility for managing maintenance contracts within a medium to large IT operations knows what a challenge this can be. You may literally have hundreds of hardware & software contracts all with different renewal dates. Very large IT operations may have a dedicated person and a sophisticated IT management software package dedicated to keeping track of maintenance contracts. In the typical medium IT operations, this duty is loaded onto the technology director who is generally armed with a self created spreadsheet for tracking. Here are some tips. First, get a feel for what contracts you have that are “pre-paid” expenses and which ones get expensed in the period they are due. Usually larger contracts (read Microsoft or SAP) get amortized over the course of a year so from an accounting perspective they effect net income evenly across the year. The cash is of course paid when the invoice comes but the “expense” for these contracts is spread evenly across your P&L throughout the year. This is important from a budgeting standpoint, you should create a list of your “pre-paid” maintenance contracts and have accounting start the amortization of these amounts on the first day of your fiscal year. You should classify these expenses on your tracking sheet into categories that match your asset classes. Once you have a depreciation report by asset class along with a detailed view of your large maintenance contracts both categorized into your desired OPEX classifications, you are well on your way to being able to categorize your total IT yearly OPEX. You cant forget your smaller maintenance contracts that simply expensed as they are received. In aggregate, these can add up to be significant so you need to capture them in detail on your maintenance contract tracking sheet. Ask your accounting manager for a report detailing the line items that made up the maintenance contracts on your IT P&L. Generally, maintenance line items listed as “accruals” will be the “chunks” of the larger maintenance contracts being spread evenly throughout the year. There should be detailed enough description on all other line items for you to ascertain what the expense was for (e.g. web filtering software etc.). Classify these contracts into your desired categories as well and you should have a firm grasp on your yearly IT maintenance contract commitment.

Understand your IT GL Codes

General Ledger (GL) codes are used by your accounting department to classify expenses into line items that will be shown on your IT P&L. For example, if you look at your P&L and see a line item called Wide Area Network, chances are your company has an IT GL code labeled Wide Area Network. As bills come in from your WAN carrier, they are “coded” to this GL account. It is important that you have IT GL codes at an appropriate level of detail that will allow you to easily classify your P&L costs into your desired IT OPEX categories. For example, if one of your desired categories for tracking IT OPEX expense is “Customer Support Operations”, it would be ideal to have a GL code labeled that and have all expenses related to that activity coded to that GL account. Avoid GL codes like “miscellaneous”, these create black holes into which IT expenses disperser, never to be understood again. Certain GL codes may be dictated by the need for your organization to report expenses in certain ways for regulatory or tax purposes. This means you will likely never see your IT P&L arranged totally into the categories your desire. For example, you will likely always have GL codes for “Salaries”, “Benefits”, etc.. So you will always have some leg work to do to completely organize your P&L into your desired OPEX tracking categories but with a set of IT GL accounts that match your goals as close as possible, your job will be much easier.

With these three steps you will be well on way to having a full understanding of your IT OPEX. Having this understanding and being able to classify your IT expenses into categories that can then be used to benchmark your IT operations against industry norms will gain you huge credibility among your management team and will give you a clear set of goals to manage towards.

Being a True Business Partner as an Infrastructure & Operations Manager

Several things I have been working on lately seem to have a common theme, defining “what is enough”, enough redundancy, process, response time etc.. I have spent some time studying several of the popular Infrastructure and Operations maturity models as defined by industry leaders such as Gartner, Forrester or IDC. All of these models make the not so implicit assumption that you “should” be driving your IT department “Up” the model. In Gartner's model for example, your IT operation is not considered a “business partner” until you have ascended through all the various layers, each requiring higher levels of process discipline, scalability and business service uptime. On the surface it seems hard to argue against continuous improvement as it relates to your IT operations. I certainly believe you should always search for ways to run your IT operation or to build your IT infrastructure in better ways, however it seems an over generalization to imply that you ALWAYS need more process, more redundancy etc.. I would make the argument that to be a true partner to the business, you as an IT leader should focus on defining exactly what your business is trying to accomplish in the marketplace and target your level of IT infrastructure and operations rigor accordingly. It may be tough for the die hard technology professional to accept that a certain degree of risk is acceptable or that it is OK to not be on the latest hardware or software. What really enables you to drive value for the business is understanding the level at which your business “needs” you to operate and ensuring that you do not operate below or ABOVE that level. Operating below an acceptable level in terms of service levels, infrastructure scalability or redundancy certainly puts your business and its go to market strategy at risk. Operating above where your business needs you to be may be diverting capital and resources away from more value added activities whose value to the business outweighs the risks you may be taking in certain areas of your IT operations. So before you to go your CFO and start showing him or her charts and models outlining where you SHOULD be as an IT organization, make sure you have a clear understanding of where your business NEEDS you to be.

Are You Over Virtualizing Your Technology Infrastructure?

In a recent key note address at Gartner’s 2010 Infrastructure and Operations Summit, Raymond Paquet, Managing VP at Gartner, made the point that consistently over the last eight years 64% of the typical IT budget has been dedicated to tactical operations such as running existing infrastructure. A driving factor behind this consistent trend is the tendency of technology managers to over deliver on infrastructure services to the business. Paquet makes the point that technology managers should always be focused on providing the right balance between technology solution cost and the quality of service the solution provides to the business. As the quality of a technology service increases the cost of that service will naturally increase. There is often still a gap in the quality of service a business requires and what is architected and built by technology professionals. The key is to understand the businesses requirements in terms of parameters such as uptime, scalability and recoverability and to architect an infrastructure aligned with these requirements. Sounds simple, right? Often however technology professionals find themselves (usually inadvertently) swept up in implementing technology solutions that at specific levels of adoption add value to a business but at unnecessary levels of adoption serve to pull budgets and resources away from more value added activities. Virtualization is a case in point.

The gap between quality of technology services required by the business and the cost to deliver them can be observed today in the tenacious drive by many technology managers to virtualize 100% of their IT infrastructure. Gartner research VP Phillip Dawson points out what he calls the “The Rule of Thirds” with respect to virtualizing IT workloads. The theory is that one third of your IT workload will be “easy” to virtualize, another one third will be “moderately difficult” with the remaining third being “difficult” to virtualize. Most technology organizations today have conquered the easy one third and have began working on the moderately difficult workloads. The cost in terms of effort and dollars to virtualize the final one third of your IT workload increases exponentially. Are you really adding value to your business by driving 100% of your environment into your virtualization strategy? The recommendation from Dawson is to first simplify IT workloads as much as possible by driving towards well run x86 architectures. Once simplified, IT workloads with low business value should be evaluated for outsourcing or retirement. Retirement may consist of moving the service the application provides into an existing ERP system thus leveraging existing infrastructure. Workloads with high business value will likely now (after simplification) be cost effective to bring into your virtualization strategy.



So be selective in the applications you target for virtualization. Be sure that all steps have been taken to simplify the respective applications technology infrastructure so that it is not in the upper third of costs and effort in terms of virtualization effort. Outsource or retire complex applications where applicable rather than force fitting them into your own virtualization strategy. Look for ways to retire low business value applications with complex technology architectures (such as moving them into an existing ERP package). The bottom line is that all technology investments and initiatives must be aligned with your organizations needs and risk tolerance. Virtualization is no different. Making unnecessary efforts to virtualize certain applications may be doing more harm than good.

A Simple Offshoring Model

I recently had the opportunity to travel to India to meet with a large provider of IT services. The purpose of the trip was to understand how best to work with this organization to deliver additional resources and thus business results to my organization. Some of the questions that needed answering where: When does it make sense to utilize offshore IT resources?, What is the best way to run projects using offshore service providers?, What are the criteria for deciding if a particular project is a fit for the utilization of offshore resources? What follows is a model I created based on my observations and peer discussions. This model has in it some implicit lessons learned from this particular trip as well as previous project experiences. The model is fairly self describing. The underlying principals are that projects with a high dependence on institutional knowledge require greater in-house resource involvement whereas projects that involve more standard business processes or technology are better fits for the utilization of offshore resources. Also, larger projects lend themselves better to the utilization of offshore resources due to the inherent overhead involved in managing offshore resources. Most IT managers will likely find this a common sense line of reasoning, the model simply provides a simple and clear representation of this logic.

You Don't Have to be a Giant to be Green

Last week I was fortunate enough to attend SAP Virtualization Week at the SAP Co-Innovation Labs in Palo Alto, California. The conference consisted of three tracks: Virtualization, Cloud Computing and Green IT. Lots of thought provoking material was presented by SAP, consulting partners and customers. When I attend these type of events I look hard to find a few practical take aways that could be put in place immediately. Of course these sessions help frame my thinking on long-term strategies around SAP virtualization and Data Center design, but what can I go home with and ask my team about next week? One of those take away points for me last week was this: You don’t have to be a giant to be green.

At surface level Green IT seems like a concept relative only to the largest of IT organizations. Organizations such as Intel and Colgate-Palmolive who can tell stories of collapsing 50 or 60 global data centers down to one facility certainly have a green story to tell. Organizations such as NetApp who have pioneered efficient data center designs can go to conferences to show how they received a million dollars in rebates from their energy provider. These are great stories, but as I sat through the first couple of these last week sipping Starbucks coffee I was thinking to myself “This is awesome, but what can I do, how is this relative to me?” How can a < $1 Billion enterprise who leverages a colocation service for data center space devise a green IT strategy? What about very small organizations who have all of their servers hosted at their own facility, all in one rack that sits in a locked (or sometimes not) closet that is doubling as storage and data center space? As the week went on I managed to pick up several practical action items that can be leveraged by smaller IT shops to build a green story. While in smaller IT shops the savings may not be as dramatic and jaw dropping as global IT operations, keep in mind all things are relative. If you can show where you started and demonstrate a thoughtful effort that created a tangible reduction in energy consumption and thus cost then you have executed a successful green IT strategy. It may not be enough to save the planet, but it is your part and shows that you are doing all you can to be a good steward of your organizations IT operations.

Know Where You Are

Your tangible achievements with Green IT thinking will be measured in percentage points. For example, a 10% reduction in power consumption, a 2% reduction in utility costs etc.. Obviously, to show these numbers you have to know what you are consuming today. Even if you have a single rack of servers sitting in a closet, do you know how much power they are consuming? Do you know how much you are paying monthly in energy costs to run the equipment you have? The answer to these types of questions becomes slightly more challenging for mid-sized IT shops leveraging colocation providers for data center space. Do you know exactly how many power circuits and what type (120/280V, 20A/30A) are provisioned to your space? Do you know the current draw on those circuits? In a colocation environment, a very practical first step is to install intelligent Rack Distribution Units (RDU’s). There are lots of vendors who offer these, see this one from APC as an example. Intelligent RDU’s will give you the data you need to establish your baseline. Most of these devices provide an HTTP interface that gives you basic statistics and reporting. You don’t need anything fancy, just a browser and a spreadsheet. Get a total average draw for all of your equipment over a length of time long enough to cover any major fluctuations that may occur in your computing environment.

How Redundant Do You Need To Be?

In a typical server deployment, redundancy is built into the design. We expect a certain degree of equipment failure so we account for that in our capacity planning and design efforts. So ask yourself this, how much redundancy is enough? This has a direct impact on green IT thinking. Most servers have redundant dual power supplies. Think of the environments you have with redundancy built in so that if you lose a single server you will have no downtime. Now ask, why do each of those servers have TWO power supplies plugged in to prevent it from failing in the event a power supply goes bad or you have a problem with an electrical circuit? Doesn’t your design accommodate for losing a server anyway? The real answer to this sort of question is that you plug in both power supplies on each and every server even in a redundant server arrangement because that is how you have always done it. Challenge the notion that this is necessary. You may find that with this simple thought process you cut out 50% of your power consumption in certain environments. Also, categorize your systems into different classes of criticality. This is a natural exercise for disaster recovery planning but is not often thought of when planning for power design. If an application running on a server can be down for a defined period of time with no serious impact to your business, maybe you don’t need to plug in both power supplies and provide redundancy at the power level. Again, challenge the assumption that just because a piece of gear has two power supplies that they MUST both be in use.

Buy Green

Pat of knowing where you are in terms of your level of green IT operations is knowing where your vendors and partners stand. Make energy efficiency a part of your purchasing decisions when it comes to IT equipment and service. As you are gathering quotes for hardware, ask your vendor to provide you with energy rating information for the equipment along with the price. With respect to service such as consulting, ask your provider what they are doing to reduce their carbon footprint and provide services in a green way. For example, how much of the work can be done remotely versus onsite? This not only has a practical implication from a green mindset, it also reduced T&E expense. If you leverage a collocation provider for data center space, insist that your provider be able to tell you the PUE of their facility. Remember, you are paying your provider their cost plus margin. If their operations are not ran efficiently then their costs will be higher and you will pay the price. Leverage the information you are gathering from your intelligent RDU’s to renegotiate the way you are buying power in your colocation space. For example, many colocation providers charge you “by the circuit” for power. Their price often includes their cost for delivering you the energy on that circuit plus their cost for removing the heat generated by the consumption of that energy. If you can tangibly show that you are only consuming a fraction of the energy provided over a circuit and thus generating less than a 1:1 ratio of heat to circuit capacity then you have a strong case to moving to a “pay by the drink” model for power. Your case here is that you should be paying in a manner that covers your providers OPEX, not their CAPEX. Your providers true operational cost to remove heat from the data center is a function of how much heat you actually generate plus how efficient they are at removing it.

These are just a few practical suggestions. All of these things can be done on a modest IT budget. The key is to understand where you are starting from, take tangible steps based on that knowledge and measure your change. Again, success is measured in percentage points, not raw numbers. As manager for a small or mid-sized IT shop, you won’t put up numbers the likes of what you will see from global, Fortune 500 IT shops. Success is demonstrating that you are aware of the need to be a good steward of your organizations IT operations relative to its environmental impact, measuring the results of your efforts and arming your organization with your numbers to add to its overall sustainability efforts. Oh yea, you will likely save money too.

The Value of an Outside IT Resource: Pointing at Elephants

There are times in the evolution of an IT organization where bringing in a new team member from the outside has significant value. While at key evolutionary points it might make sense for this new injection to come in the form of a new, permanent hire, there are times when simply bringing in a consultant can have the same value. The “value” in these cases is not fully supplied through additional technical expertise. Sometimes, an outside resource can prevent proposed solutions from being constrained by Group Think. IT teams who work together for a while come to know and understand the implied constraints that often surround proposed technical and process architectures. These implied constraints may come in the form of known manager biases, past group experiences, perceived realities of the organization (correct or not) and the simple desire to “fit” and be perceived as a team player. Many organizations do purposefully cultivate a specific corporate culture aimed at helping all members of the company to understand the guard rails within which the organization wishes to operate. New hires to IT teams such as data center operations, network engineering, database administration or software engineering certainly need to learn and understand the corporate culture which may help to define the big picture of the overall IT strategy. At a tactical level however, new hires can bring in new experiences, challenge team assumptions and ask fresh questions. In short, a new hire can point at the elephant in the room that current team members understand is there but also understand that they should not point out.

While new hires will likely cause the existing team to cycle through the typical stages of group development (forming, storming, norming, performing), it may be a move that pays dividends at key evolutionary milestones in an IT departments growth. There may be other times however where an outside resource can add value to a particular decision. Consultants are often sought out for their technical expertise or their real world experiences with other clients. Sometimes, the value of a consultant is also his or her “unbiased” opinion on a particular technical design or process improvement effort.

Whether it is a new hire at a strategic evolutionary milestone in the IT departments growth or a consultant brought in to evaluate a specific thought process, part of the value an outside resource provides is to point at your elephants.

Digital Distractions

In a recent meeting, I looked around the table and noticed many of the attendees typing on laptops or thumbing through emails on a Smart Phone. The thought crossed my mind wether these people where diligent multi-taskers’ dedicated to productivity or whether they simply had nothing to contribute to the topic at hand. Perhaps the organizer of the meeting had invited them and they had simply came out of either politeness or a sense of obligation due to the organizers rank on the company org chart. Perhaps they really did need to be there and where totally missing critical information about the current topic as they dazed into glowing LCD screens. Regardless, conducting a meaningful meeting with a room full of folks armed with digital distractions can be a daunting task. The easiest way to overcome digital distractions is to simply ban them from the meeting room. No laptops allowed, no checking email on smart phones, all phone ringers set to vibrate. If this is not possible however, here are a few tricks of the trade that may help minimize digital distraction.

Make sure follow-up items don’t become immediate tasks

When access is immediate though laptops, it becomes easy to let items tagged for follow-up become immediate action items. For example, someone may be assigned a task of sending someone else a copy of a system configuration as a follow up item. The assigned team member immediately jumps on and starts trying to grab the configuration. Problems occur when a small issue arises getting the configuration, the team member whispers to a colleague sitting next to him and they both start working on the issue. Before you know it, you have two separate streams of work and thought going on. Explicitly state which items are follow-up items and inform attendees not to work on these items now while the meeting is still focusing on the task at hand.

Let someone else "drive"

It is common for work to get done during meetings with one person projecting up a spreadsheet, word document or Visio diagram, filling in content with the input of meeting attendees. It is also common for the organizer or the most senior person at the meeting to "drive" the work by being the one projecting up the document and typing in the content. I have found it useful to let someone drive during working sessions. You will often know who the folks are most likely to be distracted by working on side items during meetings, let them drive. By having your most easily digitally distracted team members project heir desktops on the screen while work is getting done you can help them and the meeting stay on task.

Call people out

I often get to the end of a meeting or even a section of the meeting, turn to the person who I have noticed working on other tasks during the meeting and ask them to summarize for the group what we have just covered. This is not meant to embarrass anyone and I never push it if the person obviously does not have an answer. It is an effective tool if used consistently as team members will come to expect this and will be more likely to at least home in enough on the current discussion to be able to articulate the current tasks in a short summary.

Have an agenda and roll for everyone

This point is more of a general meeting principal than it is a way to overcome digital distractions. You will find though that if you follow this consistently, people will likely start to see your meetings (and even the fact that you are calling a meeting) as more relevant. Know who really needs to be there and only invite people who will play an active role in the task the meeting is meant to accomplish. Be clear at the start of the meeting why everyone is there, what you want from everyone during the meeting and what the end goal for the meeting is. Foster cooperation and interaction to keep people from falling into a digital distraction.

Demonstrating the Business Value of IT Infrastructure

A consistent theme in thinking around I.T. strategy is that your I.T. strategy must be aligned with your organizations business strategy. The term I.T. strategy is often used broadly to mean the overall set of activates and projects in which an I.T. organization is engaged. A recent McKinsey article titled “How CIO’s Should Think About Business Value” describes I.T. as adding value to an organization at two complimentary levels. The “core asset value” of I.T. consisting of hardware and software create tangible asset value for an organization. I.T.’s “value in use” varies from organization to organization and is a measure of how well I.T. is leveraged to enable core business strategies. The term “I.T. in use” here again is defined as a holistic set of I.T. activities. The problem with such a sweeping definition is that in most medium to large sized organizations there is usually two parallel streams of strategic thought and planning occurring inside I.T. There is “application strategy” which is the long-term planning of an organizations software landscape. It is the capabilities of software that will serve to enable key business processes. As such, application strategy is often seen by business executives as being synonymous with I.T. strategy. But where will the software run? How cost effective is an organization in its execution of activates required to support software functions? Answering these questions is the goal of “infrastructure strategy”. Infrastructure strategy is the long-term planning of technology investments such as networking, storage and data center design. The infrastructure investment portfolio should be closely aligned with both an organizations business objectives and its long-term application strategy. Collectively, application strategy and infrastructure strategy should coalesce to engender value creation from I.T. Due to the different skill sets between the two I.T. domains, application strategy and infrastructure strategy are generally planned separately. It is up to the I.T. infrastructure leader to ensure that his or her investment plans are geared towards building an I.T. infrastructure that is synergistic with the application and business landscape.

Infrastructure strategy rarely gets discussed at joint planning sessions between business and I.T. leaders. Metaphors such as “The Cloud”, “The Grid” as well as analogies such as “Utility Computing” have all added to the notion that technology infrastructure is a commodity with little intrinsic value. In the McKinsey article “Where I.T. Infrastructure and Business Strategy Meet” the authors suggest that thinking of I.T. infrastructure as a commodity is a mistake. McKinsey suggests that the individual pieces of an infrastructure such as storage devices and networking components may be commodities. However, the manner in which these technologies are designed, integrated and managed combine to form a whole that is greater than the sum of the parts. It is beholden on the I.T. infrastructure leader to help his or her business leaders “see” the vision of how the infrastructure strategy will generate business value. So how can the infrastructure manager clearly represent the relationship between technology investments such as storage arrays and business objectives such as supply chain execution? A good tool for connecting the infrastructure and business dots is the use of “Strategy Maps”.

A strategy map is a tool developed by Harvard Business School professors Robert Kaplan and David Norton. Kaplan and Norton are the developers of the Balanced Scorecard approach to business management. The balanced scorecard evaluates an organizations performance by examining key performance indicators in four perspectives: financial, customer, internal, learning & growth. You can learn more about balanced scorecard here. Strategy maps can be considered a method for visually displaying the set of organizational activities to be executed in each perspective and the impact these processes will have on each other. You can find a detailed discussion of strategy maps in Kaplan and Norton’s book “Strategy Maps”. At a high level, strategy maps can provide you a one slide representation of how your I.T. infrastructure strategy ties directly to your business strategy. I will walk through an example strategy map explaining how the various pieces relate. You can download the example map here.

When Kaplan and Norton discuss the placement of I.T. assets on a strategy map they classify systems into four categories: transactional, transformational, analytical and infrastructure. In my example, I focus more on mapping infrastructure investments to business strategies rather than classifying the infrastructure investments into categories. Showing how your seemingly unrelated technology infrastructure and business strategies compliment one another is the goal. At the top of this simplified example you have a clearly stated business goal of growing U.S. market share by 10 percent by 2012. Directly under that goal are four operational initiatives that the business has defined as paramount for achieving that goal. This example shows an application level strategy focused around SAP and the SAP suite of business applications. For each business level objective, a corresponding SAP application is identified as mapping to the features necessary to achieve the goal. For example, in order to leverage a skilled sales force an organization will need a human capital management system for skill development, talent identification, training and performance appraisals. Similarly, excellence in supply chain execution will require a system such as SAP APO to streamline warehouse, production and logistic functions. The concept of mapping systems to business needs can be applied to any vendor suite as well as custom developed applications. The bottom part of the example strategy map serves to connect specific I.T. infrastructure investments to the application and business layers. In this example, certain infrastructure investments such as consolidated storage and virtualization will serve to enable features across the entire application portfolio. For example, in an SAP environment production systems are regularly copied to quality systems in order to accommodate testing of new features against up to date transactional data sets. The inter related nature of SAP e environments often necessitates what is termed a federated system copy meaning that all quality systems (HCM, APO etc..) will need to be refreshed at once. The speed and agility at which this can be done will directly impact the speed with which new development can be tested and moved to production. The time it takes to move new features to production impacts the time it takes the business to realize strategic benefit. Virtualization will have a direct impact on an organizations ability to scale its SAP based operation while maintaining a steady level of OPEX spending on servers. Large ERP landscapes such as SAP and Oracle often result in server sprawl as each landscape requires multiple systems for development, test and production. Virtualization will help provide those landscapes and the business value they create at a competitive cost. Initiatives such as strengthen business relationships and implementing a more integrated supplier network will necessitate targeted infrastructure investments such as enhanced network edge security. Mapping investments in technologies such as intrusion detection systems and firewalls to a strategic business imperative clarifies their relationship.

The decisions you make around your I.T. infrastructure strategy can either serve as a conduit for business value creation or as an impediment to it. It is important that as an I.T. infrastructure manager you help your business leaders understand how seemingly commodity technology investments relate directly to businesses strategy. The use of Strategy Maps provides a clear visual representation of the relationship between business strategy and I.T. infrastructure capabilities. This mapping should also help I.T. infrastructure managers think clearly about their own strategy development focusing on business value rather than bits and bytes.