The question is at what level should a high level service be created. The component that provides the service should not be at the level of an EJB, but something larger. A business function (like 'Financial Management') is too large a concept. This would break down into a number of Business Processes (like 'Create Account' or 'Reconcile Budget'). This seems better, but I don't really want to create a business process as a service. I think a service should be more like a operation on an object. The service component or architectural building block that provides the service should still work like a large object. So the answer is to map the business processes not down to elementary business processes but to shift the approach and map them to use cases. A business use case represents a dialogue across the system boundary and consists of a number of activities, that retrieve information and cause changes to the system's state. These activities are perhaps rather like 'features' in Feature Driven Development (FDD). So long as these feature are not too low a granularity, then they will suffice as candidate services. Also with this thinking, the use cases should be primary ones and not be refined with secondary 'includes' and 'extension' use cases.
Togaf has the concept of super services so I'll go and look at these now.