Simon is a hands-on software architect and a senior consultant at 
SOA : Service focus
When building a service oriented architecture, does it matter whether your services have a business or a technical focus? Most examples that people come up with relate to business focussed services. Think exchange rates, pricing, inventory, trading, etc. These all map back to business services well.
But what about technical services? Obvious examples here include a logging service, an authentication service and so on. How about a routing service that acts as a facade for a collection of underlying business services?
The more I read about SOA, the more it becomes apparent that SOA, at a basic level, is just an architectural style made up of a collection of loosely coupled services regardless of whether they have a technical or a business focus. On the other hand, it's easy to see how SOA can be used to describe an architectural style that is made up of business related services.
As a technical architect, I think I'm more inclined to go with the former definition. However, if I were an enterprise architect looking to replace all of my heterogeneous systems with a larger SOA, then I'd probably want all of those systems to be exposed purely as business services. I guess it all depends on where you stand as to which definition makes most sense.
