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

soa Not SOA Is The Ticket

In my last post I referred to a study my team was conducting around SOA and web services management patterns. The high-level purpose of the study was to gain insight around: whether service-orientation practices were being used for building web services (as opposed to simply building a bunch of independent services), what service-orientation practices were being used such as service discovery, governance, etc., and if service-orientation practices were being used, was there a positive benefit to the business around agility, application availability, manageability, performance, and scalability What I’m finding in the recent data is that in no case are companies taking on SOA as a strategic initiative, driven from the business or CIO. Rather, in most cases, those IT shops that see the value of service orientation and build service-orientation practices into their overall software delivery process demonstrate that value to their business constituents after they’ve shown the value of doing so. That value is demonstrated mostly in the form of improved agility and an application’s quality of service. Interestingly, some customers have reported a degradation of scalability and/or performance (more on that in a subsequent post). Once that value is shown, the business embraces the idea and is willing to invest resources into it. For example, in all cases, customers responded that the number of web service implementations will increase in the coming year, in some cases significantly. This is occurring despite most customers not adopting some of the core service-orientation practices such as service discovery or repository implementations. In those cases, it appears that it is just a matter of time and those organizations will adopt those practices at some point in the near future. So, what’s your experience been? Have you seen measurable improvements in manageability, agility, quality of service, etc. or has it been a mixed experience. More to come on this… All the best, Erik, Application Platform Lead, War on Cost

[Web] Services are at the tip of the app management spear…maybe

I’m in the process of studying what web services (now just called ‘services’) management costs IT organizations. Specifically, I’m looking at what the various cost factors are considering both an environment with a service-orientation mindset (SOA, ESB, SOI) and without. One thing I’m seeing so far is that the service discovery aspect is significant. Many companies don’t have a registry (UDDI or otherwise) that allows project teams to find services that may already exist. I find this very interesting since the number one (arguably) benefit IT shops hope to gain from adopting services is reuse. How can an organization take advantage of service reuse if there’s no viable way to discover them? The cost to rebuild a service that may exist in another department in the company is probably significant. Not only that, the cost of maintenance and monitoring of the ‘new’ service is not insignificant. Another thing I’m seeing so far is that companies don’t have the capability of treating a ‘service’ as business service from a management perspective. In other words, IT is still in the mindset of ‘managing’ individual services or components without looking at the whole application or ‘business service’. I wonder what your experience is at your organization. Feel free to email me or comment here. I say that service management is the tip of the the overall app portfolio management spear because I’m seeing a trend toward more service orientation where web-based applications are becoming the norm and they are being built from ever-smaller, autonomous, stateless components (i.e. services). More insights will follow as my study progresses. In particular, I hope to quantify the costs of service management as well as bringing some quantification to the value side of the equation. Stay tuned for that. All the best, Erik

The Role of Information Technology in Today’s Economy

There seems to be a steady stream of books published on the role of Information Technology within the business it supports. The role of IT is constantly evolving and has changed significantly from the days when the IT organization was often referred to as “data processing.” Today, in many industries, IT enables some businesses to differentiate themselves from their competitors. Those companies that leverage IT for competitive advantage often differ from their competitors in two ways with respect to their IT organizations: they view IT as a strategic business enabler instead of as a cost center, and they work to maximize the efficiency of their IT operations so that they can focus their resources on providing value to the business and respond to today’s environment of rapidly changing business conditions. Microsoft has developed a model, the Infrastructure Optimization model , and an initiative, the Dynamic Systems Initiative , to assist IT organizations in becoming efficient business enablers for their companies. If you aren’t familiar with the IO model or DSI, we highly recommend you follow the above links and familiarize yourself with the information and resources provided within these two programs. In Bruce’s January 26, 2009 post , he touched upon IT being a business enabler. Bruce also discussed what we see as the four cornerstones that drive IT behavior: Cost Agility Quality of Service And Governance, Risk Management and Compliance (GRC). We recently published the results of a study we did on the IT labor costs of providing core infrastructure workloads. You can learn more about our study by visiting the Spotlight on Cost content on, where you can register to download a whitepaper of our findings. One surprising discovery in our research was how few companies implement best practices to improve IT efficiency . Of 51 best practices studied across six different workloads (networking, identity and access, data management, print sharing, email and collaboration), the average adoption rate was only 30% – meaning, each of the best practices was implemented on average only 30% of the time. We also found that roughly 70-75% of the companies were operating at the basic maturity level, per the Core IO model. The basic maturity level is the lowest and least optimized level per the model, so this is a very high percentage of companies

Microsoft and the War on Cost

Hello to everyone, and our thanks for stopping by our blog. My name is Elliott Morris, and I have the privilege of managing the War on Cost team and working with Brett, Bruce and Erik. Before I start adding posts to our blog, let me tell you a little more about the War on Cost team and what it is we do at Microsoft. At Microsoft, we are always looking to improve our products. There are many people involved in the process for planning a new product or the next version of a product, however our team is unique for a few reasons: We collect significant amounts of operational data from enterprises to understand their costs for deploying, operating and supporting Microsoft software – our product groups do significant research to understand product requirements, but it is our role to understand requirements at

IT Managers: What do you expect when developers aren't incented to build manageable applications?

Greetings everyone. I’m Erik Svenson , a biz value strategist in the System Center team at Microsoft and I focus on application platform management costs. I posted a couple weeks ago about the different types of apps out there (web, RIA, rich client, etc.). In all cases, they suffer from one common, cultural issue that plagues the consistent management of enterprise applications: developers aren’t paid to design and build applications with manageability in mind. In my 25 years in the industry, I’ve consistently gotten the message that building manageability into the application is, at best, an afterthought. When I was a developer back in the mid ’80s and early ’90s, the only thought we had around the management aspect of an app was to put in somewhat meaningful messages when an error occurred. There were no conversations with IT about how the app should perform or even a document produced about what the application did. Nope. We just tested it and pushed it out to IT with a request for the right amount of disk and processing capacity (“right” being defined by us developers, by the way!). Part of that was due to the fact that there were no management tools out there and have only become mainstream in data centers in the past fifteen years or so for the distributed computing platform. Now, there’s no excuse. With System Center Operations Manager (SCOM) , WMI and the .NET Framework, we have a rich platform to easily build management capability into applications through custom alerts that are fed into Ops Manager (or any WMI consumer) as well as custom management packs. This is all wrapped in a strategic bow we call the Dynamic Systems Initiative also known as “Dynamic IT”. And yet, few developers do this at all or, it’s an afterthought. Why? Well, I think it’s roots are primarily cultural supported by a lack of incentives. Developers simply aren’t paid to build proactive management capabilities into their applications. Even though it may take just a few lines of C# to do build an alert these days, in the crush of trying to get an app out the door, these tasks are considered nice-to-haves and generally don’t get done, much in the same way commenting code isn’t a requirement. So what’s to be done? Now that we have the tools for developers to easily build manageability, how do we do it? First, business stakeholders have to see the link between their needs for agility and reliability of apps in the business and the capabilities offered by the management platform. This is the old “an ounce of prevention is worth a pound of cure” adage. Second, development teams need to be incented not only to deliver applications on time but also based on the quality of those applications. This quality metric needs to be extended past the ideas of fixing bugs. Quality has to also be a function of how costly it is to recover from an app failure. Of course, this requires that these costs are tracked as part of a set of key performance indicators (KPIs) managed by IT. Finally, IT operations needs to be “in the room” with development teams early enough in the development lifecycle to provide requirements as well as to understand the nature of the application. In the coming months, I’ll be studying what it costs to manage a “bad app” and a “good app” across the different types of applications out there. In the meantime, what do you think? Does this ring true for you and your organization? Let me know. All the best, Erik