OSIDs are an architectural tool. These specifications are meant to be applied to solve integration problems. OSIDs lay down the tracks to guide analysis and development of new systems. They do not optimize, or even address for that matter, tools and development environments to which programmers are accustomed. They also do not directly speak to business users who will trip over the service factoring and not understand the broad and sometimes tongue-in-cheek terminology.
OSIDs need to be applied to business problems. Applications need to be mapped to service operations and data. Implementations also need to be mapped or designed. This is the job of a service architect. Don't throw OSIDs into a project and expect magic to happen. OSIDs didn't graduate from Hogwarts.
The role of a service architect works the middle ground in the what we need now, where we are going, land of integration. In enterprise projects, the service architect works with all of product management, development management, functional business, UI design, service implementation, and middleware infrastructure. This is its own integration problem! A Service Design Methodology like the OSIDs is helpful for making sure it all comes together and lowers the risk a project will paint itself into a corner. The caveat is that the OSIDs will initially not speak to any of these parties and it will feel like throwing a monkey into the wrench. Over time, however, a project will more naturally align along service boundaries. It seems to do so because there is no other design methodology that crosses all the disciplines and can live beyond the latest design fad. Depending on the project, terminology alignment may be very difficult requiring the service architects to quarantine OSID terminology from some parts of the project.
From the service architect's point of view, application components and service implementations are developed piece by piece. The service architect has the proper vantage point from which to see other possible combinations, opportunities for reusability, repeating patterns, and piling OSID Providers on top of each other to solve new problems. A service architect doesn't decide if something should be implemented and having good developers means the developers themselves are capable of deciding how. A service architect directs where the problem ought to be addressed among a growing set of layered orchestrated services.