Grouping services into functional layers reduces the impact of change. Most changes affect only the layer in which they're made, with few side-effects that impact other layers. This fundamentally simplifies service maintenance.
As more and more services are added to a service inventory, the management of services within the service inventory gets difficult. In an unorganized service inventory, just by having a look at a service, it’s very hard to predict what kind of functionality is contained in it. This makes it difficult to pickup the right type of service until all of its functions are reviewed. Similarly, a service can be designed in a manner that it contains both the reusable logic as well as the process-specific logic. When it comes to change the process-specific logic, this can inadvertently impact the reusable logic as well, which means that the reusability potential of such a service is reduced. Contrary to this, the [[Service Reusability Principle|Service Reusability]] design principle dictates that services should be designed in a manner so that they can be reused as much as possible. Similarly, the [[Service Composability Principle|Service Composability]] design principle advocate designing services in a manner so that they can be composed into multiple service compositions<ref name='servicecompositions'>[http://www.whatissoa.com/p12.php service compositions]</ref>. Both of these qualities are only possible if the service only contains a specific type of logic e.g. either reusable logic or process-specific logic.
<br/>
The [[Service Reusability Principle|Service Reusability]] principle dictates that services should be designed to maximize reuse. Similarly, the [[Service Composability Principle|Service Composability]] principle advocates designing services so that they can be composed into various ways.<ref name='servicecompositions'>[http://www.whatissoa.com/p12.php service compositions]</ref> Both principles require that a service contain only a specific type of logic e.g., either reusable or process-specific logic.<ref name='SOAMag'>
In order to design a service so that it contains a particular type of logic, different logical groups of services need to be established within a service inventory as advocated by the application of the Service Layers design pattern<ref name='SOAMag'>Thomas Erl.[http://soa.sys-con.com/node/645271?page=0,1 Introducing SOA Design Pattern][Online].Date accessed:6 April 2010.</ref>. Each group only contains a particular type of logic<ref name='WK' />, so by restricting the service to only contain a particular type of functionality, the design of the service remains rather straightforward and one can predict the type of functionality the service provides and its behavior by looking at which layer does it belong to e.g. services in a particular group may not be suitable for composition as compared to another group.
Thomas Erl.[http://soa.sys-con.com/node/645271?page=0,1 Introducing SOA Design Pattern][Online].Date accessed:6 April 2010.</ref> Restricting each layer to a particular functionality, simplifies the design of the service.<ref name='WK' />
