IT services more and more consist of services provided by external providers. Significant portions of the infrastructure are not directly managed by the IT departments. The latest trends in the enterprise space, Shared services, SaaS, SOA, outsourcing, etc. suggest that this is not a temporary phenomena.
IT organizations (as well as IT management vendors) need to adjust to the new requirements introduced with this new landscape.
So the question is: how can you do end to end management of a service when the infrastructure for the service depends on combination of multiple internal and external service providers?
Do you think silo organizational structure is an obstacle in ITSM/BSM implementations? External service providers are silos by definition. When companies begin to use external providers heavily, the primary role of the IT department may become the implementors of ITSM/BSM, except this time you have to convince your providers to play along, and not just other groups in your company.
Customers and service providers need a robust mechanism to be able to share management information. This is not by itself anything new. Customers need transparency from service providers for peace of mind, if for no other reason. As a response, service providers have been beefing up their capabilities to offer management information, typically for the purpose of reporting. The robustness of the capabilities provided has become a differentiator for the service providers. They have been moving from simple email alerts and monthly reports to web based portals and dashboards to enable customers to get an idea of what's happening, what the status of services (if provider is sophisticated enough) are, etc. Customers can see events, performance metrics related to their services, open tickets, etc.
Yet this is far from being sufficient for an IT department to manage a service that relies of multiple service providers. Just imagine the puzzlement of the help/service desk when a user calls to report a problem with an application? Where is the problem? The network? the server? the application? which part of the application? Who is the provider for the internet connection? Is that an internal application or an external one, or may be it's an internal one that uses several services via web services APIs, or vice versa?
Clearly, the service model would have to include not only the internal components that are under direct control of IT, but also the external components and all the dependencies among them. But even that would by itself may not be enough. In this environment, the service desk really has to be able to determine where the problem originates majority of the time. Bouncing of a ticket among internal organizations is bad enough, simply not feasible when external providers are involved. The service desk (Operations folks in general) need to be able to see all the management information (fault, change, performance, etc.) about the service within the context of the service model. It is not feasible for them to go to the "portal" of each service provider to figure out whether there is something wrong that may be related.
So far, the data provided by the providers have been designed for "human consumption" in the form of emails, dashboards, etc. To move forward, service providers will also need to provide the data suitable for other applications to process, and customer management systems will need to make use of this data. The service providers that make the fault, change, performance data available in the context of the services they provide will go a long way to differentiate themselves as this will help their customers overcome the new challenges introduced by using external providers.
This does not necessarily require grand enterprise integration projects where there are months of meetings among the organizations. The answer to the problems introduced by these new technologies may lie with these technologies themselves. Service providers can implement web services of their own to provide the management information. Customers then can make use of these web services to integrate the management information to their systems.
I think the bottom up implementations of XML Web services has much better chance to succeed here than the top down SOA type implementations. Top down approach is hard as it is within a single organization, it sure is much harder (if possible) among multiple organizations. Service providers may be better off following the lead of the internet companies like Yahoo, Google and Amazon, and enable "mashups" rather than over thinking the issue, wasting years in "standardization" committees, attempting to implement grand architectures. How is that for Enterprise2.0?
