The right way to expose functions, creating web services, has nothing to do with technology and everything to do with architecture and the business. The rule is: fine grained business functions are services.
The granular level at which the business thinks about business processes is the level at which IT systems should expose web services. Why? Because when your business comes to talk to IT (and even talk amongst themselves), this is the level they talk at. When they reorganize business operations, this is the level they organize at. Therefore, this is the level of agility they expect the IT systems to have.
When web services are more coarse grained than this, the services frequently have to be adjusted and redesigned for changes – losing the benefit of reuse (or centralized use / single instance). When services are more fine grained than this, every integration requires significant effort in orchestrating multiple services into the expected business level of functionality, losing the ease of integration.
Of course this is not an exact science, and the business discussion will change over years. So IT needs to keep in touch with the business pulse at the executive level to know when that conversation starts to change and adjusting the "business components" appropriately.
Tools such as BPM and/or a good ESB environment step up to the plate here, allowing complex service composition fromn the more granular services when these types of changes occur. Therefore, leaning towards the more granular is usually better.
The granular level at which the business thinks about business processes is the level at which IT systems should expose web services. Why? Because when your business comes to talk to IT (and even talk amongst themselves), this is the level they talk at. When they reorganize business operations, this is the level they organize at. Therefore, this is the level of agility they expect the IT systems to have.
When web services are more coarse grained than this, the services frequently have to be adjusted and redesigned for changes – losing the benefit of reuse (or centralized use / single instance). When services are more fine grained than this, every integration requires significant effort in orchestrating multiple services into the expected business level of functionality, losing the ease of integration.
Of course this is not an exact science, and the business discussion will change over years. So IT needs to keep in touch with the business pulse at the executive level to know when that conversation starts to change and adjusting the "business components" appropriately.
Tools such as BPM and/or a good ESB environment step up to the plate here, allowing complex service composition fromn the more granular services when these types of changes occur. Therefore, leaning towards the more granular is usually better.