A service viewpoint is indispensable in building component software (especially in asynchronous structures). Saying simply "this is a component" (or even "an object") doesn't much illuminate the interfaces between one component and the rest of a system. But things become very clear when you start talking about the services which one component requires from others, provides to others, about the service levels which can be expected, and about the types of notification which consumers will need whilst their service is being performed. "Web Services", incidentally, is a great term for just this reason. Groove's software architecture is quite cleanly structured around abstract service providers: transport, security, storage, and so on.

The thin abstraction above a single component then becomes "provider": an abstract service provider creates an interface by which you can obtain services of a particular class, appropriate to your needs, with very little knowledge of the inner workings of that service's provision. You get "mix and match". Within an application, this begins to let you maintain multiple versions of componentry which might be revised, on different timescales, largely independent of each other.

The same is true organizationally, and in discussing property rights (authority, alienability and residual income: all important aspects of property, but I read too much Proudhon to take that stuff seriously) you miss the point of organization. The structure of The Firm is not primarily to consolidate property rights (a defensive model), but to enable growth (an expansive model). Growth requires innovation. Modularity of service enables innovation.

In an organization decomposed by service provision, strategic outsourcing decisions can be made quite easily; the Firm becomes flexible not only because it inherits the ability to expand and contract the workforce overnight (the commonly-held negative viewpoint), but because the service interface is an entrepreneurial interface understood by the outside world. If you build a world-class service unit, it can operate entrepreneurially: its customers can live inside or outside of the Firm. (I've worked in the past with one interesting company which has exactly this viewpoint). Many industries have already seen the widespread emergence of a "provider interface" in human resources, in the supply chain, and so on.

Now, I'm not arguing for decomposition of the company per se, just as I don't often argue that Groove would take over the world if it were to open-source its componentry. There are real-world interdependencies which often cut deep with good reason. Our QA team, for example, provides great service: file a bug report, and they track it through triage and resolution, providing callback notification if you wanted that. But the service viewpoint from one customer is different to the viewpoint offered other customers (GrooveQA Implements ITrackBugs, but also GrooveQA Implements IManageRegression, IRunVariedTestEnvironments, and much more). This is true both of software and organizations. The "re-composition" -- providing multiple interfaces, to give a coherent customer service -- is still not an easy design task.

I'm also certainly not arguing for price-oriented contracting. Price is one of the least useful metrics imaginable; simple price competition creates problems in structural inequity and false accounting of externalised operational costs. It's vitally important that we find alternatives which are less likely to destroy the world and cause misery for millions of its inhabitants. Given the choice, I wouldn't call on a transport service which caused a huge memory leak; but industry seems happy to outsource services to minimise cost regardless of environmental or human concerns. I don't have any easy answers there. Software's so simple, sometimes.

It's a useful thought-experiment, though: outsource your group. What services do you provide? Who are the customers? What internal process gains can you envisage if you clarify the current interfaces? What structural changes would be required, and what optimisations would it bring, if the collection of interfaces were different? Who else might require those services, and under what circumstances would it be appropriate to provide them? (The "GrooveConceptDevelopmentTeam.idl" is part of my agenda for next week).