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
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
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
Filed under: Business Value, TCO, war on cost, total cost of ownership, return on investment, compliance, governance, Agility, dynamic systems, quality of service, Information Technology, infrastructure optimization, risk management
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
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.
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
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)
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
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
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
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
