Any time there is work to be done, questions are raised about who will do it, and with the enterprise those questions are focused around cost management. Is it cheaper to contract for network and IT functions or to perform them yourself to avoid funding someone else's profit goals? We've heard about outsourcing and insourcing as the names for these options, but there's growing strength in something we could call "service-sourcing." In some ways, it's a middle ground that balances the extremes of the issues. In other ways it's a new approach altogether.If you ask any enterprise or service provider business planner what their goals for the future of technology deployment might be, they'll almost always say "increase flexibility" and "manage cost of operations" as their top two. The problem is there's a fundamental tension between these two. A programmable database platform is certainly more flexible than a CRM application, but to exploit that flexibility you have to commit to development and support. A hosted CRM service presents a stable cost point, but it's not as readily customized to the needs of the business as a self-developed application.
The approach that both enterprises and service providers are taking to resolve this tension is a relatively new concept--a customizable or programmable platform on which applications can be quickly built. This platform includes its own support/operations tools and so can be used to lower support costs at the same time as it increases flexibility. The platform can also be visualized as something the enterprise uses internally or that a provider uses to create SaaS offerings to the enterprise. Even consumer services can be visualized this way. The platform becomes a tool for developers, service providers, and the users themselves, and the applications that run all appear to the user as "services." Migration to this sort of scheme can then be called "service-sourcing."
Examples of this type of platform exist now at many levels. Some programming languages like Java are very general platforms, but there are cloud providers who are doing the same thing. Microsoft's SharePoint is such a platform, and so is WebSphere. What is new and being developed are platforms with more specific and limited missions, designed for collaboration. Google Wave is one example of the newer ones. Think of these as "application platforms" that have their own functionality at a high level but can be added onto and extended as well.
Even though most enterprise IT applications aren't readily viewed as this kind of services, there are many evolving applications in enterprises that are linked less with existing IT and applications and more with the desire to improve worker communications and productivity. Mobility management is an example, and so is security management, unified communications, and collaboration. You can think of these as "technology staff functions" designed to support work practices more than application details. They can be "service-sourced" easily, using custom in-house development, third-party applications, or even SaaS. In general, anything that has an SDK and developer program could become a platform by shifting its focus away from its own functionality, and toward providing the kit and tools for third-party development.
Service-sourcing is focused not as much on how a given "service" is implemented as on how that service appears to the outside world. A good application is one that can be converted into a "black box," a concept that interfaces with the rest of the world through defined features and interfaces, but doesn't need to expose its internal properties. For a given service like collaboration, service-sourcing would define functionality (white board, telepresence, etc.) and interfaces (SIP, web URL, etc.) for each discrete component of the service, such as the client and server side.
For a given service-source model, all implementations are equivalent in terms of how users interact with them and how they interact with other applications or services. That creates a really nice framework for competition and innovation while preserving a stable model of use and integration to limit the risk that new capabilities will collide with older implementations. That collision could strand assets and confuse users.
The problem with the notion of service-sourcing is who defines the models, and in fact the whole idea of service-sourcing might point out an emerging issue in cloud computing and advanced services, not to mention UC/UCC and voice services. Here's the issue: There are plenty of vendors working on products, plenty of providers working on services, and plenty of standards bodies looking at interfaces; but nobody is really trying to define a kind of component block diagram that would show how the relevant features of new applications could fit together.
Absent this model you might well have three sets of developers working with standard interfaces that can't communicate because the tools they've developed use the interfaces based on a different view of functionality. An example is that an LDAP interface might simply update a database, or it might be a way of changing a user's application privileges or default service quality. Send the same data on the same interface and the first application writes it to disk and does nothing, while the second changes the service.
We could propose a whole new set of standards bodies or a whole new set of standards missions for current bodies here, and the result could well be more people trying to define something than are actually developing anything to use, or even using it. A better approach might be for enterprises themselves to get a bit more involved at this level. For tools like UC/UCC, security management, access rights, and mobility there are more than enough implementations to support a user-selected structure for the components of these services, and to define the best ways for them to connect. With that kind of input, providers of all sorts would be able to build the tools and expand the opportunity.
Lacking user input, the way that service-sourcing will come about is through the PaaS (platform-as-a-service) providers already in the market, like Salesforce.com or Google. A good service platform will be one that creates some preferred model of functional compartmentalizing of applications. Some might do that implicitly through structure of the middleware features that build the platform, some by how the development process modularizes tools around goals in top-down design, and some by example. We can see all these approaches in the PaaS providers of today. We should encourage them all, but also be mindful that the value of PaaS may depend as much on how service-source-able the results are as on the technology that's used or who provides the implementation.
