Blog

We’re excited to announce that we recently published a new whitepaper by Chris Vandersluis in the

A single, consolidated business intelligence portal helps Microsoft streamline business processes and lower costs. Users can share business information securely across the enterprise, and can view and organize reports with ease.

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.

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.

Here is some great news from Jim Corbin in the Developer Docs team: The Project 2010 SDK download and the MSDN online release are both published, and the Project Developer Center portal is updated. · Project Developer Center :

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

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

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

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

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