IT Maturity Is More Than Process Improvement

For years, IT industry consultancies as well as hardware and software vendors have talked about people, process, and technology as the three corners of the success triangle within an IT shop. And yet the various maturity models that exist haven’t yet married these three elements with the levels of maturity they describe. IT Maturity is often thought of in terms of process maturity or technical maturity. In the realm of IT maturity models, there are no shortage of frameworks that cover this area with Capability Maturity Model Integration (CMMI), COBIT , Microsoft’s Infrastructure Optimization (IO) Model , and Gartner’s Maturity Model being among the most popular. (Process improvement models such as ITIL and the Microsoft Operations Framework (MOF) share a close relationship with these maturity models but don’t, in and of themselves, promote a specific path to improved IT maturity.) Unfortunately, none of these models do a complete job of clearly defining the various maturity levels they espouse. The levels that are defined as part of their models are descriptive in nature without clear boundaries described between the various levels that give quantifiable measures of success. Further, the descriptions themselves do not cover all aspects of maturity. CMMI and Gartner, for example, focus exclusively on process improvement in which each of the maturity levels describe better and better states of process maturity. The Microsoft IO Models consistently define maturity in terms of an organization’s ability to automate processes. What is needed is a unified maturity model that incorporates what it means for an IT organization to be mature around the following: People The right staff is acquired and retained for the right job. They have access to appropriate training and, at the highest levels of maturity, have appropriate industry certifications and training credentials. Process While this area has been covered in depth by most of the models, process maturity should also include why processes are being improved in the first place. CMMI, for example, defines Key Process Areas (KPAs) such as “Requirements Management”, “Product Integration”, “Causal Analysis and Resolution” to name a few. While these process areas are categorized into various maturity levels, they are not inherently linked to specific measures of business value. Improving a process that isn’t measurably linked to enhancing the business’s effectiveness around any of the four War on Cost Value Pillars ( ) is a waste of time and effort. Technology This area has also been covered in detail by various models such as the Microsoft IO Model. The technology aspect, however, is a means to an end, not an end in and of itself. Very often, technology is used as a means to improve processes by automating them. By focusing on process automation, the value of technology is sold short. Technology should be utilized to help improve the maturity of people as well by maturing training, access to information, as well as the quality of that information. The War on Cost team is in the process of studying these concepts further to help unify these areas of maturity so that a more practical model of how technology can and should help customers become more mature can be defined. More to come. Happy New Year everyone! On behalf of the War on Cost team (Elliott, Bruce, Brett, and Erik), we hope you have a prosperous and successful 2010! All the best, Erik War on Cost Application Platform Lead

Practices vs. Processes

In the world of IT as in most industries, the term “Best Practice” is often used to describe a set of activities that a business would consider as representing the most effective set of activities for achieving a particular goal. But what about all those other activities that are not considered “best practice”? I would contend that many activities that an IT organization does would not be called a best practice. They may be effective, but not most effective. As an example, an organization might manually distribute client install discs for an application rather than create an automated software distribution mechanism. As another example, a development team may test an application completely manually rather than using techniques such as code coverage analysis and automated testing tools to increase software quality. In both these examples, the job gets done but with significantly differing results on quality, cost, agility, and/or risk. I’d like to suggest that both these cases above are examples of what I would refer to as “Practices”, borrowing the Wiktionary definition as “ The ongoing pursuit of a craft or profession , particularly in medicine or the fine arts.” Forgetting the “particularly in medicine or the fine arts” bit, I find this concept is useful because it provides a way to group activities that can be aligned along a maturity curve such as the Microsoft Infrastructure Optimization Model . A practice could be called “Test Pre-production Application” for example, containing such activities as: Develop test plans Perform manual testing Perform code coverage analysis Perform automated testing etc. As you can probably see, some of the sample activities above could be performed at a very basic level, whereas some could be more advanced, requiring sophisticated sequences and a higher degree of automation. Further, a practice is inherently associated with one or more of the War on Cost Value Pillars : Agility, Quality of Service, Cost, or GRC (governance, risk management, and compliance). Practices Are Not Processes There are many models out there that describe processes. COBIT for example, defines 34 core processes across four domains . ISO 20000 and other organizations also describe groups of processes as part of their model. While these processes and have their place, what they lack is a distinct linkage to sets of activities that can be assessed for maturity along some value curve such as service quality, agility, or compliance. For example, the COBIT process “Ensure Continuous Service” does not say anything about how well the organization performs that process. Also, these processes do not inherently align to specific value measures that are relevant to the business. While some of them may be implied, no model currently published makes this clear. The Value of Practices By defining sets of activities into practices and further classifying those activities into groups based on a maturity curve such as the core Microsoft Infrastructure Optimization (IO) model , it will be possible for us to assess how effective an IT organization is at delivering a service by determining how mature the organization is at delivering it (i.e., what activities does the organization perform at a given maturity level?). Also, we can also align these practices to specific value measures that the organization wants to better understand. For example, practices such as “Manage Policies & Compliance” and “Perform Change Impact Analysis” have clear alignment to Governance, Risk Management, and Compliance (GRC). An organization that has a clear goal to assess their maturity around GRC can look at specific practices that are associated with that value dimension. A Business Value Model As the War on Cost team matures this definition of Practices, we will publish more information about how it relates to our larger definition of the War on Cost business value model. More to come… All the best, Erik

Microsoft IT Strengthens Security with Data Loss Prevention (Article)

With information residing in a multitude of places, enterprises face growing risks of inadvertent or malicious leaks. The integration of Active Directory Rights Management Services into RSA Data Loss Prevention products provides a very effective solution for Microsoft IT to locate and protect sensitive data.

Learn Project 2007 quickly with the Quick Reference Guide

This just in from Toney Sisk in on the IW writing team: The blog title says it all—Quick. Project management methodology can be a complex jungle of concepts. One way to help you through the jungle is with a reference guide. This popular download maps the features in Microsoft Project 2007 with commonly accepted project management practices and procedures. Click the image below to download your copy for easy browsing. Or print it out for easy access.

Application Criticality

I recently completed a study of over 500 US-based customers in which I wanted to understand: what types of applications are being delivered and managed generally, how much does it cost to deliver and manage those applications how are web services being used how well are cloud computing solutions being adopted In my first post about what I learned from this investigation, I wanted to first share my thoughts about the concept of “application criticality”. We’ve all heard the term “line of business application”. While there are many specific definitions of what an LOB app is, a generally accepted definition is: An application that is vital to running a business This extremely vague term, while generally descriptive, doesn’t get down to the level of specificity needed to understand how one LOB app compares to another in importance, scope, or complexity. In order to better understand the population of applications being delivered and managed, I needed to get to a lower level of granularity. Our team therefore defined the concept of Application Criticality to better distinguish line of business apps from each other in terms of their importance to the business as well as their relative scope of influence on the business. Below are the 4 levels of criticality and their definitions. The descriptions of these levels of criticality are defined in terms of the impact on the business if these applications become unavailable. While there may be other ways to define these classes of criticality, we find it useful to refer to them in terms that line of business owners typically care about. Criticality Level Failures of applications in this class can result in: Mission Critical

Managing Services, not Apps

I’m currently conducting a study that looks at understanding how enterprise businesses build, deploy, and manage their line-of-business applications. As part of the study, I interchange the notion of an “Application” with a “Service”. The two are not really the same; in my world a “service” is an application that has added customer-focused attributes such as Service Level Agreements to ensure service quality and governance policies to mitigate risks, to name a few. However, I think it’s helpful for IT to start to migrate away from the term “application” and only think in terms of “service”. With the increase in adoption of service-orientation and the commensurate increase of development paradigms that encourage the creation of composite applications, the line is blurring between what an application is versus a service. Arguably, business agility is the brass ring of an organization’s ability to deliver for its customer. This agility will be determined in part by IT’s ability to build repositories of reusable components and construct new services from them. Before this can happen on a wide-scale basis, however, several things have to happen: The business needs to see IT as a business enabler rather than a cost center IT needs to have a clear understanding of what constitutes a business service and be able to report critical success factors and KPIs at a the service boundary Disruptive technologies such as virtualization, newer programming models such as AJAX, and cloud computing need to be adopted based on the assumption of delivering the right levels of service needed by the business. Too often, these technologies are treated like a panacea, when more often they do little more than add complexity The ability for IT to raise its profile with the business has traditionally been based on a reactive relationship with the business. Improved management practices that truly deliver high quality service management will help to change the perception and allow the organization to treat IT as a full partner in delivering high quality products and services to its customers. When my study concludes at the end of the summer, I’ll share some of the insights gleaned from it. In the meantime, let me know how your experience has been with the shift from application delivery to service delivery. All the best, Erik Svenson, Application Platform Lead, War on Cost

Web Services Adoption Increases – Management Focus Does Not

In a recent study of enterprise customers, I found that most reported an increase in the adoption of web services in the coming year. While that may not be a big surprise, what I found surprising was the lack of a commensurate focus on management practices of those services. Activities such as service discovery, implementations of service registries and/or repositories, as well as the establishment of service level objectives were noticeably absent for most customers surveyed. Why would that be if web service adoption was having an increasing level of importance to the business, at least as function of what IT is delivering? Is it because it’s too hard to implement? Are these structures too costly to put in place? Are these Service-Orientation practices not thought of as valuable? Some combination? My initial conclusion is that it is some combination of these challenges. Quantifying the value of things like service discovery or having a service repository may be difficult. Not implementing them in favor of increasing the manual labor cost required to accomplish the same task may seem easier, and less complex overall. But, do you sacrifice the very thing you set out to accomplish with web services in the first place: reuse? Do you find that you are re-implementing variations of the same customer lookup service across different departments for example instead of standardizing on one, well-defined, well-managed service? What other obstacles to you encounter in improving the management picture of your web services environment? Let me know your thoughts. Drop me an email at . I’d like to hear your opinions on the subject. All the best, Erik Svenson, Application Platform Lead, War on Cost