IT Business Value

The Service-Oriented Business: Part 2

War on Cost Team — Mon, 28 Mar 2011 16:21:42 GMT

Fast forward four years. It’s 2009. Remember that you’re Sara, the CIO of a mid-to-large retail company. You have many accomplishments that the business leadership team (and Board of Directors) has recognized: a streamlined supply-chain management system that reduces costs and out-of-stock conditions in stores, expanded your ecommerce presence to Europe, and improved the service levels of your major mission critical applications substantially as well as most of your “tier 2” applications, to name a few.

Internally, you recognized that to have accomplished these goals for the business, changes within your IT group had to be made:

You examined the IT processes that historically were either poorly performing or not defined and created programs and training for staff to implement IT management processes based on ITIL
You virtualized most of your data center except for your mission critical applications and large database systems
You implemented an IT service management management function that resulted in a robust but practical and usable configuration management database (CMDB)
You created an SLA enforcement mechanism for your critical applications that has the effect of notifying your systems operations center when mission critical application components fail

As a result, sales are up, costs are noticeably lower, and service quality is significantly improved. Life is sunny.

Until the clouds come (sorry, I just had to put that in!)

The implementation of your online presence in Europe has increased the traffic to your site infrastructure by 20%. Moreover, this move results in many holiday specialty items. While your ecommerce infrastructure (web site, fulfillment, inventory, and supply chain) has generally kept up with demand, it has struggled with performance and scaling issues during the holiday season. Also, the annual operational cost of the data center is quite high due to the need to support seasonal demands. This new expansion is stressing your servers even more at peak and, though you’ve grown capacity to meet the demand, your CFO is putting pressure on you to cut operational costs. As you look at your utilization reports in February and March, noting the significantly low traffic that your servers are getting, you know a change needs to be made.

To solve the performance issues and the overall seasonality challenge that’s causing significant annual operating costs, you form a task force to investigate the implementation of a private cloud environment. While you believe this will potentially solve the performance and scale issues, you’ve come up with more questions than answers. On the plus side, cloud technologies promise significant scalability benefits (elasticity) to be able to more effectively handle the seasonality concerns, including scaling back services when demand is low. This plan could also result in improvements in your ability to deliver services on demand by deploying ready-made virtual machines for web and application servers. However, many questions persist:

What model do I choose: PaaS, IaaS, or some combination?

If I choose infrastructure as a service, how do I guarantee the quality of the resulting applications?
If I go with platform as a service, what standard services do I put in place that will promote agility without sacrificing quality? How do I enable flexibility and not compromise compliance?

Will it be cost-effective? I have a charge-back model today for the services I provide to various lines of business. How will I need to redefine that model so I can keep costs in line?
How will it affect my service delivery? Right now now I have a pretty well-defined service management system that helps me keep my critical apps up. Will there be significant VM sprawl as a result of the elasticity I should be getting? If so, how will that affect my ability to manage this sprawl for my critical applications. Heck, I just finished getting a handle on my tier 2 apps. Will I lose control of those?

If you haven’t gathered by now, there are themes here that the War on Cost team has been exploring and discussing for some time across a variety of scenarios. They are the enduring business value pillars of reducing costs, improving agility, improving quality of service, improving governance and compliance, and managing risk. All of these value dimensions are in play with the introduction of a cloud paradigm. In fact, they have the potential to be amplified:

Agility – Possibly the value pillar with the highest potential amplitude. The cloud paradigm (whether public, private, or something in between) has the potential for extreme agility. Automatically provisioning development, test, and production environments in a matter of minutes or hours instead of days or weeks has enormous potential
Costs – Costs have the potential to be dramatically reduced by providing a commoditized set of services that can be automatically commissioned and decommissioned at will. Also, server utilization can be significantly improved through intelligent load balancing as demands for the service change, particularly due to seasonal demands from stores and online traffic
Quality of Service – QoS in all its forms (reliability, scalability, performance, availability, etc.) can be greatly improved by intelligently and dynamically load balancing workloads across (potentially large) arrays of servers running as VMs on a farm of servers that are well-utilized
Governance, Compliance, and Risk Management (GRC) – These three are related values and the cloud offers huge potential benefits here too. As services are defined (whether its infrastructure, platform, or software), they are standardized (one of the main tenets of cloud computing). Standardization has the natural implication of introducing governance and compliance regulations, which, in turn, has a direct net benefit to managing risk

But, and it’s a really big but, what about complexity?

You’re thinking about the sheer number of VMs that can get spun up in your data center. Where once you had a hundred or so servers, you now have somewhere between five hundred and a thousand VMs (you’re not really sure). Will implementing cloud exacerbate that VM growth? How can I contain it? How much should I contain it?

So, therein lies the challenge before you: if you’re going to move to a private cloud because you and your business leadership team see the potential for huge benefits, how will you manage the complexity introduced by this cloud to be able to maintain and enhance your IT team’s ability to deliver for the business?

What do you think? Do these ideas ring true with you? Are there other major considerations to weigh? Let us know what your experience has been. Have you answered these questions for your organization? Don’t be shy. We want to hear from you.

All the best,

Erik, Strategist, War on Cost

The Service-Oriented Business: Part 1

wocteam — Wed, 16 Feb 2011 19:41:00 GMT

It’s 2005

Imagine you’re Sara, the CIO of your retail company with 10,000 employees. You have 500 employees within IT reporting to you. Your manager, Fred, the CFO, calls you into your office and asks: “Sara, how many applications does IT support?” My first thoughts (as Sara) are: “why is he asking? Is there a problem?”. My next thought is: “Does Fred want me to change the way I run my end of the business?”

Regardless of your initial thoughts, if you’re a typical CIO, the simplest and most straightforward answer is “I don’t know”. The truth could be anywhere from hundreds to thousands for a medium/large size organization that Sara supports. A more nuanced answer would be something like:

“Well Fred, we have 8 mission critical applications supporting the store systems side of the business, another 3 supporting merchandising, 5 supporting our supply chain, 3 for customer service, and of course, our e-commerce site. They all have SLAs that we defined and track on behalf of the various business stakeholders. There are approximately 250 other applications throughout IT that support the organization, but we don’t track them very closely. Finally, there are as many as 500 applications that we host in our datacenter but we provide no support for them.”

Sound familiar? It should. This is a classic problem of limited application portfolio visibility. Most IT shops support a vast array of applications, but only the ones that are either considered mission critical or directly support the business are managed closely by datacenter operations. This typical scenario presents the following challenges for you:

“Rogue” applications deployed into the datacenter could cause quality of service issues for the mission critical and/or tier 2 applications
Changes to any application in the environment could cause sudden, unpredictable resource spikes (network, data access, server CPU/memory) affecting any of the mission critical applications (and impacting the SLA)
Lack of visibility into which datacenter resources are associated with what application, such that, if a server goes down, IT operations may not know how many applications would be affected by the components on those servers becoming unavailable
Higher costs of deploying 3rd party applications on dedicated hardware
Higher costs of duplicate functionality from similar applications
Lower agility and higher costs due to not being able to optimize the server and storage resources for the application portfolio

Do you care? Absolutely! But, what can you do? Neither application development teams nor their IT support staff typically don’t define a production IT topology specifying where various components of the app will reside.

I’d like to hear from you about your experience with this dilemma. Does it ring true for you? Are there other pitfalls you see with this lack of visibility.

In my next post, I’ll discuss the “costs” of the problem in money, time, lack of agility, poor service quality, and risk.

All the best,

Erik Svenson, Strategist, War on Cost

Using metrics to, you know, actually measure stuff?…that’s crazy talk!

wocteam — Mon, 27 Sep 2010 21:48:22 GMT

A fundamental part of the work we do on our team is to measure things: the costs of deploying desktops, the business value of an application lifecycle management solution, the costs of managing a virtualized server environment, etc. In doing this, we aim to drive scenarios that amplify the value that our future products will have to our core customers. And to do that, it’s important to understand how our customers measure performance, costs, risk, and so forth and put that in a context of how our products are being used.

In a recent survey I conducted of 45 developers, DBAs, and information workers and managers, I wanted to understand what metrics were being used measure the effectiveness of current processes and technologies across a set of application platform scenarios such as building composite apps, managing app servers, and data warehousing to name a few.

What I found is that most respondents had very little sense of what measures were used to track the effectiveness of the work they do. This was especially surprising given the number of respondents who described themselves as having a very mature IT organization.

In his excellent book: How to Measure Anything: Finding the Value of Intangibles in Business, author Douglas Hubbard makes a compelling case for how it is possible to measure just about anything from a business context. The value of his message, in my opinion, is not that you can measure these things or even that you should. Rather, I think the biggest value here is how to measure. Without going into a lot of detail (and spoiling the thrilling end of the book!), he states that even if an organization doesn’t have a specific measure for some process or desired outcome, they will certainly at least have some observable way to detect an improvement that the business values. If not, you wouldn’t do it.

Given that rather straightforward and somewhat obvious statement, it’s clear that every organization in a business context will have measureable processes, technologies, and/or outcomes whether or not they have specific metrics or key performance indicators (KPIs).

What has your experience been in measuring your work against specific measures? How do you measure the effectiveness of your team’s work?

Let me know at erik.svenson@microsoft.com or feel free to post a comment.

All the best,

Erik Svenson, Application Platform Lead, War on Cost Team

Information Management - what do the real costs look like ?

wocteam — Tue, 25 May 2010 16:11:52 GMT

As the cloud environment moves from its conceptual state to a real living breathing reality, it brings with it a deep dependency to an area of IT that I predict will become central to how effectively the capability of the cloud is utilized. This same dependency underpins datacenter growth and change as well.

That area is information management.

Total capacity of shipped disk storage systems has grown by 14.8% in the last year⁽¹⁾. While profitability for solutions vendors has reduced as the storage market has finally started to feel the impact of the economic downturn, it is clear that demand for storage capability is not slowing down. The reality is the continual growth in the amount of data being created and needing to be stored is driving that demand. This can be seen in the associated rising costs associated with management of that data.

Even at a personal level, how many readers have in the last two years gone from managing their personal data stores by using DVDs to running terabytes of storage for movies and music and other media on home networks? Are you already using cloud based services such as Hotmail and the associated free storage, not to mention Facebook, Flickr etc. How many of you expect that use to slow down or diminish? How do you protect yourself from disaster? How do you deal with replication? What’s your personal strategy on de-duplication (do you really need multiple copies of that R&B album spread across multiple machines) ? Not to mention have you considered and understood the privacy and ownership issues that relate to web based storage?

Any business faces a similar reality - they need to fully understand how they will manage the information that they own. That management load includes not only simply storing their data, but also the challenge of managing capture, duplication, retention, access, and data protection. It’s clear that products for management of information are constantly improving - but at the same time the amount of data being stored and used grows as well. And with the widespread adoption of virtualization - storage and associated data protection form a complex environment that may create a significant potential source of frustration and challenge for an organization. Not to mention costs.

In my recent research it’s clear that there is a significant omission in the guidance available regarding information management and the associated storage solutions. While there are multiple claims of "cost savings", the majority of offerings do not define how organizations can measure any related benefits that are realized and delivered. The cost models that are publicly available are at best limited and simplified - they focus on generalizations and simple benefits related to technology. Doing further research regarding the state of the storage world this gap has become very clear - and I'm now also left wondering due to the lack of any clear data - what is missing in terms of impact on some of the other costs in the datacenter.

As our work continues to further understand the costs in the datacenter, it has become clear for information management that there are both benefits that can be delivered (stability via baseline measurement, agility through standardization) and investments that need to be made (quality of service by building and enabling standardization, risk avoidance through enabling backup facilities) that all assist in defining where the information management costs related to your data center will fall. There is however little or no coverage, or impact, in those models that is reflects the issues or need to have storage and its associated capabilities in place or used. That needs to change given the above.

So a clear goal in this area, and a focus of further work, is to create a cost model that reflects the major issues and challenges. If I can build that structure then an overall assessment of how information management impacts datacenter, and ultimately cloud, related costs will emerge. It should prove an interesting journey.

I'm interested in your feedback regarding information management, related storage implications, storage management and any associated cost models - I'd be more than happy to debate my position on the lack of well-defined cost models.

Brett

(1) www.networkworld.com/news/2009/072409-storage-vendors-emc-seagate-report

“Tier 1” Apps are Special…But At What Cost?

wocteam — Fri, 05 Mar 2010 15:28:00 GMT

Greetings everyone, and happy-almost-spring. Lately I’ve been focusing on understanding the costs (in all its forms) of delivering and managing Tier 1 applications. For the sake of discussion, let’s define a “Tier 1” app in terms of reliability or “quality of service”. In a previous post, I discussed four tiers of criticality for enterprise applications. While you may disagree with some of the names, there should be little argument that there are classes of applications that are truly critical to the success or failure of a business; the so-called “mission critical” application.

These apps are also referred more generically to be called “Tier 1 applications”. These applications hold a special level of importance in the corporate enterprise because their failure (measured in terms of reduced service quality or complete outages) would have a profound effect on the business including any or all of the following:

Widespread business stoppage with significant revenue impact
Risk to human health/environment
Public, wide-spread damage to organization’s reputation
Company-wide productivity is compromised

Examples of these types of applications are eCommerce (amazon.com, ebay, etc.), 911 response systems, stock and commodity trading systems, and airline reservation systems (some would also put CRM and corporate email into this group too).

(Note: while some have referred to Tier 1 apps with examples such as Exchange, SharePoint, SQL, Oracle, DB2, etc., I claim they are missing the point. With the possible exception of SharePoint, these other examples support the application and need to be treated as part of the overall solution, not as the solution itself.)

It’s obvious that these applications are important to the business for the reasons listed above as well as others. They represent a significant importance to the business when they run well and a huge impact to the business when they don’t.

Tier 1 Apps Put Quality and GRC Ahead of Cost

What I find interesting, however, is that these apps hold a special place in the minds (and the wallets) of business and IT leaders. Despite the IT maturity of an organization, companies will “invest” whatever it takes to keep these applications up and running with the highest levels of quality expected of their customers.

Even for organizations that do not have a culture of IT maturity improvement, Tier 1 apps will always enjoy financial and human resource availability to ensure those apps remain highly available. While the driver for most applications in the organization (60%-80%) is cost (delivery and ongoing maintenance), Quality of Service (QoS) and Governance, Risk Management, and Compliance are foremost.

The implications of this can be profound, particularly for companies that do not have a practice of IT maturity improvement. Highly mature organizations imbue the practices of service delivery with high quality, high compliance, and low risk across the entire portfolio of their service catalog, without incurring the huge costs of maintenance.

Less mature organizations, on the other hand, will tend to be reactive in nature and waste resources to ensure these Tier 1 applications remain healthy. The costs incurred can come from many sources such as expensive consulting resources, inefficient, time-consuming processes, and an over-reliance on expensive technologies. In short, these organizations will throw whatever is necessary at a Tier 1 app to keep it up and running to meet any explicit or implicit quality and compliance bars exist.

What to Do? Learn The Lessons from Tier 1 App Delivery and Management

Regardless of how you define it, every business of any appreciable size has Tier 1 applications. Unfortunately, many IT organizations do not have a very high level of IT maturity and yet, these Tier 1 apps demand it. As a result of this gap, significant wasteful costs are incurred to keep them up and running. Where there are pockets of good, mature IT practices, they probably exist within the realm of Tier 1 service delivery.

Unfortunately, what also exists is REALLY bad process too, all in service of maintaining high quality of service. In my role as an enterprise consultant for many years I’ve seen countless “all hands on deck” events when a Tier 1 app went down. There was a mad scramble to restore service, all the while work on other important IT functions was put aside.

For that reason, IT organizations should look at the mature practices and policies they do have have (many of which will be implied) for their Tier 1 apps and see how to apply them across their IT service portfolio, but not simply because it’s “good practice.”

The organization needs to also take a hard look at recent emergency situations as much to understand what cost is being incurred to restore service as to understand how to minimize their occurrences.

By using the lessons learned from their Tier 1 app efforts (both the good and bad), IT organizations will reduce their overall delivery and operating costs by becoming more efficient in the deliver of IT services through such activities as:

Rationalizing the costs of high availability
Reducing the reliance on expensive consulting and support resources
Becoming smarter and more targeted about information security
Designing apps with the right level of service (how many “9s” are needed?)
Resolving incidents more quickly with appropriate service monitoring

Conclusion

The overall message is simple and taken from an old adage: an ounce of prevention is worth a pound of cure. IT organizations and the businesses they support will lower their overall delivery and operations costs when they look to the best practices learned from the delivery and maintenance of their Tier 1 apps and apply them generally across their organization.

All the Best,

Erik Svenson, Application Platform Lead, War on Cost Team

IT Maturity Is More Than Process Improvement

wocteam — Mon, 04 Jan 2010 21:21:10 GMT

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 (http://blogs.technet.com/itbizval/archive/2009/02/27/the-role-of-information-technology-in-today-s-economy.aspx) 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

wocteam — Fri, 11 Dec 2009 21:22:14 GMT

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

Application Criticality

wocteam — Tue, 01 Sep 2009 22:27:00 GMT

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	Widespread business stoppage with significant revenue impact Risk to human health/environment Public, wide-spread damage to organization’s reputation
Business Essential	Direct revenue impact Direct negative customer satisfaction Compliance violation Non-public damage to organization’s reputation
Business Core	Indirect revenue impact Indirect negative customer satisfaction Significant employee productivity degradation
Business Supporting	Moderate employee productivity degradation

What do you all think of this definition of application criticality? What would you add or change? Do you have a similar or different concept of application (or service) criticality in your company?

I’d like to hear from you. Feel free to contact me at erik.svenson@microsoft.com.

In a subsequent post I’ll share some of the results I from my study on this subject.

All the best,

Erik

Managing Services, not Apps

wocteam — Wed, 24 Jun 2009 17:30:00 GMT

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

erik.svenson@microsoft.com

Web Services Adoption Increases – Management Focus Does Not

wocteam — Mon, 15 Jun 2009 22:40:00 GMT

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 erik.svenson@microsoft.com. 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

wocteam — Wed, 06 May 2009 04:43:00 GMT

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

wocteam — Thu, 26 Mar 2009 18:26:00 GMT

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

wocteam — Fri, 27 Feb 2009 23:24:00 GMT

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 Microsoft.com, 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 with inefficient IT organizations managing core workloads in the datacenter.

So what does this mean to an IT organization in today’s economy? With budgets getting cut and organizations being asked to do more with less, the first step is to take a look at how to improve your efficiency. After all, if you can free up time by improving or automating processes, for example, that time can be spent on activities that provide strategic business value. The reduction in workload management costs were in the thousands of dollars per server for high-value workloads (e.g. email, collaboration) for mature organizations versus basic organizations. Even lower value workloads (e.g. print sharing) showed reductions in cost in the hundreds of dollars when well managed. The study showed that many organizations stand to achieve significant savings by optimizing its infrastructure. The Spotlight on Cost whitepaper will help you get started by pointing you at the best practices that you should evaluate for adoption within your organization. The key thing to note is that these practices often require no new investment in hardware or software, but only require improving systems management processes and leveraging the investments in tools that you already own.

Once you have a plan to optimize operations, you need to work with your business units to understand their business needs and align IT as an enabler in meeting these needs. The companies that, in this economic downturn, come out ahead of their competitors will be those companies that don’t just tighten their belts to control costs, but actually invest in the business to offer new or improved products and services. By optimizing IT, that enables the company to leverage the use of IT in its investments. Obviously there are some business requirements that must be addressed, such as GRC-related (Governance, Risk Management and Compliance) requirements. But there also needs to be effort and investment to improve the quality of service and agility that IT provides the business.

In summary, we feel that in today’s economy IT organizations should do the following:

Optimize, optimize, optimize! Assess your operations to evaluate where you can implement best practices to improve efficiency and free up resources to work on more strategic activities. Talk to your Microsoft account team if you would like Microsoft’s assistance to evaluate how you can optimize your infrastructure.
Align IT with the business units within your company. Now more than ever it is important that the business views IT as a strategic enabler for the business to distinguish itself from its competitors. Review with the business executives the challenges and opportunities they face to identify how IT can be leveraged to address these challenges and opportunities.
Invest in IT. Those companies investing in IT during this economy are the companies that will survive the downturn and then excel as the economy improves. And by optimizing your infrastructure first, you have the opportunity to invest by shifting resources from sustaining to strategic activities.

As always, we welcome your feedback.

Elliott

New Virtualization site released

wocteam — Thu, 26 Feb 2009 04:22:50 GMT

Further to my on-going threads re virtualization – make sure that you have checked out the latest update on Virtualization and its benefits that has just been released in the new Microsoft Virtualization site. The link is http://www.microsoft.com/virtualization.

There is great data now available re the benefits that are being achieved by our customers using Hyper V and associated tools like SCVMM.

Enjoy

Brett

Microsoft and the War on Cost

wocteam — Wed, 25 Feb 2009 22:02:00 GMT

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 a very detailed level to improve operational efficiency;
Although we are part of the Management and Services Division, we work across Microsoft’s business units to drive improvements in manageability into products that reduce costs for customers, so we are not tied to products from just the Management and Services Division;
And our responsibility is to improve products organically, by building improvements into the product, or even inorganically, such as by licensing or acquiring technology from other companies.

Why do I tell you this? Partly to help you obtain a deeper understanding of our role within Microsoft, and partly to demonstrate Microsoft’s commitment to help our customers operate Microsoft software as efficiently as possible. I will also add that we hope you are not offended by the use of the word "War" in our team's name. We know this can be a sensitive word, but our reason for using it in our team's name is to connote just how serious Microsoft is about reducing operating costs for its customers. You can learn more about some of our work at the Spotlight on Cost web page.

We hope you are finding our posts useful and look forward to your comments. Please feel free to email me if you would like to respond directly to me on this post.

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

wocteam — Fri, 20 Feb 2009 12:45:00 GMT

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

Finding the Pillars of Virtualization

wocteam — Tue, 10 Feb 2009 02:47:00 GMT

Hi my name is Brett Williams – I’m the focus owner for datacenter and virtualization on the War on Cost team and like my colleagues will be a regular contributor to this Itbizval blog.

Currently I’m on a search for Automation, Consolidation, and Integration being used together. My goal is to find them being leveraged to manage Virtualization.

Why ?

In one view they are three very well known and straight forward strategies that assist to drive costs lower, increase availability, address governance, manage compliance and decrease risk. In another perspective they are the core parts to making the virtualization excitement and focus real.

Considering the strategies above individually there are many specific incremental benefits that can be achieved. Each strategy has a range of fundamental processes, and technology that can be applied effectively.

Combined they form a core framework for managing the increasingly complex and important role of the datacenter – the central component in the delivery of the business services and capabilities required in today’s volatile and challenging economy. Unfortunately cost inefficiencies and service inflexibility are commonplace. So the question becomes what is really the reality of these strategies and how are they impactful ? What can a customer take and really use ?

Again these are a strong clear messages that are widely known. They are not new. They should be being followed.

Unfortunately our recent research findings on datacenter operations don't provide a rosy picture. In fact what we have uncovered is that there are many fundamental IT processes that are not being adopted by organizations and that failure to adopt has a direct impact on operational costs.

Match that failure to adopt fundamental processes back to the three pillars we are discussing and it is clear there is real scope for change in the somewhat untouched datacenter world. Its not just all about green IT or environment management, the latest hardware or even a software feature compete - its also about managing what should be fundamental services efficiently.

Now let's try and understand how Virtualization comes into this story.

How are these strategies being used to benefit Virtualization ? Are they relevant ? – what effect could they have ? All questions that are very important to have answers for. To do this - over the next few blog updates I’m going to drill into our data and outline the key findings observed and the impact of the the three strategies above.

And yes I do consider that virtualization is the key to the future for datacenters….

Brett

If you want to discuss this in more detail – or can our team provide guidance to help you with a customer discussion or question please don’t hesitate to contact me directly at (brettw@microsoft.com)

ROI is Dead - Long Live ROI!

wocteam — Tue, 27 Jan 2009 00:12:00 GMT

For years, organizations have been chasing the holy grail of “ROI on IT investments”. The typical approach has been focused on the TCO ("Total Cost of Ownership") methodology, wherein one measures the current annualized cost of the IT environment, the future/anticipated (and presumably lower) annualized cost of the IT environment, and then seeks to calculate whether or not the lower anticipated “run-rate” returns value over and above the cost of the IT investments made to achieve it.

Boiled down to its essence, what the TCO approach generally does is put a boundary around IT’s “direct costs” or “hard costs” – the set of things which appear in the IT budget, including hardware, software, and ongoing IT labor - but excluding any factors which do not directly correlate to IT spend.

For IT-centric questions, this TCO approach may still be valid. The problem is that, as IT seeks to become a “strategic enabler to the business”, a pure cost focus may no longer be entirely meaningful. Rather, cost becomes just one of the interesting variables in the equation. In our opinion, other key variables are centered around business impact: Agility (how quickly can IT respond to business needs and changing business conditions?); Quality of Service (how well does IT deliver against its service commitments to internal and external customers?); and the question of Governance, Risk Management and Compliance (how well does IT protect the business against regulatory issues, audit requirements, threats to business continuity, etc?).

In that light, the ROI question becomes both significantly more compelling, and significantly harder to quantify. More compelling because business alignment is a critical success factor for many IT organizations; as Peter Weill and Jeanne Ross wrote in “Six IT Decisions Your IT People Shouldn’t Make” (Harvard Business Review, November 2002), a company must “clarify [their] strategy, then ensure that all [their] IT decisions support that strategy.” Put simply: IT’s goal has to be about helping the company achieve its business goals. Reducing TCO is a part of the answer, but it is not the entire answer. At the same time, the non-cost impacts on ROI are harder to quantify because those “other parts of the answer” can be very difficult to calculate on a generalized basis.

Consider an example of “backup and recovery”. There is no question that a robust backup-and-recovery solution costs money to implement, manage and support (representing an increase in IT spend). But, if that same backup-and-recovery solution mitigates or eliminates the need for users to spend countless hours of non-IT time recovering or rebuilding lost data – a cost which is not reflected in the IT budget – doesn’t that solution have “business value” beyond the boundary of the IT budget? Assuming it does, how do we calculate the “cost” of lost data and the “benefit” of lessened exposure to data loss? And, would the calculations be different for a highly-centralized manufacturing plant than for a highly-decentralized retail chain?

Or consider another example: in the context of emerging “optimized desktop” scenarios, the ability to implement a standardized-but-flexible desktop through any of several virtualization approaches may cause an increase in (for example) infrastructure costs, as a result of shifting client workloads and associated IT labor into the datacenter. That may represent an up-tick in “client TCO”. But when we consider the overall impact of such an approach, the impact may not only return benefits to the IT organization (operational efficiencies, manageability and support), but extend to the business as a whole in the form of organizational agility, quality of IT services, and ability to mitigate risks. As a result, the incremental IT spend has enormous potential to return superlinear “business value” to the organization, outside the boundaries of the IT budget. We don’t yet know how to measure some of those value components, but it is clear that the “ROI” of such a scenario is not just about “reducing TCO”.

My name is Bruce Gary. Within the War on Cost team, I focus on the ROI impacts of client scenarios, including “rich client” and “optimized desktop” scenarios. I want to take a second to thank Erik for starting this blog, and I also want to give the reader fair warning: my future posts here may at first blush appear to be a random assortment of thoughts ranging from crisp data-supported guidance to stream-of-consciousness musings on emerging scenarios and trends that intrigue me. Across that spectrum, though, I’m hopeful that the reader will gain some “value” and will, in turn, engage us in dialog that provides a positive return on the investment of your time here. I can’t help but think that will benefit us all.

Bruce

Application Archetypes and Management

wocteam — Wed, 21 Jan 2009 02:48:00 GMT

In general, there are six different types (archetypes) of line of business (LOB) applications prevalent in modern corporations today:

Rich Client Applications – Applications of this type are usually developed as stand-alone applications with a graphical user interface that displays data using a range of controls. Rich client applications can be designed for disconnected and occasionally connected scenarios because the applications run on the client machine.
Web Applications – Applications of this type typically support connected scenarios and can support different browsers running on a range of operating systems and platforms. Web applications have no client-side scripts or components. Web servers only serve HTML to the client.
Rich Internet Applications (RIA) – Applications of this type can be developed to support multiple platforms and multiple browsers, displaying rich media or graphical content providing a higher fidelity of user experience than traditional web applications. Rich Internet applications run in a browser sandbox that restricts access to some devices on the client.
Services Applications – The basic goal in this type of application is to achieve loose coupling between the client and the server. Services expose business functionality, and allow clients to access them from local or remote machine. Service operations are called using messages, based on XML schemas, passed over a transport channel. These applications may be part of a service-oriented architecture (SOA) or just a bunch of web services used for specific application solutions.
Mobile Applications – Applications of this type can be developed as thin client or rich client applications. Rich client mobile applications can support disconnected or occasionally connected scenarios. Web or thin client applications can support connected scenarios only. The device resources may prove to be a constraint when designing mobile applications.
Cloud-based Services/Applications– Applications in this space describe deployed services into either a private or public cloud infrastructure.

Many organizations naturally have a combination of most or all of these (maybe not cloud services/applications yet!), some of which are packaged applications, while others are developed in-house. So, here's the question: are the populations of the different types of applications random or are there patterns to the types of applications determined by some set of drivers?

From what I've discovered, management concerns drive many of decisions to deploy applications of specific types, namely Web applications. Arguably, these types of applications enjoy low deployment effort and cost compared to other types of applications that require components to be installed on some client device. The services that comprise web applications can also be centrally monitored without having to track utilization, configuration, and failures on client computers for the most part. The downside of these applications is that they tend to have low fidelity of user experience compared to any other type of application.

Now, if you're an optimist, Rich Internet Applications (RIA) have the best of both worlds between providing a rich user experience and having a relatively thin client footprint, in some case relying on a user experience engine such as Microsoft Silverlight. On the other hand, the pessimists out there would claim that RIAs introduce client deployment and management overhead that present significant associated costs.

The other types of applications have their own management overhead regarding deployment, configuration, and monitoring. In subsequent posts, I'll address some of those issues.

In the meantime, let me know what you think? Is your organization deploying a preponderance of web applications with a trend toward RIAs? Or, do you have some other type of profile? If so, why? Inquiring minds want to know.

All the best,

Erik

SOA Adoption Blockers: Service Management is Key

wocteam — Wed, 14 Jan 2009 17:39:00 GMT

Successful adoption of Service Oriented Architecture has been a topic of discussion pretty much since the beginning of its introduction to enterprise businesses five or six years ago. As companies have worked to adopt this approach to building more reliable and agile applications at a lower price, they quickly found that it wasn't as easy as it was to build the monolithic applications of old or even the n-tier and Internet applications that became standard archetypes in the late 1990s.

While those types of applications certainly require solid application development, deployment, and management discipline, SOA introduces several new dimensions to the challenge of successfully adopting applications built on this architecture. Applications that rely on SOA have two inherent attributes that do not necessarily exist within applications based on other architectures. First, the architecture promotes the composition of ever-smaller atomic services into higher-order services (a ProcessOrder service, for example, has ValidateCustomer and CheckCredit services associated with it). This "feature" introduces the potential for hundreds or thousands of these compositions to exist in the enterprise (or, in some cases, outside the organization's firewall; more on that in a subsequent post). Second, services based on SOA are autonomous and stateless by nature (or, at least, they should be!). As such, they can be created and exposed by anyone in the organization as a completely independent island of functionality without being tied to any one specific application.

While both of these elements of SOA can certainly benefit enterprises who wish to accelerate the creation of custom, line-of-business applications through the promise of service reuse, the dark side is that services can proliferate out of control. Adopting SOA doesn't inherently enforce reuse. Corporations may have multiple versions of a "CreditCheck" service created by different departments.

Further, these services don't necessarily have well-defined service levels defined for them that are backed up with enforceable service level agreements. While this may not be a significant problem initially, it can be a serious concern to organizations that want to adopt SOA as a strategic direction within IT. The nature of application development and maintenance changes since the development cycles, feature requirments, and service level requirements become decoupled.

While there are many potential impediments to SOA adoption, which I will post more on later, the discipline of governance and the implementation of robust service management is central to long-term sustainability of applications that rely on the services within an SOA. Here's why:

Many organizations view service orientation as overly complex, without enough supporting tools to properly manage service artifacts.
There is an inconsistent use of repositories and/or registries for defining service levels, availability requirements, and providing adequate discoverability (for a good description of repositories and registries, see Keith Pijanowski's article on this.
Policy enforcement at run-time in many cases is non-existent or is spotty at best.
Good service orientation mandates a consistent approach to data access. This implies that data management, including master data management (MDM), consistent access to structured data (as stored in a DBMS), semi-structured data (as you might find in search service such as SharePoint), and unstructured data (as exists on a file share), must be taken into consideration. Security and privacy must also have a strong focus.
Metrics definition and reporting is elusive. While specific services on individual servers can (and often are) monitored, having an all-up view of a related set of services that provide a business view of the health of the application is an altogether different beast to tackle.
Production testing and troubleshooting gets harder to implement. As services proliferate, a failure at any point along the way will be harder to pinpoint and diagnose, particularly if the failed service is part of one or more composite services.

Subsequent posts will delve into each of these as well as other adoption issues. For now, we'd like to get your feedback on the list above and the subject of service management. What resonates with your experience and what doesn't? In particular, I'm curious about whether application performance issues represent an impediment to SOA. In my experience, this hasn't bubbled up as a tier one issue, but I invite you to prove me wrong.

All the best,

Erik, Application Platform lead, War on Cost Team

Welcome to the IT Business Value Blog

wocteam — Wed, 07 Jan 2009 04:12:00 GMT

Happy New Year and Welcome to the IT Business Value Blog. Like others within program management at Microsoft, our team of strategic program managers (PM), including Elliott Morris, Bruce Gary, Brett Williams, and I, work within the Windows Server & Tools division at Microsoft to help shape the future of the Microsoft platform. However, unlike our peer PMs who mostly focus on particular product feature design, our focus is different in that we focus more on identifying business value enablers and inhibitors across various customer segments to better understand what our customers need from the future versions of Windows, our management platform with System Center, and our Application Platform.

Particularly in these tough economic times, we believe our team is positioned right in the center of what needs to be a highly valuable conversation with our customers around positive ROI (Return on Investment) and TCO (Total Cost of Ownership) and how to improve how the IT community provides value to their business customers. Please see our page for a more complete description of our team's mission and goals.

We hope this Blog will be informative as we share our insights with you in areas of client computing, virtualization, application platform management, etc. as well as collaborative as we engage you in a dialog for your opinions around how our platform is or isn’t satisfying your business’ needs.

We encourage you to be as candid as possible with us about where we’re hitting or missing the mark and only ask that you be as constructive as possible with your feedback.

All the best for 2009,

Erik

Elliott

Bruce

Brett