Before we delve into IT and differentiation and the rest of the bumbo jumbo, ask yourself one question Do you crave to be different? If you are like the 99% of the rest of human population your answer will be yes. Yet, we act and behave with just one fear and that is the fear of non-conforming and still by conforming we seek to be different. This is also true in our IT world. Companies around the world today employ the same software, same type of infrastructure, same delivery process, same buzz words, ITIL, PMP, SAS, ISO, Cloud, n-tier, SOA etc. Yet somehow people assume their investments are deployed better than the competition, they employ the same one-dimensional metrics for measurement like bugs per lines of code, defects per function point, mean time between failures (MTBF), mean time to restore (MTTR), etc and assume if their scores on these are better then they are providing a better service. I think such a thinking is naive at best. So how do we tell whose IT department is better than the other and more importantly what does a "better IT department" mean to a company's bottom line?
One of the key challenges IT managers get roiled up in is trying to convince the business leaders how critical their service is and that IT is not just an overhead. In the act of circumventing such notions they ended up creating metrics and statistics that are foreign not only to the business but also to IT itself. The belief being that once having chosen this strange tongue of metrics as long as the graphs show forward progress we are ok. We have all seen such graphs that show how outages have reduced month over month, or the number of change related incidents are down, etc. You seldom here metrics like the key transaction response time in our online shopping cart has reduced by 2 seconds, or due to changes we made to the code the productivity of our call center agents increased by 30%. Why? This is because IT has always had this mirage that it doesn't really have to care about what its impact is on the business as long as their lights are all green then the business must be doing great. Somehow IT and the business seem to live on two different planets.
Below are things that IT can do to create better business outcomes: Create Relevance: The best thing you can do to reduce the divergence between IT and the business is to make sure both have the same goals. You can start this by making a list of all the imperatives the business has to meet to be successful. This means looking at all the touch points your business has with customers, vendors and employees. Then make sure your IT assets are addressing these touch points effectively allowing you better speed, flexibility and productivity. The key here is reevaluating how your applications are really addressing the needs of the business without the business having to rearrange itself to adapt to the application. This requires a sit down with the business and a clear plan to subject the business and the IT for a candid evaluation of each other. Installing a big ERP or going to the cloud just because it is cool and everybody is doing it will not help the business nor you.
Know what you have: If you don't have a clue what applications you have spread over your data center, consuming gazillion servers, power, space and everything in between then rest assured, you will be in the Twilight Zone for kingdom come! Having a CMDB (Configuration Management Database) is just a start, it at least lists your IT assets. What you can then do is to actually assign weights to these assets based on how critical an application they support or are part of. Then create an "asset web" that shows interconnectedness between your infrastructure components to reflect the fact that your applications are seldom stand alone but are connected, especially in this new world of SOA (Service Oriented Architecture). This will help you visualize what assets are really relevant to the business and get rid of applications and related infrastructure that don't directly affect the business in any meaningful way.
Reduce Risk: In my opinion a successful IT department is one that has the least risk or is the most consistent. So what does risk mean? Risk means all those things and activities that can occur which can directly affect the business bottom line and good will. In IT change is the biggest risk. If there were no changes be it application changes, patches, new release installation etc then the chances of you having an outage goes down significantly. But living in a real world there is no such thing as "no change", change is part of our lives and we have to learn to manage it the best way that we can. To reduce the risk due to change it is prudent that the team has the "asset web" to understand the impact of the change on components directly receiving the change and those connected directly and indirectly to these components. The best way to visualize this would be to imagine a trip wire across the impacted portion of your "asset web" and understanding how a change can trip that wire and proactively address issues and avoid the "deer in head light" look come Monday morning. Most business don't do the extra due diligence to coordinate with various teams and formally discuss changes. Reducing risk is also about investing time and thought when selecting applications, architecture, infrastructure, process and people that make up your IT department. All are part of the same chain and weakness in one means more risk.
Invest where you have to: While many parts of the IT delivery chain has indeed become commodity, the predictability afforded to a mature industry (if we can call IT that) is seemingly here and there. We can have all the process we want, but if we don't have the right people doing the right job then every safety net is moot. People are the glue that make process and technology work, so cherish and grow them. The right incentives and a "we belong to the same family" attitude will go a long way in fostering an environment where people want to work, then quality becomes second nature and overall outcomes are much better. Even when it comes to technology understand that while getting a good deal is important just beating down a vendor on cost is not a big achievement in the long run, if the technology does not fit with the business and second. It is important to make sure that you have the people who understand the technology and that you don't have to rely on the vendor hoping that someday your people will be able to manage on their own. Chart the technical attributes your people are good at, their strengths and weakness, now compare if the new technology is in the ball park of what your people are capable of handling. Don't shy away from investing in "production-like environments", we have all heard it time and again - "But we tested this and everything was fine. We don't know why it is behaving this way in production!" If you wish to mitigate the risk of change, then commonsense dictates the final test is done on an environment that looks exactly like production. One way to save money on this would be to repurpose temporarily the DR (Disaster Recovery) environment for testing before the production move.
Measure the right things: Coming back to the points we made at the beginning of this blog on what to measure for ITs impact, don't try to stuff your business with IT speak, make it plain speak that business can relate to. Measure business outcomes, choose attributes that mean something to the business performance and bottom line, for example if you are credit card company you would want to for example measure response time for every credit card swipe as a business measure. This means you will then need to map this business attribute or service to all the applications and infrastructure that support or are related to this and then measure each of their performance and availability. Once you have identified your key business attributes or services you can create a dashboard for the business to show how the underlying applications and infrastructure are performing in real time, you can proactively see how a web server down somewhere is impacting the response times, and then you don't have to spend time and countless conference calls to figure out what is broken. It should all be right there at your finger tips!
Comments